Today we are talking about “Is Quick Business Intelligence Better Business Intelligence?” And you may notice that I have taken the liberty to add a small question mark to the end of that title which is not in the original, and the reason I have done that will become clear as we go through the presentation. So let’s get moving.
So we are talking about the old BI conundrum, quicker or better, and that’s the source of the question mark. If you look at the world today, quicker and quicker and quicker seems to be the thing that is most interesting to people, and it's all about the business immediacy. It's all about getting action done. It's about short term goals. It's as if we are running on a stop watch.
And the way that that’s typically been done over the years has been through the use of data marts, with typically independent data marts. They are data marts, separate from the data warehouse or appliances. And that still continues today, and it is a very effective way of continuing today.
But if I went back to the past, the business focus often was on better more consistent, more quality data and really focusing on longer term gain and governance. This is what led to the development of an enterprise data warehouse. And people have joked in the past and said, ‘this is the Rolls Royce version of business intelligence.’ And so that is why you see a Rolls Royce logo here on this slide.
| #1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index |
|
Read More |
But if I go back with you to the very early days, to the beginning days of data warehousing, on the right hand side of this slide, you see the original or one of the early data warehouse architectures. This is a data warehouse model that we have used for years and one in fact that I drew myself in the early 90s. And back then, data consistency and quality was the original business driver for data warehousing.
Down at the bottom of this chat, you see little green boxes called operational systems. Most of you know them intimately and perhaps too well. And back then particularly, and I suppose some of you would say it’s still the same today, operational systems were multiple. They were disparate. They were inconsistent sources of data.
And so in the warehousing architecture that we developed in the late ‘80s, we conceived of an enterprise data warehouse which was modeled in a cross enterprise way. We created what we called a single version of the truth. That was our goal, and indeed it still is the goal in many instances today. You see then, of course, we then took that information for various performance reasons out of the enterprise data warehouse and made it available in data marts.
So that was the original architecture, and well, over the years architecture has developed. In this slide which you can say, is this an architecture or is it a spaghetti diagram? What we did was we added lots and lots of components in order to cater better for immediacy and action. We had the idea of having, and still have, of course, that idea of having near real time data availability. This is what led to the introduction of an operational data store. Operational BI is what it is called today. We had the need for fast analysis and decision making, and so we were looking at improving the performance of data marts. We needed better BI tools and improved visualization and rapid response to change. So this leads to the introduction of agile BI.
And of course we have an explosion of components and approaches from federated queries to data mashup, to cubes, to spreadsheets, to independent data marts, to staging areas, you name it. But the real question, of course, is how would we ensure consistency and quality in such an environment. So hold that thought, and let me bring you back to the user view. What would the business user choose?
Well, Freddie Mercury said it all in 1989 when he said, “I want it all, and I want it now.” Most of us know that that’s what our business users want. But I do pose this question to you: which would your users choose, the wrong answer immediately, the right answer too late, or “a sufficiently correct answer” soon enough to effect the outcome of decision making? And in my experience working with companies, with users and with IT people, generally, it's the last answer that they typically choose.