Welcome Guest. | Log In| Register | Membership Benefits

Intelligent Enterprise

Better Insight for Business Decisions

Home
Digital Library
Events
RSS | Newsletters
Webcasts

September 17, 2003

The Bottom-Up Misnomer

Our data-warehousing approach is sometimes referred to as bottom-up, but it's far from it

by Margy Ross & Ralph Kimball

The Kimball methodology of building a data warehouse is often called a bottom-up approach. This label, along with its associated connotations, is misleading, and misunderstandings about our approach are proliferating. It's time to set the record straight: Although our iterative development and deployment techniques may superficially suggest a bottom-up methodology, a closer look reveals a broader enterprise perspective.

Enterprise vs. Departmental Focus

The bottom-up terminology originated to distinguish the Kimball approach from other alternatives. Bottom-up is typically viewed as quick and dirty — focused on the needs of a single department rather than the enterprise.

But suggesting that Kimball dimensional models or data marts are built to serve the needs of a single department or workgroup is a gross misrepresentation. Unfortunately, this perception causes an enormous amount of confusion and consternation, in addition to spawning criticism regarding our techniques. Our dimensional models and data marts explicitly embrace an enterprise point of view.

Vertical and Horizontal

For more than 20 years, we've been helping organizations publish their data assets to enable better strategic and tactical decision-making. Our focus on business requirements has remained steadfast. Unfortunately, a business-centric approach is sometimes seen as synonymous with building independent departmental or workgroup solutions. However, we provide very specific recommendations for avoiding that snake pit both in The Data Warehouse Toolkit and The Data Warehouse Lifecycle Toolkit. When gathering business requirements, we encourage you to broaden your perspective both vertically and horizontally.

Rather than solely relying on business data analysts to determine requirements, you should also meet with senior managers to better understand their vision, objectives, and challenges. Ignoring this vertical span leaves the data warehouse team vulnerable to here-and-now myopia — a failure to grasp the organization's direction and likely future needs.

Keep in mind that you also need to look horizontally across the organization before designing a data warehouse's dimensional presentation. This suggestion, although somewhat challenging to adopt if a single department is funding the project, is absolutely critical to establishing the enterprise view. Ignoring the horizontal span leaves the team vulnerable to isolated, workgroup-centric databases that are inconsistent and can't be integrated. Obviously, no one expects complete coverage in a large organization; however, you should meet with representatives from related departments, as they often share needs for the same core data.

Enterprise Bus Matrix

The enterprise bus matrix reflects the enterprise's core business processes or events, in addition to the common dimensional reference data. Both the rows and columns represent cross-departmental requirements. You can learn more about this technique in "The Matrix," Dec. 7, 1999.

In the simplified bus matrix in Table 1, the rows identify a subset of the primary business processes within an insurance company. The rows were uncovered while gathering information about the company's business requirements by asking about strategic business initiatives. The effectiveness of these initiatives is measured by key performance indicators (KPIs) and success metrics, which are collected or generated by the organization's core business processes, such as underwriting, billing, and payment processing. Typically, a single primary data source supports each business process; the resulting KPIs and metrics from each process are used in a variety of analyses.

The columns are also culled from the requirements gathering sessions. As we explore the business representatives' decision-making process, we listen for "by" and "where" words to gain insight to natural analytic groupings. For example, business managers may want to look at claims payments by policyholder, agent, and coverage; each represents a core dimension or dimension attribute. Or they may want to analyze payments where the agents have more than five years of experience and work in the Eastern region. By listening to their word choices, we gather clues about dimensions and their attributes.

Drafting the enterprise bus matrix is an iterative process: After each business requirements gathering session, the matrix is fine-tuned to reflect new insights. By the time the requirements process is winding down, we've arrived at a surprisingly complete matrix. In fact, when no changes to the matrix are made following a session, we know the requirements process is likely nearing the end.