Master Data Management Does Not Equal The Single Source Of Truth

The number one reason I hear from IT organizations for why they want to embark on MDM is for consolidation or integration of systems. Then, the first question I get, how do they get buy-in from the business to pay for it?

My first reaction is to cringe because the implication is that MDM is a data integration tool and the value is the matching capabilities. While matching is a significant capability, MDM is not about creating a golden record or a single source of truth.

My next reaction is that IT missed the point that the business wants data to support a system of engagement. The value of MDM is to be able to model and render a domain to fit a system of engagement. Until you understand and align to that, your MDM effort will not support the business and you won’t get the funding. If you somehow do get the funding, you won’t be able to appropriately select the MDM tool that is right for the business need, thus wasting time, money, and resources.

Here is why I am not a fan of the “single source of truth” mantra. A person is not one-dimensional; they can be a parent, a friend, or a colleague, and each has different motivations and requirements depending on the environment. A product is as much about the physical aspect as it is about the pricing, message, and sales channel it is sold through. Or, it is also faceted by the fact that it is put together from various products and parts from partners. In no way is a master entity unique or has a consistency depending on what is important about the entity in a given situation. What MDM provides are definitions and instructions on the right data to use in the right engagement. Context is a key value of MDM.

When organizations have implemented MDM to create a golden record and single source of truth, domain models are extremely rigid and defined only within a single engagement model for a process or reporting. The challenge is the master entity is global in nature when it should have been localized. This model does not allow enough points of relationship to create the dimensions needed to extend beyond the initial scope. If you want to now extend, you need to rebuild your MDM model. This is essentially starting over or you ignore and build a layer of redundancy and introduce more complexity and management.

The model is all-important for MDM and this model cannot be entrenched to the physical data store or application. When you embark on MDM, make sure the reason you do this is to align master entities to a system of engagement defined by the business. Do not feel you have to get to one version of the truth. Model the data to allow for flexibility in different situations and leverage keys to enforce connectivity. Doing so means your MDM initiative is about supporting a business need over solving an IT management and cost issue that is hard for the business to digest. You will speak in terms the business understands when you discuss their objectives, leaving the technical talk for your architect discussions. That gets you buy in to invest and help the business succeed.


Michele, I totally agree with


I totally agree with your article and very relevant to my recent post on

I like to think of it as:
(1) The entity or the representation of the real thing (i.e. myself Diane Arneberg, a item definition etc.) which should not be duplicated or multi-managed (best to avoid many Diane Arnebergs)

(2) The attributes: I am registered in many many systems (Facebook account, my corporate HR record, Tax records, voting records, DMV records, criminal records if I had any). it does not make sense to have a single source of truth with all this information in one place as it has little practical benefits.

What it comes down to is how attributes which are common and how they should be managed. Data which is relevant only for Engineering team which nobody else cares about should probably remain in the PLM or PDM application whereas for example the weight of an item which may be relevant to many systems across the enterprise should be "owned" in one place avoiding 4 different weights for the exact same item.

Hi Michelle I couldn't agree

Hi Michelle

I couldn't agree more. Far too often MDM is seen as a technical problem.

I have seen business consultants called in by IT, at massive expense, to build a cbusiness case based on these technical goals - not surprisingly business hasn't bought in.

Achieving allignment to business goals is critical as discussed here

Good confimation

Thanks for the feedback. I agree with the point on expense. There is certainly expense in deploying MDM that focuses on the golden record - de-duplication. This would include over building and lack of scalability. But, a colleague of mine also made a point yesterday that the cost is even greater when you have various processes and master definitions for the same outcome (ie, customer on-boarding). Think about having to implement multiple "golden record" systems to service this need. Or, worse, you implement in a localized fashion and only manage a portion of the business and value stream.

Connie Moore wrote this - worth looking at.

Interesting perspective

Interesting perspective. I’d suggest that it’s becoming increasingly important to take a holistic approach to managing all of an organization's data assets, both master and mastered, which is key to generating precise insight. I recommend to my life science clients that they need to take a step beyond MDM in terms of data governance, and that’s Information Management. As technology evolves, many IM frameworks include not only the development of a technical architecture, but also the evolution of the key disciplines required to truly realize information management maturity, such as governance, quality management and lifecycle management.

Context matters

Hi Michele
Well written. I agree that (master) data is always used in certain context i.e. user has a certain need in moment and the data is valued and used in a variable situation. Traditional? approach, yet practical, could be that all master data should be valued, retrievable and associated to Balanced Score Card views used in organization - or other similar frame work. If company does not yet have a common business discipline such as BSC - it has more home work to do before utilizing MDM in data driven decisions making. In order to automate and make concrete, one should apply KPIs as real "business attributes" in MDM data model, or build a linking and query capabilities to map "business driver structure" to MDM data (the model and instances too). Should you ask me, I'd build a separate layer above using semantic tech tools. Business ontology approach I have studied a bit on my blog post:
Thanks for a good article, Heimo

Right on.

It is so logical. It seems most people link MDM as the silver bullet to solve their Data warehouse or Data integration problems.


You made some good points there. I did a search on the topic and found most people will agree with your opinion.