One of the cornerstone technologies for enabling enterprise grade insights is the data warehouse. This has had many names adopted through the years, since the inception of the phrase itself by no other than Bill Inmon. (resource: Find out more on our resource page)

Having coined said phrase back in the 1970’s, with the goal in crafting a standard in which a companies data could be stored, accessed and used in order to provide a single source of truth in which describes and tell the story of said company.

Thus the great data warehouse religious wars began that pitted two strong willed and minded camps. Those whom would embrace the original author of the concept itself found themselves flying and fighting for the Inmon camp.

With this there was yet one more knight in which to battle until victory was claimed. If therefore you where not part of the Inmon camp then you found yourself digging in and amazed at the fact in which anyone would design for a company the construct that a data warehouse represents – no others than that of Ralph Kimball’s approach to the design of the coveted single semantic layer. This, as time progressed onward, would then in turn be called an enterprise data warehouse. Inferring with its name the single and solely accepted version of a companies truth, and that Kimball on a tone of 7/8-1 would be used in designing a companies prized semantic layer.

(pictured above is an example of the Ralph Kimball data warehouse architecure)

From a historical perspective there are plenty of websites that have been dedicated to the preservation of the great wars, it battles, outcomes and ultimate winners and losers. The goal of this post then is not to exhaust you by trudging through the past. If your interesting in finding out more about the historical impact of this great war we suggest diving into the following resource from zentut: Kimball vs. Inmon Data Warehouse Architectures.

Now having established an understanding of the past along with the fact that Kimball was the most used from the two camps, we can proceed forward to now were we find ourselves sitting, starring and dare say welcoming the age of the modern data warehouse and its underlying architecture. (resource: Microsoft Azure Modern Data Warehouse Home)

(pictured above is an example of the Microsoft Azure empowered modern data warehouse)

In this we have now established between us an understanding of what the data warehouse represents as well as a brief history in how the phrase itself was formed. Finally we can then look at the attributes comparing that of which has been called a data warehouse since its inception through to the changing wave we find ourselves riding upon in the current state of which has been dubbed ‘modern‘.

In this the traditional data warehouse, even more so before the advent or focus towards the cloud, existed as a highly structured and well define set of dimensional models. These dimensional models represent a set of facts and dimensions in which said facts are then employed via. Thus enabling a foundation across a companies many business processes that in turn allow for descriptive analytics to cast characters from and play out story lines that – in turn enable decision makers to act upon.

In relation then to the concept of the data warehouse with context based in today’s near-real time and streaming analytical wants; one could ponder and opine upon the desire nor need for such a past tense version of said data. If by its nature the existing data elements that arrive exist in past tense for its variations and semantically driven adjectives and verbs.

Once a data warehouse is established at a company, its value continues to expand at the rate in which said semantic layer is relied upon to enable critical decisions to be made. This implies that a certain level of maturity in how a company relates to its data must exist in order for desired value to be recognized. Once this is achieved – even if only for a single business area – then a natural cycle of usage starts to unfold for your company as it relates to its data warehouse.

A data warehouse is only  as valuable as to the rate in which it is trusted and adopted throughout a given company. 

With this then we correctly imply that a data warehouse is only as valuable as to the rate in which it is trusted and adopted. This is where the art and science of effective data story telling finds its place in the world.

Since its creation data warehouse and business intelligence projects in general have suffered through high rates of project failures. Such failures always come back to the two truths that set a data warehouse free. Trust and adoption. When these are the elements in which the measure of successful project(s) are based then upon – such BI and Analytical projects are able to capitalize and be considered successful investment for a company.

Part of the issue that plagued the earlier days, and at times even today, relates then back to one of the twin pillars of success. Specifically because the complexity in which exist in crafting a semantic layer for a company; at times only a handful of people would have access to a data warehouse or known at times as an EDW. (Enterprise Data Warehouse). Due to the rigid nature of such highly structured data, all too often such a project would be headed and sponsored within a company from the information technology departments.


This in turn would add to the failures rates that such data warehouse projects would suffer from. The very essence in which such a project is commissioned revolves around that of establishing a trusted source of a company’s truth that enables decisions makers within the company to take action from.

Technology has progressed at a rate now that many variations and options where crafted as a response to the general failures that where being reported – relating to data warehouse, analytics and business intelligence projects in general.

Such actions include, but are not limited too, end user frustration that lead to shadow IT operations that would enable specific departments to push towards solving their need for delivering upon critical insights that the failed EDW never was able to achieve for them. Thus creating a ‘bad taste” for many customers across our fair world.

What we have then in this new era of the ‘current modern’ approach to design and deployment of new technologies that are meant to help bridge the gap between business user and technologist.

This is the first part in our series covering the adoption and process by which current modern designs and models are being targeted in order to speed along and ensure more successful BI, Analytics and specifically data warehouse projects.

I will end this first part in our multi-part series, with the following guidance that I and my team at Arbela Technologies find true:

You can not buy business intelligence. It is not a tool, technology or set of design approaches and protocols. It is an on-going journey that finds its existence at the intersection of people, data and process. 

Next in this series we will continue to dive into depth of data warehouse projects and how you can near guarantee success through following an establish agile approach that is rooted in Mr. Ralph Kimball methodology. Finally how this process is the critical key for turning on effective data stories that build on the success of each other.

Until next time! 

Brandon George | | | | Master Data Story Teller


Iman · July 21, 2018 at 11:08 pm

Good one! From your experience how does the modern DW approach differently in area of data modelling and ETL?

Azure SQL options – The Arrival of the modern data warehouse – part 2 – Effective Data Story Telling via Microsoft Power BI · August 16, 2018 at 12:27 pm

[…] I wrote about the arrival of the modern data warehouse, per Microsoft Azure design concepts. In this I walked you through an introduction of what this […]

Leave a Reply

Your email address will not be published. Required fields are marked *