▣ dataarchitect.studio

Field Notes

What Is Master Data Management, and Why Does MDM Fail?

October 17, 2026/ 11 min read/Governance

Every large organisation eventually discovers it does not know how many customers it has. Sales counts accounts, finance counts billable entities, support counts contacts, and the three numbers disagree by a margin nobody can explain. The standard response is to buy master data management software.

That response is usually premature, and understanding why is most of what is worth knowing about MDM.

What master data actually is

Master data is the set of entities a business shares across systems — customer, product, supplier, location, employee. It is the nouns, as distinct from transactions, which are the verbs. An order is a transaction; the customer who placed it and the product they bought are master data.

The defining property is that master data is referenced by many systems and owned by none of them in practice. Every system that touches a customer has opinions about what a customer is, and each of those opinions is encoded in a schema somebody shipped years ago.

Master data management is the practice of maintaining one agreed version of those entities. It has three parts, and they are not equally hard.

The mechanical part: matching, merging, survivorship

Every mechanical step in MDM rests on a human decision A pipeline runs from source systems through matching, merging and survivorship to a golden record. Beside each mechanical step sits the decision it depends on: matching needs agreement on what counts as the same customer and what match confidence is good enough; merging needs someone empowered to approve or reverse a merge; survivorship needs a per-attribute ranking of which source is more trustworthy. The software performs the steps; it cannot make the decisions. What the software does CRM · ERP · billing · support each with its own idea of "customer" MATCH — are these the same thing? needs: what counts as the same customer, and what confidence is good enough MERGE — combine the matches needs: someone empowered to approve, reject and reverse a merge SURVIVORSHIP — which value wins? needs: a per-attribute ranking of which source is more trustworthy, field by field golden record assembled, not found The software performs every step. It cannot make a single decision. Each decision needs a person with the authority to overrule a department. If that person does not exist, the project stalls here — after the licence is signed. Every mechanical step in MDM rests on a human decision On the left, a pipeline runs from source systems through matching, merging and survivorship to a golden record. On the right, the decision each mechanical step depends on: matching needs agreement on what counts as the same customer and what match confidence is good enough; merging needs someone empowered to approve or reverse a merge; survivorship needs a per-attribute ranking of which source is more trustworthy. The software performs the steps; it cannot make the decisions. What the software does What it cannot do CRM · ERP · billing · support each with its own idea of "customer" MATCH — are these the same thing? what counts as the same customer, and what confidence is good enough MERGE — combine the matches someone empowered to approve, reject and reverse a merge SURVIVORSHIP — which value wins? a per-attribute ranking of which source is more trustworthy, field by field golden record assembled, not found Each needs authority to overrule a department. The software performs every step and cannot make a single decision.
The pipeline is the easy half. Every box on the left waits on an answer from the right.

Matching asks whether two records refer to the same real-world thing. Deterministic matching compares exact keys — a tax identifier, a registration number, an email. Fuzzy or probabilistic matching scores similarity when no shared key exists, which is the usual case for customers and suppliers whose names and addresses are typed by humans in a hurry.

Merging combines matched records. Most implementations auto-merge above a confidence threshold, queue the middle band for human review, and leave the rest alone.

Survivorship decides, attribute by attribute, which value wins. The standard approach ranks sources per field: ERP wins on legal name and tax data, CRM wins on contact preferences, the billing system wins on the address that actually receives invoices. A single blanket rule across every field is the classic mistake, because it lets a source that is authoritative for one attribute overwrite a better source for another.

The output is the golden record — and the word “record” oversells it. It is not a row that existed somewhere waiting to be found. It is assembled, and it reflects a set of decisions about trust. Change the survivorship ranking and you get a different golden record from identical inputs.

The four implementation styles

Most MDM writing organises implementations into four styles. They are a genuinely useful ladder, and they are usually presented as a vendor-neutral industry standard. A caveat on provenance: this taxonomy is widely attributed, and I could not trace it to a single authoritative primary source — almost every citation leads to a vendor glossary. Treat the names as common usage rather than a specification.

Style Where master data lives Writes back? What it costs you
Registry Sources keep it; hub holds IDs and match keys only No Least disruption, least benefit
Consolidation Copied into a hub, cleansed, published No Good for analytics, fixes nothing operationally
Coexistence Both hub and sources, synchronised Yes Sync complexity, and the hub is not the system of record
Centralized / transaction hub The hub, authored directly N/A — it is the source Maximum benefit, maximum organisational commitment

Read down that last column. The ladder is not primarily technical. Each rung increases how much authority the hub has over systems other teams own, and that is a political quantity, not an architectural one. Programmes that start at registry or consolidation and earn their way upward tend to survive. Programmes that begin at transaction hub because that is where the value is have skipped the part where everyone agrees to be overruled.

Why MDM projects fail

Not because the software is bad. Modern matching engines are genuinely good, and the fuzzy-matching problem is largely solved for ordinary cases.

They fail because every mechanical step above has a prerequisite that is a decision, and the decision requires authority somebody has to actually hold.

  • Matching needs agreement on what counts as the same customer. Is a subsidiary the same customer as its parent? Is a person who moved house the same person? Finance and sales will answer differently, and both answers are defensible within their own department’s purpose.
  • Merging needs someone who can approve a merge over the objection of the team whose record loses.
  • Survivorship needs a per-field ranking that says, in writing, that one department’s data is less trustworthy than another’s.

None of these is a configuration question. All of them are whose definition wins, which is a question about org charts. A tool makes them unavoidable and explicit, which is useful — but it surfaces them at the most expensive possible moment, after a licence is signed and a delivery date is public.

This is the same shape as data quality problems being org-chart problems, and the same reason a data contract is mostly a cultural artefact. The pattern repeats because the underlying constraint repeats: software can enforce an agreement and cannot manufacture one.

What to do before buying anything

Two diagnostics, both cheap, both revealing.

Count the claimants. For your most contested entity, list every system that believes it defines that entity. Not systems that store it — systems whose owners would argue if you told them their version was wrong. The number is usually higher than expected and is the real scope of the problem.

Ask who can overrule. Name the person who can tell finance that sales owns the customer definition, and make them say it out loud. If no such person exists, you do not have an MDM project; you have an escalation waiting to happen.

If the second question has a clear answer, a tool will accelerate you considerably. If it does not, the useful first step is cheaper and less political: a data catalog to document how many conflicting definitions exist, or a semantic layer to make the disagreement visible in reporting before you try to resolve it at source.

Where it meets the warehouse

For analytics specifically, there is a narrower and much cheaper version of this problem, and it is worth knowing you may only need that one.

If your goal is consistent reporting rather than consistent operations, you do not need to fix the source systems. You need conformed dimensions: one shared customer dimension that every fact table references, with the reconciliation done once on the way in. That is MDM’s analytical benefit without MDM’s political cost, and it is a well-trodden path.

MDM proper earns its keep when the operational systems need to agree — when a shipment goes to the wrong address because billing and logistics disagree about which one is current. That is a real problem and worth real money. It is just a different problem from the one most MDM purchases are trying to solve.

The summary worth keeping: master data management is an organisational agreement with software attached. Buy the software when you have the agreement, or at minimum when you know who is empowered to make it. Buying it to produce the agreement is the expensive way to discover you needed it first.

Common questions

What is master data management?

Master data management is the practice of maintaining one agreed version of the entities a business shares across systems — customer, product, supplier, location, employee. It combines matching records that refer to the same real-world thing, merging them under survivorship rules into a golden record, and governing who may change that record and on what authority. The software does the matching and merging; the agreement about what counts as a customer and whose definition wins is the part that is not software.

What is a golden record in MDM?

The single most trustworthy version of a master entity, assembled rather than found. Records referring to the same real-world thing are matched across source systems, then survivorship rules decide attribute by attribute which value survives — typically by ranking sources per field, so ERP wins on legal name and tax identifiers while CRM wins on contact preferences. The golden record is therefore a constructed artefact reflecting a set of decisions, not a record that existed somewhere waiting to be found.

What are the four MDM implementation styles?

Registry keeps a thin index of IDs and match keys and leaves the data in the source systems. Consolidation copies data into a hub, cleanses it and publishes a golden record for analytics, with no write-back. Coexistence keeps master records in both the hub and the sources and synchronises them. Centralized, also called a transaction hub, makes the hub the system of record where master data is authored directly. The order matters: each step increases both integration value and organisational commitment, and most programmes that jump straight to a transaction hub are underestimating the second.

Why do MDM projects fail?

Because they are run as software implementations when the hard part is a negotiation. Matching, merging and survivorship all require someone with authority to decide whose definition of a customer wins, which source is more trustworthy per attribute, and who may overrule a merge. If that authority does not exist before the tool arrives, the project stalls at exactly the point where those decisions become unavoidable — usually after the licence is signed. The common failure is not a bad product; it is a good product waiting on an answer nobody is empowered to give.

What is the difference between MDM and a data catalog?

A data catalog tells you what data exists, where it lives and what it means. MDM decides which record is correct and makes other systems use it. The catalog is descriptive and read-only over your estate; MDM is prescriptive and writes back. They are complementary, and a catalog is often the cheaper first step because it surfaces how many conflicting definitions of customer you have before you commit to resolving them.

Is MDM the same as data governance?

No, though they are frequently sold together. Data governance is the broader practice of deciding ownership, policy and accountability across all data. MDM is a specific application of that to shared master entities, with software that enforces the result. MDM without governance is a matching engine producing golden records nobody has agreed to honour, which is the most common way to spend a lot of money and change nothing.

Do I need an MDM tool?

Later than most vendors suggest, and possibly not at all. If the organisation cannot yet name an owner for customer, a dedicated tool will not create one. The cheap diagnostics first: count how many systems claim to define your most contested entity, and ask who is allowed to overrule the others. If that question has a clear answer, a tool will accelerate you. If it does not, the tool will surface the disagreement at enormous cost and then wait for you to resolve it anyway.