We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Kimball versus Inmon Approach

Originally published February 18, 2014

Today, people inside companies look to have a “quick win” with a rapidly implemented Kimball-designed business intelligence (BI) solution that is “good enough.” Most often, this represents a missed opportunity and comes with higher risk. Local optimization, “silos,” are costing businesses in expensive, yet not readily observable ways. This approach, often called the Kimball approach, results in redundant assets that must be managed.

Best practices suggest an organization would be best served by an enterprise architect with whom the BI architect collaborates on their project. The enterprise architect (using the Inmon approach) ensures the enterprise data warehouse (EDW) is in third-normal form, data relationships are accurately represented, and all data sources are appropriately rationalized and integrated. This step must be done before a BI project can consume disparate data. So, the EDW must be built first, which gives the Inmon approach more weight and value.

The least risky time to use the “bottom-up” approach is when there is only one data source. Still, this would not negate the need for the BI architect to collaborate with the enterprise architect, who should have project oversight so that data objects can be leveraged in future projects. Also, the enterprise architect should examine the source data to determine if it already has been integrated into the EDW. If it has not been integrated, it should be examined to see if it shares like-named objects as already exist. A BI architect cannot know everything about the enterprise and is foolish to believe the current and future states of all enterprise data objects and relationships are within his or her purview.

The whole point is: It is essential for a BI project’s design (i.e., Kimball approach) to have collaboration with the enterprise architect (the Inmon approach) from the time of project inception! Data is an enterprise asset.

There are two benefits for doing so:

  1. To plan future enhancements, flexibility and scalability, the enterprise architect needs to vet a project’s design against the “as is” and “to be” EDW design, since it is always a work in progress. It is the enterprise architect’s job to review the BI design for strategy and adherence to best practices.

  2. To avoid costly BI project rework since an exclusive “bottom-up” approach may result in redundancy or, at the very least, incomplete corporate data being reported. In either event, how much more would the project cost before it would start being regarded as “value-added”? How long might it take before incomplete corporate data becomes noticed? I’ve seen this happen for many months before discovery!
So, when should the Inmon approach be used versus the Kimball approach? If what is required is having the authoritative system of record – a long-term foundation of believable data – then one would use the Inmon approach; if that's not the case, the Kimball approach works well.

Really, it’s not about egos, whose idea it was, or who wants kudos for a job well done.

It’s all about us working together when we should. Ultimately, it is about doing the right thing for the enterprise – the company as a whole.

  • Deborah Arline

    Deborah is an independent consultant in Seattle, Washington, with over 30 years’ IT architecture experience in many different verticals including e-commerce, engineering, financial services, health care, energy and wireless communications.

     



 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!