Single or multiple sources of truth?

BlogData Strategy
September 2, 2022
For years I am trying to build a single source of the truth (SSOT). Now I read about a MVOTs architecture: multiple versions of the truth.

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.

Data vs information

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:

  • For finance it is someone to send an invoice to,
  • for sales the different business units at the customer can need a different sales approach,
  • the different sites of the customer where repairs are needed are relevant to after sales.

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.

An example: project management

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?

  • A first step to solve this, is to model the processes a project goes through.
  • Then you define a uniform way to perform projects within the organization. And you agree upon definitions of the different elements in this process.
  • Next you put in place templates. For instance templates of time sheets or project charters
  • After that you can start looking for a software to offer these templates in a more scalable and maintainable manner.

The database of this software contains the SSOT about projects on the datalevel. 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.

Conclusion

In short: SSOT works at the data level, MVOTs use the data in the SSOT to support the management of information.