The Objectives of the Business Intelligence Project

These are the objectives of the business intelligence project. We want to do customer profitability. We want to do revenue enhancement. We want to do product defect reduction. We want to save money. Whatever those big things are at the executive level, that’s where we start in the dialogue, and then we start to decompose the executive goals into the concept of themes.

In the case of customer profitability one theme might be lifetime value scoring, and the other might be customer retention metrics. These two different things are related to the common ethic of customer profitability, and so we may deliver one piece and then a second piece in the second iteration.

And from there we then begin to get into the heart of the agile methodology in the context of the user stories or the business which are often articulated in the forms of business questions. That’s where we begin to put some meat around what the specific information needs are to allow the themes and ethics to be fulfilled.

How These Stories Get Decomposed

Now the next thing we do from there is once we begin, and I’m going to show to you an example of how these stories get decomposed, but what we do next is we begin to decompose the stories or the questions into a set of business terms or a glossary or a data dictionary that then becomes where we move from the business value chain to the technical value chain to figure out where can I pull this data from.

If we think about business questions like how profitable are my customers and are they increasing or decreasing over time and how does it vary by geography. What we do is we’re deconstructing them. I see this term customer, or I see this term geography. I see this term revenue. I see this term profitability and we begin to build that glossary and do data storage searches and define what these words really mean and we get the standardization of terms.

Then we pass that over to the IT group to figure out where can I potentially source the data from, and then as we’re now same within the business value chain we begin to create what's called a business model which I’m going to show you some examples of. Out of that we create a working prototype. And we create a star schema which we can then build a semantic layer around and build some reports and do this through prototyping in sprint zero.

Then we can allow the technical team to work in parallel to continue to do the source systems analysis and then begin to build out ETL and the mappings. We view the ETL and data warehouse architecture layers as an independent subset because we can build a prototype without having to have actually source data. We can create dummy data sets and do prototyping for validation without spending the time and effort to do all the ETL work.

Focus on Business Value Chains

Here is a polling question, does your organization focus on the business value chains when starting BI initiatives in the way I’ve explained it or something similar? I’m going to launch that poll, and if you could go ahead and answer the question. We will give it a few minute. I’ll give it a few more seconds. Okay, so we’re going to close that, and we’re going to share the results and what we see is that 27% say not at all. But we could do better and again this is typical of what we see all the time.

What I hope to show you, and what you can take out of today is it if you start to follow these business value chain processes and methods and adopt them within the agile framework, what you’re going to end up doing is hitting homeruns every time. You’re going to get the business requirements down to a very precise level, and you are going to get very happy business people because of the prototyping methods and what they entail and how what they bring to the table is clarity.

So, having said that if we start to look at that traditional SDLC, and we overlay the value chains, and that’s really where the agile methods and the scrum part comes in, is in that design, develop, and test. That’s really what we’re talking about is working through those in an iterative fashion and then employing spiral methods of building the little pieces, playing it back in validation, doing a little bit more and then running through the SDLC many, many times within a two week sprint and certainly many, many times within a delivery cycle.

The traditional Software Development Life Cycle (SDLC) is a structured methodology for building software that follows a sequential, step-by-step process. It typically begins with requirements gathering and analysis, moves into system design, then proceeds to implementation (coding), testing, deployment, and finally maintenance. Each phase must be completed before the next one begins, making it a “waterfall” style approach that emphasizes thorough documentation, clear deliverables, and upfront planning. While this method provides predictability and control, it is often criticized for being rigid, slow to adapt to changing requirements, and less suited for today’s fast-paced, iterative development environments.

How Can StyleBI Be Used to Do Better Than the Traditional SDLC?

The traditional Software Development Life Cycle emphasizes rigid phases and heavy documentation, which often creates bottlenecks and limits adaptability. In contrast, StyleBI can be used to streamline the cycle by introducing agility and flexibility into how requirements are gathered and fulfilled. Instead of waiting weeks or months for IT teams to develop and deliver reports, end users can rapidly prototype dashboards themselves, reducing the back-and-forth between business stakeholders and technical staff. This shortens the feedback loop, ensures that the delivered output reflects actual business needs, and helps organizations avoid the “big reveal” problem where a finished product does not match expectations.

Another way StyleBI improves upon the traditional SDLC is by supporting iterative development. Dashboards and reports in StyleBI are not static deliverables but living artifacts that evolve alongside business needs. Teams can start with a simple prototype and expand it incrementally as requirements become clearer. This agile approach minimizes wasted effort and allows businesses to respond quickly to changing priorities or market conditions. Where the traditional SDLC locks teams into long development cycles, StyleBI fosters an environment where progress is continuous and adaptive.

StyleBI also reduces dependency on technical intermediaries, which is a common pain point in the waterfall model. Because of its drag-and-drop interface and self-service design, business users can build, modify, and explore reports on their own. This decentralization speeds up delivery and prevents bottlenecks, since insights no longer have to wait for IT schedules or specialized coding skills. At the same time, IT teams benefit because they can focus on maintaining data quality and governance rather than being tied up in routine reporting tasks. This redistribution of effort creates a more efficient and collaborative development environment.

Continuous validation of data and outcomes is another area where StyleBI surpasses the traditional SDLC model. In waterfall-style development, testing often happens late in the cycle, which can delay the discovery of problems. With StyleBI, users interact with data in real time and validate insights as they are built. This immediate feedback ensures that errors, mismatched requirements, or misinterpreted data definitions are caught early, avoiding costly rework. The platform’s interactivity transforms testing from a final stage into an ongoing practice that improves accuracy and builds trust in results.

Ultimately, StyleBI aligns better with the dynamic realities of modern business than the rigid SDLC model. By enabling iterative development, empowering business users, and shortening the feedback cycle, it ensures that analytics projects stay relevant, accurate, and actionable. Instead of treating BI initiatives as long, inflexible projects, companies can use StyleBI to make analytics development an ongoing, collaborative process. This not only accelerates time-to-value but also cultivates a culture of continuous improvement that traditional methodologies struggle to achieve.

Previous: Requirements for a BI Reporting Platform

Next: The BI Layer: Visualization