An obvious mistake architects and project sponsors make is associating BI and warehouse efforts to particular technologies. Too often, the notion of implementing an online analytical processing (OLAP) tool or building a star schema overshadows the rationale and purpose for these tools and techniques in the first place. Hopefully, it was a business requirement that drove project planners to recommend the use of OLAP, for example. It is important to understand that business requirements drive warehouse iterations and not the techniques used or technology implemented.
Nevertheless, the data architect or solution strategist must recognize when a particular technique or technology will be necessary. Moreover, these individuals must plan the overall BI architecture in advance of any iteration being implemented. This includes any data structures required to support the overall BI plan as well as predicting the type of technologies to implement. Architects and solution strategists must set into motion an inclusive picture, an encompassing agenda for virtually any combination of BI applications that might be necessary for their particular enterprise.
The core reason for establishing your BI vision in the form of a strategy document is to ensure that implementation of specific technology or a data structure (e.g., data mining or the establishment of an ODS) is not done in a haphazard manner. The project planners must understand what and where the technology or technique fits in their overall BI environment.
Implementing your BI organization as a big-bang effort has long been deemed a formula for disaster. Instead, BI environments are grown iteratively, addressing business requirements one at a time. Iterations, consequently, must remain focused and well defined to address specific business requirements. On the other hand, iterations must be assimilated into the long-term vision of the BI organization. Iterations are driven by specific requirements but guided by the broader, enterprise-wide road map. The conceptual diagram of the business intelligence organization as shown in Figure 1 serves as the basis for such a road map and all subsequent planning, including the basis of the strategic document.
Figure 1: The BI Organization Conceptual Architecture
Components of Your Strategic Document
There is often confusion regarding the content required in a BI strategy document. Much of the perplexity is due to the several competing methodologies for building data warehouses and supporting BI initiatives. From industry leaders to vendors, they all offer some approach that has proved successful. However, in all the various approaches and methodologies, there are a few topics that everyone agrees must be in your plan, including some variation of the following four views or components:
- Conceptual View
- Data Architecture
- Technical Architecture
- Implementation View
Each topic contains numerous opportunities for detail to be introduced. Even a high-level perspective such as the BI organization diagram (Figure 1) provides an excellent road map of your enterprise initiative and an opportunity for architects and project planners to define and describe, in some detail, the individual components.
There are some aspects of the overall strategy that can be addressed in detail, while other elements can only be dealt with at a very high level or conceptual perspective. However, because your BI strategy document is a "living" document, you will be able to continuously refine your enterprise road map with subsequent iterations of your warehouse. It should be your intent to update, modify or otherwise evolve your enterprise plan as you implement project iterations and more detail becomes available. For example, let's assume that we know data mining will be needed at some time in the future. We need to emphasize that fact and establish the standard for its use. However, we probably do not have any other detail about the mining tool or technology necessary. Consequently, we will wait until we have a specific iteration that would trigger such a decision to document the exact software to be implemented.
As previously mentioned, there are at least four major sections to your BI plan: conceptual view, data architecture, technical architecture and implementation view. Within each section, there are numerous topics that you could cover, from conceptual diagrams, to use-case views, to security to standards. What you ultimately include under each section will be largely driven by the size and scope of your BI initiative, your ability and authority to establish guidelines and your experience. The following content will describe some components you should consider for each core section when drafting your overall BI strategy.
There are at least five issues that can be addressed when defining your enterprise strategy within the conceptual view section, including:
Architecture goals and constraints. This topic provides a means for architects and planners to set overall goals and objectives related to the BI initiative. The establishment of any constraints that impact the BI effort must be defined as well. For example, the BI initiative may not be able to start until the new data center is complete, or the overall BI effort needs to begin with finance or our offices in the Pacific Rim.
Conceptual view. The BI organization conceptual diagram in Figure 1 is the type of view expected in this section as well as a brief discussion of each component illustrated.
Use-case view. A use case can be developed in order to formalize the intention of the BI initiative.
Be the first to comment on this post using the section below.