Development Approaches

Almost every kind of engineering project ”structural engineering as well as software engineering ”goes through six stages between inception and implementation, as illustrated in Figure 0.1.

Figure 0.1. Engineering Stages

As the arrow in Figure 0.1 indicates, engineering processes are iterative. Once deployed, a product is continually improved and enhanced based on the feedback from the business community that uses the product. Each iteration produces a new product release (version) as the product evolves and matures. (This release concept is explained in detail in Step 16, Release Evaluation.)

Stage 1.	Justification: Assess the business need that gives rise to the new engineering project.	Stage 4.	Design: Conceive a product that solves the business problem or enables the business opportunity.
Stage 2.	Planning: Develop strategic and tactical plans, which lay out how the engineering project will be accomplished and deployed.	Stage 5.	Construction: Build the product, which should provide a return on investment within a predefined time frame.
Stage 3.	Business analysis: Perform detailed analysis of the business problem or business opportunity to gain a solid understanding of the business requirements for a potential solution (product).	Stage 6.	Deployment: Implement or sell the finished product, then measure its effectiveness to determine whether the solution meets, exceeds, or fails to meet the expected return on investment.

The Traditional Development Approach

Since BI is an enterprise-wide evolving environment that is continually improved and enhanced based on feedback from the business community, the system development practices of the past are inadequate and inappropriate.

In the past, systems were never designed or built with integration in mind. Every system had a beginning and an end, and every system was designed to solve only one isolated problem for one set of business people from one line of business. The old "single- swim-lane " development practices were suitable for such static stand-alone systems. However, they are not well suited for integrated BI initiatives because the old practices do not include any cross-organizational activities necessary to sustain an enterprise-wide decision-support environment. In the past, cross-organizational activities were not only deemed unnecessary but were also perceived to stand in the way of progress because they slowed down the projects.

For nonintegrated system development, conventional waterfall methodologies are sufficient. They provide enough guidance for planning, building, and implementing stand-alone systems. However, these traditional methodologies do not cover strategic planning, cross-organizational business analysis, or evaluation of new technologies with every project; nor do they embrace the concept of application releases. Traditional methodologies typically start with a functional business need, then concentrate on design and development, and finally end in maintenance, as illustrated in Figure 0.2.

Figure 0.2. Conventional Waterfall Deployment

Unlike static stand-alone systems, a dynamic, integrated BI decision-support environment cannot be built in one big bang. Data and functionality must be rolled out in iterative releases, and each deployment is likely to trigger new requirements for the next release, as shown in Figure 0.3.

Figure 0.3. The BI Application Release Concept

Figure 0.3 highlights other major differences between BI applications and stand-alone systems.

• BI applications are mostly driven by business opportunity rather than business need.

• BI applications implement a cross-organizational decision-support strategy rather than departmental decision-support silos .

• BI decision-support requirements are mostly strategic information requirements rather than operational functional requirements.

• Analysis of BI projects emphasizes business analysis rather than system analysis, and analysis is the most important activity when developing a BI decision-support environment.

• Ongoing BI application release evaluations promote iterative development and the software release concept rather than big-bang development.

The Cross-Organizational Development Approach

With the expansion of e-business comes an increasing demand for cross-organizational integration. This integration does not refer merely to bridging old systems across different platforms using enterprise application integration (EAI) middleware. Instead, it refers to:

• Information consolidation

• Information integration

• Information integrity

• Seamless business functionality

• Streamlined organizational business processes

Moving an organization from a "single-swim-lane" development approach to a cross-organizational, "cross-swim-lane" development approach requires organizational changes, including a culture shift. No other initiative demonstrates this as vividly as customer relationship management (CRM). If organizations would implement more cross-organizational BI operational applications (front-office as well as back-office) like CRM, they could significantly reduce their construction efforts on BI decision-support applications.

Although in Business Intelligence Roadmap we do not address organizational changes and culture shifts, we do define the necessary BI project activities that support an integrated enterprise-wide infrastructure. Both technical infrastructure and nontechnical infrastructure are required core competencies for cross-organizational integration. In addition to defining project activities, we identify the roles and responsibilities to be assigned to project team members for each development step.

The development steps outlined in this book form an engineering roadmap that provides a framework for developing different kinds of BI decision-support projects. The flexible entry and exit points of this framework allow you to start with any step as long as you meet the "entry criteria" outlined in the Entry and Exit Criteria and Deliverables Matrix. We also designed these steps to be agile and adaptive so that you can organize and manage the development of a BI application as multiple subprojects, each going through several of its own iterations or releases. For example, Figure 0.4 shows two iterations each for the Extract/Transform/Load (ETL), Application, and Meta Data Repository subprojects .

Figure 0.4. Iterative Subprojects of an Application Release

The approach presented in Business Intelligence Roadmap encourages the use of parallel development tracks (subprojects) so that multiple development steps can be performed simultaneously and multiple project activities can occur concurrently. Some project teams may choose to roll up project activities from multiple development steps into one step, while other project teams may not need to perform some steps or activities at all. Figure 0.5 illustrates the dynamics of a typical BI decision-support project, showing several steps running simultaneously (such as Step 5, Data Analysis, and Step 6, Application Prototyping) and multiple iterations of the same step (such as Step 9, ETL Design).

Figure 0.5. The Dynamics of a BI Decision-Support Project