For years I am trying to build a single source of the truth (SSOT). Now I read in "What's your data strategy" about MVOTs architecture: multiple versions of the truth. But wait a minute, wasn't this exactly what we were trying to root out? Let's have a look.
First Dallemulle and Davenport distinguish between data and information. According to Peter Drucker, information is 'data endowed with relevance and purpose'. It's only when you put raw data in context you get information that supports decisions.
You can, for example, compare sales figures by product group and region with last year's sales. This provides you with information that allows you to follow up on your business strategy. The raw data in this analysis may be millions of cash register tickets. Those are hard to interprete without parsing, sorting or enriching it.
Many organizations start with a top-down, centralized, control-oriented architecture. This approach is effective for standardizing enterprise data and is necessary to keep the data safe and compliant. But this kind of data management can inhibit flexibility. This makes it harder to transform it into actionable information.
MVOTs.
Linked to this SSOT you need a more flexible way to use data: MVOTs. They are the result of business-specific transformations of the data into relevant and purposeful information. Information that you tailor to different contexts for different parts of the business.
For example a customer can mean different things for different departments in your organization:
All the data related to the customer lives in the SSOT, but you create MVOTs for the different departments to suit their specific needs. But why then, are we trying to root out many versions of the truth in the first place? The many versions of the truth we sometimes find at our clients are not exactly based on a SSOT. The MVOTs at our clients exist not only on the information level, but also on the data level.
Every project manager has her own excel with time sheets, milestones and deliverables. So there is no governed SSOT on the data level that contains data in line with company wide definitions. This limits the ability to compare projects with each other. The client gets invoiced more or less depending on the interpretation of the time sheets. Data exists on different levels of detail between projects, and so on.
How to solve this?
The database of this software contains the SSOT about projects on the data level. Now you can start building MVOTs based on this data. Different people in the organization need different information to make decisions. The project manager needs all the details to manage the day to day activities. But management only needs a couple of key figures about the project. The data will be the same, but the context in which you present the data will be tailored to the needs of the end user.
In short: SSOT works at the data level, MVOTs use the data in the SSOT to support the management of information.
I will help you figure out the right conceptual data models to support your different business cases. On the one hand we will start from all available data to see how we can store it in an efficient, accessible, extensible and secure way: the SSOT. On the other hand we will interview business stakeholders to find out how data can support decisions and actions to propel their business forward: one of the MVOTs.