MDM: A Disruptive Approach

Today I wanted to share a very insightful and disruptive article on Master Data Management (MDM).
It was written by Michele Goetz, an analyst at the Forrester, in 2012: Master Data Management Does Not Equal The Single Source Of Truth.

MDM is not about creating a golden record or a single source of truth.

Unlike many MDM tools you could find on the market, announcing they are the right choice to manage golden records (basically one unique representation of a master entity), the author explains that MDM is simply not made for that reason.

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?

It makes sense. If the business sees the solution just like another integration solution (already sold with EAI then with ESB), it is not the good approach.

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 […] Context is a key value of MDM.

This part is really key. Put yourself in the place of the business.
The IT guy in front of you is trying to sell a solution for having a single source of truth to manage the master entities you are working with every day.
It is very likely that you would not be interested in such solution because many organizations remain silo-based. You would rather be interested in a solution to support as best as possible your own system of engagement, your own utilization of these master identities. In a nutshell, your own context.

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.

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. Model the data to allow for flexibility in different situations

It reminds me a good old debate:

  • Should we model canonical data for cross-business domain usage?
  • Or should we rather model a core and lightweight representation but with flexible extensions for domain-specific information with hooks to navigate from one domain to another?

After having worked in a manufacturing industry on trying to model its main master entity, I could not agree more on the fact that one unique view is very often a mistake (still for master data). Master entity representations are not unique but business domains are.

Make sure the reason you do this is to align master entities to a system of engagement defined by the business […] Doing so means your MDM initiative is about supporting a business need

This is the key argument. MDM is not made for having all business domains speaking the very same language. It is a solution to align master entities onto a specific context defined by the business.

We don’t have to forget that in the Business-IT alignment, it is up to the IT to be aligned with the business, not the contrary.
This way an MDM solution has to support a business need, not an IT one.