Part of a blog series.<\/a><\/em><\/p>\n A common story. A tragic story. An avoidable story. An insurance<\/a> company has recently marked retention as a Key Performance Indicator (KPI) for a new three-year thrust.<\/p>\n A C-level executive calls a kick-off meeting, and the agenda is set to discuss each department\u2019s contribution. Department heads vigorously prepare, but the enthusiasm is quickly dampened. They discover that each of the ten department heads has a separate version of the current retention rate. There is no discussion about improving retention, and the meeting devolves into an argument over which number reflects the \u201ctruth.\u201d<\/p>\n If you have worked around data warehouses for any length of time, I\u2019m sure you have similar stories. <\/strong>It turns out that there is a simple, but not easy, solution. Stated simply, \u201cProvide everyone with a single version of truth<\/em>.\u201d A simple goal, but even the definition is hard.<\/p>\n What is \u201ctruth?\u201d<\/p>\n A fact is a piece of information. That piece of information can be correct, or not. That piece of information can be shared by all, or not. The systems that load a data warehouse will usually have steps in place to conform and clean facts. But there are questions we should ask:<\/strong><\/p>\n Truth is a little harder to define. Philosophy may try to convince us that there is no truth. I like to define truth by looking at an ancient Chinese slogan \u201csh\u00ed sh\u00ec qi\u00fa sh\u00ec” meaning “Seek truth from facts.” A dictionary describes truth as a statement or principle that is generally considered to be true.<\/p>\n In a data warehouse, truth is an agreed-on interpretation of facts<\/strong>. A universally accepted truth must be built on accepted facts and an accepted formula or interpretation. We should ask the same questions of truth that we ask about facts. Get a single version of facts with a single interpretation into truth and have confidence in conclusions. Simple, right?<\/p>\n So, why do so many companies struggle to achieve this simple goal? Answers to these five questions usually provide clues:<\/strong><\/p>\n What is the solution? This is by no means an exhaustive list, but let\u2019s look at four concepts today:<\/strong><\/p>\n The only way to ensure that the appropriate facts and truths are complete, correct and relevant is through Data Governance<\/a>. Data is one the most valuable commodities a company has. Yet too often data is resource-starved.<\/p>\n I was recently working with an insurer to review their data warehouse architecture. This insurer had spent hundreds of thousands of dollars, with one of the Big 4 consulting companies. The insurer had the right goal. They wanted to get their information into a trusted and usable format for self-service reporting and analytics. This insurer trusted this major consulting company to lead them in the right direction.<\/p>\n Only after delivery did the insurer realize that the “data warehouse” wasn’t built for the business to use but built to help the consulting company with its other work. The structure was too complex. There was no way for anyone on the business side to use the “data warehouse.”<\/p>\n Why did this happen? There are two sides to every data warehouse project. <\/strong>The business and technology<\/a>. Just like a person needs both food and water to survive, a data warehouse project needs both the business and technology. Technology cannot deliver without clear direction from the business. <\/strong>Only by working together can either succeed. The business must take a leadership role to have any chance of true success.<\/p>\n Now that we know the facts and truths we are going to provide, we need to create a storage model.<\/p>\n Regardless of which of the many platforms you choose, data needs to speak the language of the business. The underlying structures of entities, attributes and measures should be modeled around business terminology and activities. The data belongs to the business, they should understand it. There should be no requirement for a secret decoder ring.<\/p>\n A data warehouse will either provide value to the business or die. Why should a data warehouse design make it harder for the business to understand, harder for the business to use? Think of the time and money that could have been saved if the insurer had insisted that the data model be business-centric?<\/strong><\/p>\n A spreadmart is a data store (e.g. Excel, Access database, and so on) created and maintained by an individual or group that provides shadow data warehouse functions.<\/p>\n Let\u2019s review the life of a Spreadmart. <\/strong>A departmental analyst is trying to fulfill a request by someone in the department. The analyst cannot find a dataset that contains the required data. The existing stores are too narrow, too shallow, or not consolidated. The analyst must produce the request and compiles a desktop data store in Excel. That initial request becomes a part of the analyst\u2019s monthly assignments. The analyst keeps updating the spreadsheet and producing reports. An auspicious beginning. However, at the same time, an analyst from a separate department receives a similar request and creates a similar spreadsheet.<\/p>\n Maybe both spreadsheets agree, but usually over time differences grow. And before long you have those department heads meeting that C-Level executive with different retention numbers.<\/strong><\/p>\n There are four bases in baseball. It is quite an achievement to hit a triple and end up on third base. But if the inning ends and you\u2019re still on third, the score does not change.<\/p>\n The same is true in Data Warehousing. Building a business-centric model on business-provided governance that properly cleanses and conforms to data is quite an achievement. <\/strong>But if you stop there, the score does not change.<\/p>\n This is where reporting applications come in. Over the past 20 years, we have seen canned reports become self-service, self-service become analytics, analytics become machine learning. Each of these advancements was driven in part by some visualization application.<\/p>\n Delivering down the home stretch is where a project turns from a theoretical achievement to a practical one. The visualization application<\/a> must provide the right data, at the right time, to the right people, without making a mistake.<\/p>\n\n Facts are Not Truth, and Truth is Not Only Facts<\/h2>\n
\n
\n
1. Data Governance of the Business, by the Business, for the Business<\/h3>\n
2. Data Modeling on the Cutting Edge of Business<\/h3>\n
3. Spreadmarts Spread Chaos<\/h3>\n
4. Visualizations Say the Right Things to the Right People<\/h3>\n