After one of these articles comes out, a burst of e-mails agreeing wholeheartedly with everything that has been said quickly materialize. (Tongue firmly in cheek here.) Such was the case last month when the importance of business sustaining information was emphasized over a specific architecture. To review, there is no one “good” architecture or framework (you know, federated, atomic DW, etc.). Business needs must drive the appropriate framework. The design technique must be apolitical (not favoring a business group) and agnostic (not favoring a particular approach or framework).
The nature of most of the e-mail I received was to provide a bit more detail on the agnostic and apolitical approach. Therefore, we’ll explore how the intrinsic nature of business information usage provides the clues to the “correct” framework.
Attributes of Information Usage
If information is not used, it is a wasted asset. When a business intelligence (BI) project is initiated with the reason given as “better access to data,” what the business really is saying is saying is that they aren’t using information. It is there, but not used. Therefore, the first step to being apolitical is to take a broad-spectrum look at the enterprise requirement to use information. Even if a CRM project office or a finance vice president sponsors the BI project, it is key that some type of big picture be examined.
Examining enterprise usage is not too hard and does not require permission for some type of controversial enterprise analysis effort. Figure 1 illustrates a simple example of mapping business drivers to standard usages of information. The enterprise big picture will vary based on business drivers and industry context.
Usage is manifested in achieving objectives. The BI environment supports this through supporting and providing metrics and other information requirements. If you examine some generic business drivers and cross-reference them with generic information uses, it is easily seen that the type of business use of data generates situations where a measure (in italics in Figure 1) is used to fulfill a business goal. This is actionable use of information.
Figure 1: Mapping Business Drivers
Once a set of measures has been developed, the attributes of the measures are used to formulate the requirements for the framework. By attributes, I mean the various descriptors of what makes up a measurement. Figure 2 lists a subset of the ones I use when developing technical requirements. The attributes are scored on a relative scale of your choosing. Figure 3 shows an example using our three metrics from Figure 1. Once the measures have been scored, it becomes apparent how the characteristics of that measure and its context for use shape the BI framework that will support that measure. It is obvious that a blended set of data structures or frameworks would be required to efficiently support an enterprise spectrum of measures.
If it isn’t obvious, you can use a simple graph to show the distinctions between the different types of structures.
Figure 2: Subset of Technical Requirements
If we plot the various values from Figure 3 on a simple radar chart, we can see the obvious differences between the measures. Extrapolate this to several dozen measures, and you can see how measures of common characteristics can be identified. This way the most efficient framework can be created to deliver the measurement to the end user but within the scope of a master architecture that will be developed to support all measures.
Figure 3: Measurement and Scoring Matrix
If we look at a set of 50 or so measures, we may see the need for atomic data and summarized data. This means the architecture must support a central DW and a mart to be most efficient.
Once all measures are considered, specific projects can be rolled out to support subsets of the measurement, The development team can correlate the framework requirements to the applications to identify a series of iterations to implement new BI applications. As a bonus, the team can use the measures to identify ROI opportunities and build the business case.
Figure 4: Mapping Characteristics
The bottom line is that different structures are more efficient at meeting different needs. Different data “topologies” are required for different attributes. The essence of the entire exercise is to balance long-term total cost of ownership against business requirements. This gives the sustainable return on the DW investment. The data warehouse staff must eschew the search for the one ultimate answer to their framework and apply sound analysis.
Figure 5: Data Topologies
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access