View online: tdwi.org/flashpoint
April 1, 2010
ANNOUNCEMENTS
Applications for the 2010 Best Practices Awards are due April 26. Click here to apply.
Submissions for the next Business Intelligence Journal are due May 21. Submission guidelines.
Exclusive Member-only Q1 2010 publications are now online.
- 2010 TDWI Salary, Roles, and Responsibilities Report
- Business Intelligence Journal, V15N1
- Ten Mistakes to Avoid When Driving BI Adoption and Managing Change
CONTENTS
The Hidden Value of
Dimensional Design
Mistake: Lack of Executive Involvement
See what's
current in TDWI Education, Research, Webinars, and Marketplace
The Hidden Value of
Dimensional Design
Chris Adamson
Oakton Software LLC
Topics:
Dimensional Design, Business Requirements
Data warehousing professionals often struggle to effectively set expectations for both short-term projects and long-term plans. One of the most powerful tools at their disposal is so simple that it is often overlooked: a dimensional model.
A dimensional model communicates with both business users and technical personnel. It brings them together in a way that allows balanced consideration of development priorities. As the basis of project scope, a dimensional model provides a shared understanding of system capabilities and implementation efforts.
To achieve these benefits, forget that dimensional design is a design-stage activity. Instead, think of it as a system for capturing and defining requirements.
Defining Requirements
The definition of business requirements in dimensional terms is surprisingly simple. There are four initial components:
- Definitions of major subject areas within the business
- Enumeration of discrete processes and subprocesses within each subject area
- For each subprocess: definitions of specific measurements and their context at the most detailed level
- A cross-reference of measurement contexts across subject areas
As the core of a statement of requirements, these components are immediately understood and interpreted by business and technical audiences. If you are already familiar with dimensional design, the components should look familiar. Each corresponds to a central feature of your dimensional design:
- Subject areas correspond to data marts or projects
- Processes correspond to individual stars, snowflakes, or cubes
- Measurements, context, and detail correspond to facts, dimensions, and grain
- The cross-reference corresponds to a conformance plan for dimensions
This information conveys functional objectives. Four additional components will help assess the effort required for implementation:
- Dimension table detail, including natural and surrogate keys, standard levels of summarization, and significant hierarchies to be leveraged by BI or OLAP tools
- Fact table detail, including type, grain, stored facts and their additivity characteristics, and explanation of non-additive facts
- Column-level detail, including data source(s), business rules that guide transformation, and information about how to respond to changes in source data
- Table profiles, including load frequency, planned data volumes, and security considerations
Addressing Two Audiences
The business requirements fall along two axes: business capability and implementation complexity. Business people can understand what functionality will be delivered, and IT personnel have sufficient detail to assess the effort required to deliver each piece.
Because it supports these dual perspectives, a dimensional design is tailor-made for planning strategy. Functionality and level of effort are easily assessed; business and IT can work together to subdivide implementation plans and establish priorities.
The dimensional design is also a natural sounding board for change requests. This is particularly valuable in environments that leverage an agile approach to data warehousing or follow an iterative methodology. From a dimensional perspective, some changes will provide minimal disruption. Requests such as the following may require additional time and resources but will not have extensive impacts:
- Changes that require the addition of columns to a dimension table (without upsetting hierarchies or conformance properties)
- Changes that require the addition of facts to a fact table (without altering its grain)
- Adjustment of the business rules required to process an attribute
Other proposed changes will alter dimensional scope. These will require significant additional resources. For example:
- Increasing the number of data sources
- Increasing the number of stars to be built
- Altering the grain of a planned fact table (or cube)
Beyond the Model
Dimensional information is not the sole mechanism for defining requirements and scope. A model can be supplemented with other kinds of requirements that communicate deliverables, functionality, or technical complexity.
The most common examples are specifications geared toward specific “information products” such as reports or dashboards. These correspond to discrete deliverables. Like the model, they communicate functional and technical aspects of scope. Others include solution characteristics (such as latency or security) and architectural requirements that may be more technical in nature.
Other Benefits
There are other valuable benefits to the up-front development of a dimensional design. It helps ensure compatibility across subject areas. This allows you to avoid incompatible data marts, or “stovepipes.” Mapping the design back to source data also ensures that your plans are achievable. This dramatically reduces project risk.
Never lose sight of the fundamental benefit of your dimensional model: you can use it to manage the expectations of business and technical personnel alike.
Chris Adamson provides strategy and design services through his company, Oakton Software LLC. He teaches dimensional design at TDWI conferences and through TDWI’s Onsite Education program. His latest book is Star Schema: The Complete Reference, coming in July from McGraw-Hill.
Highlight of key findings from TDWI's wide variety of research
Adoption of BW
Of the small minority of respondents who evaluated and rejected BW, the survey asked: “Why did you reject SAP NetWeaver BI?” (See Figure 14.) By far, the leading reason for rejecting NetWeaver BI and BW is the preference for “an independent data warehouse” (70% of respondents). Note that this reason is about data warehouse architecture or the desire to leverage a preexisting EDW investment. In other words, it’s not a complaint about BW. However, the remaining users offered reasons such as “we follow a best-of-breed strategy,” “didn’t fit our requirements,” and “too expensive” (each was selected by 50% of respondents). Multiple respondents selecting “other” entered comments about BW’s lack of flexibility.
Source: Business Intelligence Solutions for SAP (TDWI Best Practices Report, Q4 2007). Click here to access the report.
FlashPoint Rx prescribes a "Mistake to Avoid" for business intelligence and data warehousing professionals.
Mistake:
Lack of Executive Involvement
By Karen Degner
“An army of a thousand is easy to find, but, ah, how difficult to find a general.” —Chinese proverb
Lack of executive involvement in business performance management (BPM) is the kiss of death. BPM is a way of life, and it cuts up, down, and across organizational boundaries. It can dramatically change the way budgets are allocated, initiatives are funded, and resources are managed. It aligns activities such as strategic planning, business process management (the “other” BPM), operations, IT, and financial management. By its very nature, it requires leadership and influence to drive change throughout an organization. Without visible executive involvement, BPM will not be taken seriously and will soon face mortal difficulties.
Different groups have different goals, some of them conflicting. In the absence of explicit strategic direction, priorities are left to the interpretation of individuals. This results in a costly lack of focus, which ultimately creates barriers to the very integration and alignment foundational to BPM. It’s imperative to keep the big picture in mind and assist early adopters, usually finance or operations, to avoid introducing functional bias.
Think global; act local. Engage executives in the identification of strategic critical success factors and associated key performance indicators. Each subsequent phase should be in alignment with those objectives. This will help ensure that tactical steps will be taken within the overall strategy. BPM can begin at any level where there is an objective to meet and a budget to manage. Start small, educate, and demonstrate early value.
Source: Ten Mistakes to Avoid When Implementing Business Performance Management (Q1 2007). Click here to access the publication.
