Q:

When it comes to the design technology of enterprise data warehouse (EDW), some people are insisting we use Inmon's approach of top-down methodology. What are the basic criteria one should take in considering this type of approach and what are the specific drawbacks in Inmon's approach?

A:

Larissa Moss’ Answer: Bill Inmon’s approach to data warehousing is a holistic data management approach, not an approach for providing stovepipe solutions. In other words, a holistic data management approach recognizes the many different types of decision support requirements all organizations have, such as operational reporting, operational ad hoc querying, tactical management reporting and strategic trend analysis reporting. This approach allows organizations to evolve into an integrated and standardized decision support environment that provides solutions for all of these requirements. This involves many different types of databases (and database design schemas, i.e., not every database has to be multidimensional), such as ODS, EDW, data marts, oper marts, data mining databases, and so on. It also includes many different types of applications, an implementation strategy for the organization, and data standards to avoid uncontrolled redundancy. The "drawback" (although I would not call it that) is that it takes longer to build a holistic decision support environment than to build stovepipe data marts for different sets of requirements without any consideration of standardization or integration (which includes reducing redundancy) across the organization. The end effect of stovepipe solutions is that they add to the non-integrated spaghetti chart of systems (thus adding to the redundancy) that already exist in most organizations. And the large the spaghetti chart the harder it will be to manage your data as a true corporate asset.

Scott Howard’s Answer: A funny thing happened on the way to the warehouse! I used to be among those who insisted on Inmon’s approach until this very week. I started as a disciple of Kimball believing in his decentralized, more bottom-up approach because of his compelling and obvious arguments citing quicker implementation, cheaper approach, thus realizable ROI. It was too obvious not to support and attempt. However, every implementation I led, though initially a success, eventually turned to chaos as both professionals and users found ways around the rigid meta data management scheme that was needed to ensure the decentralized dimensions remained conformed. This was not to mention the gradual introduction of all the varying metrics used throughout most enterprises.

My next step was to hop on the Inmon express. I realized the benefits of the rigid, more expensive, centralized approach in which all input to the data marts must first be physically instantiated in a central or enterprise data warehouse. No data in the data mart classified as "enterprise class" could be sourced by the data marts from any other place. Experience showed that the extra effort and expense was justified. I started to use the Inmon top-down approach as the model for all my DW projects, modifying as business needs dictated. All of these efforts were successful though expensive. I was a convert.

I just concluded another engagement during which I had a true revelation. I was bought in to help an experienced DW team architect their EDW after an expensive failed attempt – which, mind you, was not due to lack of a well-planed architecture and a lot of very intelligent and diligent effort. Unbeknownst to me a second architect, a full-time professional at the firm, was doing the very same thing. I suppose the organization viewed the two of us as a form of checks and balances. I was a converted Inmonite while my secret counterpart was a true Kimballer. Independently and unaware of each other’s efforts, we came up with IDENTICAL proposals! I then realized that it didn’t matter which approach one begins with, success relies on good analysis of the business problem, the business need and business drivers including local politics, policies and practices. That complete understanding and only that understanding will lead to a successful implementation. Both the Inmon top-down and the Kimball bottom-up approach in the wrong hands will lead to failure, but either one in the right skillful hands...well you get the point.

Joe Oates’ Answer: In my experience, if an enterprise-wide data warehouse is to be developed, Inmon is right in saying that a top-down methodology should be a major component of the process. However, developing an enterprise-wide data warehouse design that can be queried across departmental and business unit boundaries requires experience and skills that few organizations have in house.

See my answer in the archive about the disadvantages of the bottom-up approach. The drawback to the top-down enterprise-wide approach most mentioned include the time required, the costs, management impatience to see results, lack of experience and skills, political issues and the difficulty in gathering requirements. This is why so many organizations have implemented the bottom-up, independent data mart approach. The costs of this approach are low enough so that a business unit can fund an independent data mart without having to go before the board of directors or other such body. Thus, the business unit can avoid the political hassles that go with an enterprise-wide approach.

It would be ideal to have an inventory of integrated enterprise-wide data warehouse design components that have already been tested for your particular industry. Then an organization could build an enterprise-wide data warehouse by selecting the components to solve the analytic problems for the first business unit, and when that was done, pick out some more components and add them to the first project to handle the needs of the second business unit. This process could then be repeated, business unit by business unit, until at some point in the future, there would be a central enterprise-wide data warehouse based on an integrated design.

Alas, creating an integrated enterprise-wide data warehouse design is a very, very, very difficult task. Few organizations, including leading consulting firms, have the people in-house who can do such a task. Today, an enterprise is not necessarily in just one industry. For many multi-national and other organizations, the enterprise consists of several different business lines.

There have recently been some discussions about a "pre-fabricated" data warehouse concept. These pre-fabricated data warehouse designs are an inventory of proven, customizable, integrated components for an industry or group of industries that can be assembled in many different ways. Such a solution overcomes the major objections to the enterprise-wide development such as long lead-time, cost, lack of experience and skills. If ERP vendors can say they have such a solution for the operational side of organizations, it follows that a similar solution should be available for the analytical side.

The Sybase Business Intelligence Division has developed such a pre-fabricated data warehouse design. It is called the Industry Warehouse Studio. The URL is http://www.sybase.com/products/bi/industrywarehousestudio. It has been successfully implemented in many different organizations around the world. But it is not magic. A lot of hard work has to be done, but it is far less than starting from scratch if the goal is to have a central enterprise-wide data warehouse that can provide a single version of the truth.

Chuck Kelley’s Answer: I think the Corporate Information Factory is an excellent choice in delivering a enterprise data warehouse. The biggest drawback is that you will have some amount of duplicated data which will add to the cost of the overall system. With near-term storage and the price of DASD (direct storage access device or a disk) going down, I would think this would become less and less a concern. The other drawback is that it takes longer to process the data downline (to the data marts). The other option (data warehouse is the sum of the data marts) has drawbacks as well. These drawbacks include enforcing central control on multiple organizations, added network bandwidth, etc.

Clay Rehm’s Answer: The top-down approach assumes many things. It certainly can be accomplished; however, you must be aware of people who do not want to integrate or share their data. The top-down approach assumes everyone wants to share and play well together.

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

Don't have an account? Register for Free Unlimited Access