Seven Fatal Errors in MDM and How to Avoid Them, by John Owens

The business practice referred to as Master Data Management (MDM) is plagued with seven fatal errors that prevent enterprises from achieving success, no matter how much money or effort is thrown at the problem.

What are these fatal errors?

  1. Calling it MDM!
  2. Looking in existing data for Master Entities.
  3. Using misnomers like Customer, Supplier, etc. for the Master Entity of “Party”.
  4. The Curse of the Systems SILO.
  5. Mistaking Unique Codes for Unique Identifiers.
  6. Mistaking Address for an attribute of Party.
  7. Not using the Logical Data Model.

In this article, I’ll address each of these fatal errors in turn and, more importantly, describe how they can be easily avoided.

Error 1: Calling it MDM

The first fatal error is calling it ‘Master Data Management’ at all.  Calling this core set of activities by the wrong name starts it off in the wrong place and heads it in the wrong direction. The fact is that there is no such thing as ‘master data’!

What is actually being managed are what I call the Master Entities of the enterprise and, for that reason, this set of activities should be termed Master Entity Management (MEM).  True, we do hold data about these, but it is the management of the entities, not of the data, that is key to success.  The quality of the data of the entities will need to be managed, but that is a subsidiary part of managing the Master Entities themselves.

This misnaming is historical and came about because this whole area has been mismanaged for some time now and is probably worse off that it was 20 years ago.

Many of the core skills and techniques that are essential for Master Entity Management have been forgotten. Indeed, many practitioners have never even learned them.  For that reason, most enterprises start in the wrong place by trying to sort out databases full of error-laden data relating to Master Entities and believe, erroneously, that this will solve the problem.


The solution starts by calling this core set of activities by the correct term, Master Entity Management.  Will this solve all of the problems? No.  But it is the foundation for a solution.

Using the wrong name makes a solution impossible to achieve as all efforts are pointed in the wrong direction.  By using the correct name, it becomes possible to identify the true faults and, more importantly, ways of rectifying them.

Error 2: Looking in the Wrong Place

Scrap Car

Having started off by calling Master Entity Management by entirely the wrong name, practitioners further compound their error by looking in entirely the wrong place for the Master Entities of the enterprise.

And where is this? In the existing data!  Why should they not look there?

Unless Master Entity Management is already well established in your enterprise, then your existing data on your Master Entities is probably as far from what it ought to be as it is possible to get. So, looking there for your Master Entities makes about as much sense as looking in a scrap yard for the components for a Formula 1 racing car.


The only way to find out what the Master Entities of the enterprise are is to ask the Senior Executive team the six “Multi Dimensional MEM” questions.

These six questions, which will lead you to the Master Entities for any enterprise, are:

  1. What types of things do we make, buy, sell, improve or trade?
  2. Who do we buy from and sell to?
  3. Who benefits from our products and services?
  4. Where are our customers, suppliers, beneficiaries, etc. located?
  5. What resources do we use to make, buy, sell, improve or trade our products and services?

Error 3: Muddled Misnomers

Using misnomers like Customer, Supplier, etc. for the core Master Entity of the Enterprise is our next MEM fatal error.

Customer is NOT a Master Entity! This will come as a shock to all of those enterprises that see Customer as their most important Master Entity and spend so much time, energy and money trying to achieve things like a ‘Single Customer View‘.

The truth is that they’ve gotten it wrong, and their approach is a major cause of fragmentation of the Master Entities in enterprises around the world.

If Customer is not a Master Entity, with whom does the enterprise do business?

They do business with legal entities or parties other than the enterprise itself.  For this reason, a more appropriate name for this crucial Master Entity is ‘Party’.

If Party is the correct name for the Master Entity, what is ‘Customer’?  It is a Role played by a Party in a commercial transaction with the enterprise.


Be aware that one Party can play many roles, such as Customer, Supplier, Guarantor, Beneficiary, even Employee!  Although all of these roles are crucial to the survival of the enterprise, they are NOT Master Entities and mistaking them to be such, will cost the enterprise dearly.

Error 4: The Curse of the Systems Silos

System SiloOne of the major causes of fragmentation in MEM is the ‘Silo Mentality’ that pervades nearly every enterprise, due to the widespread use of third party applications or packages – also called Commercial Off-the-Shelf (COTS) software.

A typical package of this type would be a Customer Relationship Management (CRM) application.

In the silo world of the CRM application there is only one Role for Party and that is Customer, so it is called ‘Customer’.

Everybody who works with these packages gets sucked into the Silo and they too start to believe that Party is really Customer.

It’s similar in the silo world of Supplier Management, where Party is mistakenly called Supplier and where all concerned believe it to be so.

The same error is repeated around the enterprise in the worlds of HR, Marketing, etc.

Everywhere that you have a “silo application”, you will have a “silo mentality”, bringing fragmentation and duplication.


Party Transactional Roles

What is required is central management of the Master Entity of Party.

This requires unified and integrated thinking and a centralised system that holds a single view of Party that can be used by all other satellite systems.

The starting point for such integrated thinking is a Logical Data Model that shows the Master Entity of Party in its true light and Customer, Supplier, Employee, etc. for what they really are – Roles.  Important Roles. Vital Roles. Yet just Roles – all played by the core Master Entity of Party.

MEM Error 5: Mistaking Unique codes for unique identifiers

This error is perhaps the single greatest cause of duplication of Master Entities in systems around the globe. The most common example of this is the belief that Customer Number is the unique identifier of a Customer.

What is wrong with doing that? Several things.

As we saw in MEM fatal error 4, there is no such Master Entity as Customer.  The actual entity is Party.

Having this ‘unique code’ mentality results in one part of the enterprise giving Party the unique identifier of Customer Number, another part giving it Supplier Number, and in yet another part giving it Employee Number and so on.

So here we have (at least) three different unique codes posing as the unique identifier of the same entity in the same enterprise.

So, what is the solution? A Party Number?  Well, Party Number would definitely be a useful mechanism for removing the proliferation of other numbers around the enterprise, however, it would not be the unique identifier of Party.

The fact is that unique codes are never unique identifiers.

Imagine we had three Parties with unique Party Numbers as follows:

P00123 John Owens

P00124 John Owens

P00125 John Owens

Are these three different Parties? Well, according to the Party Codes they are.  However, the Party Name suggests quite the opposite.  It does not prove it, but is strongly suggests it.


How would we find out?  We would actually look for more information on Party, such as age, gender, address, etc.

From this we can see that the information that we need to uniquely identify a Party has nothing to do with the Party Number, it has to do with other key data about Party.

The question we must ask to guide us to the defining the unique identifier of Party is, “With regard to this enterprise, what is it that makes one occurrence of Party uniquely different from every other occurrence of Party?”

This will never be a code! The fact is that codes do not identify entities, they are merely a mechanism for referring to them. Because they do not identify them, they can never uniquely identify anything.

Unique identifiers for Party are a challenging subject and are covered in much greater detail in Module 2 of the Multi-Dimensional MEM Online Training Course.

MEM Error 6: Modelling Address as an Attribute of Party

Party EntityOne of the major misunderstandings that pervade Master Entity Management is that of modelling address as an attribute of party.

How many times have you seen a data entity or database table with the structure shown on the right?

But why is this structure wrong? Ask yourself, ‘What happens if the Party changes address?’ Do the values for house number, etc. all get overwritten?

If so, how do you know where the party lived before the address currently displayed?  How long did they live there? How often did they move?

Also ask, ‘Who else lives at this address?’

This structure will not allow you to answer any of these questions.

It is only the attributes above the line that actually belong to Party.  Those below the line belong to another entity entirely.  The proper name for this entity is Location.


Party Location Usage

Move all address details out of Party into an entity called Location.  Because a Party can be legitimately associated with many Locations over time, the relationship between Party and Locations is a many-to-many.  This means that it needs to be resolved by an intersection entity called Party Location Usage (or Site, as some MDM vendors refer to it).  This is a very powerful entity that shows what use a Party makes of Locations, for how long and what other Parties also make use of these Locations.

MEM Error 7: Not using the Logical Data Model

This is a case of the last being first and the first being last.

The fact is that if enterprises were to model the structures of their Master Entities in the form of Logical Data Models (LDMs), then all of the preceding six errors could be avoided!

Amazing as it may seem, there are comparatively few MEM practitioners, who use, or can use, Logical Data Models in the course of their work.  This fundamental skill has been lost over the last few years and has given the world very many, far too many, MEM practitioners without the necessary skills to successfully implement Master Entity Management in any enterprise.

Because they have lost the core skill they try to push forward a whole raft of technology based solutions, such as Big Data, Real World Alignment, MEM in the Cloud, etc.

All of these technologies have a lot to bring to MEM, however, unless the fundamental structures of the Master Entities of the enterprise have been robustly modelled at the logical level, they will bring absolutely no benefit – quite the reverse.

The use of these technologies actually presents a significant risk to any enterprise that has not carried out proper logical modeling.


There are five essential actions to take in order to assure the quality of, not just your Master Entities, but of all of your data. These are:

  1. Bring Logical Data Modelling to the heart of all Master Entity Management and Data Quality and activities.
  2. Train a core group of people (this would include analysts and business managers) in the fundamental skills of Logical Data Modelling and locate this team in the business, NOT in IT.
  3. Build a Corporate Business Functional Model for the enterprise, as this defines all of the data that is required by the enterprise.
  4. Build a Corporate Logical Data Model showing the elements and structures of the data required by the Business Functions.
  5. Use these two models as the foundation on which you make all of your decisions on systems development and procurement for all parts of the enterprise.

About the Author

John is a Thought Leader, Consultant, Mentor, Practitioner and Writer in the worlds of Strategic Requirements, Business Process and Data Modelling, Data Quality and Master Entity Management.

He has built an international reputation as a highly innovative specialist in these areas and has worked in and led multi-million dollar projects in a wide range of industries across the UK, Ireland, Europe and New Zealand.


Tags: , , , , , ,

2 Comments on “Seven Fatal Errors in MDM and How to Avoid Them, by John Owens”

  1. Sabu Joseph 11/20/2012 at 3:15 pm #

    Thanks John for this great article. Such holistic and fundamental approach is required to save data management initiatives from falling into the category of DW systems that didn’t meet expectations of business. And it is all the more relevant given the importance of Data governance and convergence of data management with BPM, SOA and trends in analytics to take effective decisions and for efficient business operations


  1. Seven Fatal Errors in MDM and How to Avoid Them, by John Owens « analyticalsolution - 11/07/2012

    […] See on […]

%d bloggers like this: