![\"Consensus.png\"](\"https:\/\/3cloudsolutions.com\/wp-content\/uploads\/2022\/11\/Consensus.png\")
<\/p>\nAs modern analytics continues its exciting evolution, it\u2019s more important than ever to be mindful of some of the foundational elements that allow an organization\u2019s analytics strategies to mature and evolve. Today, advanced analytics, data lakes, and cloud-based solutions dominate our industry headlines, and while these things will no doubt prove indispensable to any venerable analytics practice, many of us are still faced with learning to walk before we can learn to run \u2013 and the time-tested data warehouse remains today just as relevant a cornerstone to a budding analytics practice as it did a decade ago.<\/p>\n
<\/p>\n
<\/p>\n
There\u2019s just no getting around it: before stakeholders can turn their data into insights, that data needs to be structured in a way that lends itself to being easily understood \u2013 a central prerequisite to any analytics solution. Turning data into insights is, and should be, the ultimate goal, but it is difficult to build effective and advanced solutions without having a strong model to stand on.<\/p>\n
Of the many data models designed to help organizations build a durable analytics platform, the Kimball dimensional model is the gold standard. It pushes data modelers to focus on building something that is fast, and, more importantly, something that is easily understood.<\/p>\n
After all, if an analytics solution does not impart understanding and insight, then what is it doing? While the technical requirements to building a data warehouse are generally well known and understood at this point by the industry, we should know that lurking behind IT\u2019s requirements checklist is a far more critical (and almost completely non-technical) prerequisite: organizational consensus.<\/span><\/p>\n As consultants, we have a saying in the Business Intelligence\/Analytics space when it comes to centralizing data as part of an analytics solution, and that is: \u201cWe want one version of the truth.\u201d In other words, for the audience served by your analytics solution \u2013 and by extension the data warehouse within that solution \u2013 we want to use one set of terminology, one set of \u201crules,\u201d and\/or one set of agreed-upon use cases. How else do we arrive at \u201ctruth\u201d if we are not using a common language to describe an agreed-upon definition of the process or organization that we seek to analyze? Quite simply, we cannot.<\/p>\n In fact, as the scope of a solution grows in size and in complexity, it becomes more critical to have a single truth in order to be successful. Indeed, simply deciding the scope of the solution itself should help organizations come to a consensus, but it isn\u2019t always that simple when there are questions such as:<\/p>\n There is no one-size-fits-all answer here. Rather, these questions can only really be answered through meaningful discovery and conversation, ultimately allowing teams to arrive at a point of mutual agreement.<\/p>\n Somewhat unique to analytics solutions is the unvarnished way in which data can paint a picture of a process, or an organization, or a way of doing business. Much as the weather doesn\u2019t particularly care what the forecasters are calling for, raw data begins to tell a story that is \u2013 especially as we continue to procure it from more and more sources \u2013 largely agnostic to any one interpretation or point of view.<\/p>\n For example, data generated by a process of selling goods or services may ultimately end up in the hands of both sales personnel and accounting staff \u2013 often undergoing quite a bit of disparate conditioning and massaging along the way in order to suit the particular needs of each division. When tracking toward a data warehouse as a singular repository of data, what will be the agreed-upon structure, naming, and rule sets that the data warehouse should incorporate?<\/p>\n The answer here is not particular to some hypothetical question like the above, but rather to point out that it\u2019s still up to people (the stakeholders and<\/em> the consumers), and the establishing of process, to determine these answers before any sort of computer architecture can be expected to. Know your audience. Know the use cases being presented.\u00a0Bring those with both relevant knowledge to the processes being discussed, and an open mind to change, to the table. <\/span>Give them a chance to be heard. And only then worry about knowing your source <\/span>systems, or what keys your tables should use.<\/span>\u00a0After all, improved insight often brings about change, as we very rarely open our eyes only to discover that we\u2019ve been doing things in the dark perfectly all along.<\/span><\/p>\nOrganizational Consensus<\/h2>\n
\n
Arriving at Consensus<\/h2>\n