In addition to the traditional warehouse structures and BI-centric tools, there are other aspects of your BI organization for which you must plan, such as:
- Customer touch points. As with any modern organization there exist a number of customer touch points in which to influence a positive experience for your customers. There are the traditional channels such as dealers, telephone operators, direct mail, multimedia, and print advertisement, as well as more contemporary channels such as email, and the Web. Data produced at any touch point must be acquired, transported, cleansed, transformed, and then populated to target BI data structures.
- Operational databases and user communities. At the opposite end of the customer touch points lies a firm’s application databases and user communities. Existing here are traditional data that must be gathered and blended with data flowing in from the customer touch points in order to create the necessary informational content.
- Analysts. The principal beneficiary of the BI environment is the analyst. It is this person who benefits from the timely extraction of operational data, integrated with disparate data sources, enhanced with features such as spatial analysis (geocoding), and presented in BI technology that affords mining, OLAP, advanced SQL reporting, and spatial analysis. The primary interface for the analyst to the reporting environment is the BI portal. However, the analyst is not the only one to benefit from the BI architecture. Executives, broad user communities, and even partners, suppliers, and customers can and should share in the benefits of enterprise BI.
- Back-feed loop. By design, the BI architecture is a learning environment. A principle characteristic of the design is to afford the persistent data structures to be updated by the BI technology used and the user actions taken. An example is customer scoring. If the marketing
department implements a mining model that scores customers as likely to use a new service, then the marketing department should not be the only group that benefits from that knowledge. Instead, the mining model should be implemented as a natural part of the data flow within the enterprise, and the customer scores should become an integrated part of the warehouse informational content, visible to all users.
IBM’s suite of BI-centric products—including DB2 UDB, DB2 OLAP Server, Intelligent Miner, and the Spatial Extender—encompasses the vast majority of important technology components, defined in Figure 1.1. We use the architecture shown in this figure throughout the book to give us a level of continuity and to demonstrate where each IBM product fits in the overall BI scheme.
Figure 1.1 The BI organization.
Providing Information Content
Planning, designing, and implementing your BI environment is an arduous task. Planning must embrace as many current and future business requirements as possible. The design of the architecture must be equally comprehensive in order to include all conclusions found during the planning phase. The implementation must remain committed to a single purpose: building the BI architecture as formally presented in the design and founded on the business requirements.
It is particularly difficult to maintain the discipline and political will to ensure its success. This is simply because building a BI environment is not done all at once, but by implementing small components of the environment iteratively over time. Nevertheless, being able to identify BI components of your architecture is critical for two reasons:
- It will drive all subsequent technical architecture decisions.
- You will be able to consciously plan a particular use of a technology even though you may not get to an iteration needing the technology for several months.
Sufficiently understanding your business requirements will, in turn, affect the type of products you purchase for your technical architecture. Planning and designing your architecture ensures that your warehouse is not a haphazard event, but rather a well-thought-out, carefully crafted mosaic of blended technology.
Planning for Information Content
All initial planning must focus on identifying critical or core BI components that will be necessary to the overall environment, present and future. The rationale for even starting a BI effort is driven by known business requirements. Even before any formal planning begins, the architect or project planner is often able to identify one or two components right away. The balance of the components that might be necessary for your architecture, however, may not be as easily identified.
During the planning phase, architects lead joint application design (JAD) sessions on a quest to identify business requirements. Sometimes these requirements can be addressed with little more than querying and reporting tools. For example, users state they want to automate a report they currently have to create manually by integrating two existing reports and adding derived calculations of the combined data. Although this requirement is straightforward, it does define some feature functionality that you must include when purchasing the reporting tool for the organization. The project planner or architect must also pursue additional requirements to gain a complete picture. Do the users want to subscribe to this report? Are subsets of the report to be created and emailed to various users? Do they want to see this report over the corporate portal? All of these requirements are part of the simple need to replace a manual report as requested by users. The benefit of these types of requirements is that everyone, users and project planners, is familiar with the concept of reports. And the architects are well versed on the type of technology that exists to support these efforts.
There are other types of business requirements, however, that we must plan for. When business requirements are stated in the form of strategic business questions, it is easy for the experienced architect to discern dimensional and measure/fact requirements. Figure 1.2 illustrates the dimensional and measure components of a business question. If JAD participants don’t know how to state their requirements in the form of a business question, architects will often give examples to jump-start the requirements-gathering session. The experienced architect is able to help user communities to not only understand what strategic business questions look like but also how to form them. Requirement-gathering approaches are discussed in Chapter 3; for now we merely want to point out the need to plan for all types of requirements as early in your BI effort as possible.
Figure 1.2 Dimensional business question.
A strategic business question is not only a business requirement but also an architectural clue. If you need to answer a multidimensional question, then you need to store and present data dimensionally. And if you need to store multidimensional data, you need to decide what type of technology or technique you are going to employ. Do you implement a Star schema, a proprietary cube, or both?
As you can see, even a simple business question can drive considerable planning. But these types of business requirements are commonplace and well understood, at least by experienced architects and project planners. There has been sufficient debate on OLAP technologies and support, and a wide range of solutions are available.
|
