This post is part of a Methodology discussion – other posts will follows. I will be happy to get your feedback!

I am proud to announce a public draft of the first paper about the SQLBI Methodology. I and Alberto Ferrari tried to define a consistent methodology which covers the construction of the back-end of a BI Solution using Microsoft SQL Server and its complementary services. Now, we are looking for comments and feedback about it.

But, wait. Is this “yet another data warehouse methodology”? It depends from your point of view, because it strongly inherits concepts from both Kimball’s and Inmon’s methodologies, but it also includes concepts that are very specific to serve a multidimensional database like Analysis Services. However, before you start to read the whole paper, we start to make a fast comparison in this post between different methodologies we are talking about.

On the web, there are plenty of discussions regarding the Inmon vs Kimball debate. Both authors have fans that seem to believe that the choice between the two approaches to a data warehouse project is much more a religious war than a technical decision.

We (I’m writing these posts with Alberto Ferrari) do not want to start another war with this post, mainly because we do not believe that such a war has any reason of being, as is the case with any religious war.

Both Inmon and Kimball developed methodologies that work well in different kind of data warehouses. However, there are situations where the Kimball approach brings a fast and effective data warehouse and there are others where the Inmon approach leads to a cleaner solution. Both methodologies have drawbacks too and this post is not the right place to list all of them.

What is really important, in our opinion, is something else. If you choose the wrong approach, you will discover (usually too late) that you cannot complete your data warehouse project on time and on budget. Moreover, since the requirements in the BI world change frequently, it is often the case that you have to choose the methodology when the real requirements are still not clear.

Having worked with both methodologies for different projects, we believe that a careful analyst should take a different approach other then the “religious war”. For example, it would be a good idea to use the best of both methodologies, starting with the easier Kimball method but being ready to introduce Inmon structure if and when needed.

Our experience is that a clean analysis of the entire BI solution (including the data warehouse) can produce a very effective database and a set of ETL procedures that will let you get the best from both methodologies. Most important, this can change the general approach. The ability to change idea very late in the data warehouse building is very important, because it will let you follow the user requirements even when they deeply change.

If all the ETL process is designed with a strong and clean architecture, then it is possible to switch from Kimball to Inmon, in a smooth and easy way. Clearly, this is feasible if and only if you start – from the beginning – with a mixed approach in mind. This mixed approach is the one that is described in the first paper about the SqlBI methodology, downloadable here.

As said at the beginning, since this is the first public draft of the paper, we will be glad to receive feedback about it. You can contact us directly and you can also participate in the dedicate forum SQLBI Methodology forum.