Master data without the capital-P program

Master data management arrives in most companies as a Program: a platform purchase, a steering committee, a two-year roadmap, and, frequently, a quiet burial around month eighteen. The need underneath is real and much smaller: when three systems each have a record called "Acme Corp", something must say whether they are the same customer. That is an identity problem, and identity problems have a lightweight answer.

Build the mapping, not the monument. A cross-reference layer in the warehouse: one table per entity (customer, product, vendor) mapping each source system's key to a canonical id, with survivorship rules written as code. Deterministic matching (tax ids, domains, normalized names) resolves the large majority; the ambiguous remainder goes to a human queue, which is a spreadsheet before it is a workflow tool. Version the rules, log the merges, publish the mapping like any other governed dataset with an owner and a contract.

Cross-system identity is bread-and-butter integration work, not platform exotica; a public integration platform case study shows the shape at enterprise scale, an in-house layer replacing an expensive SaaS by treating identity and data movement as one engineering problem with named owners.

When the Program is actually warranted. Real-time write-back into operational systems, regulatory regimes that mandate golden records, or entity volumes where the human queue stops scaling. Those are genuine MDM-platform cases, and arriving at them with a working mapping layer makes the platform implementation dramatically cheaper, because the survivorship rules and the political fights are already settled.

The survivorship rules are the actual project. Matching gets the attention, but the fights worth scheduling are about survivorship: when two systems disagree on Acme's address, which one wins, and who decided. Write each rule as a line of code with a named approver and a date. Billing wins on payment terms, the CRM wins on contacts, most-recently-verified wins on addresses, and every exception is a pull request rather than a meeting. The rules will be wrong at first. Wrong-but-versioned converges in weeks; wrong-but-undocumented converges never, because nobody can see what to fix.

Run it like a pipeline, not a project. The mapping table gets the same treatment as any governed dataset: freshness checks, a match-rate metric on a dashboard, and a weekly count of the human queue's depth. Those three numbers are the whole status report. When match rate drifts down, a source system changed its data entry habits; when the queue grows, the deterministic rules need a new pass. Half a day a week of an analyst's time keeps a mid-sized company's customer entity clean, which is a number worth comparing against any Program license quote you have received.

Where to start counting. Pick the entity whose duplication costs the most this quarter, almost always customer, and the two systems whose disagreement is loudest, usually billing and CRM. One entity, two systems, one analyst, four weeks: that scope produces a working mapping and, more valuably, the survivorship precedents every later entity reuses. Expanding entity by entity afterwards is routine. Starting with all entities and all systems is how the lightweight answer turns back into the Program, one workshop at a time.

A last definitional point, because the terminology invites scope creep: this article is about identity resolution, which is the part of MDM most companies actually need. Reference data management, hierarchy management and golden-record write-back are separate problems with separate cost curves, and bundling them into one initiative is precisely how the two-year roadmap gets written. Solve identity first, standalone. The other problems either shrink once identity is settled or reveal themselves as the platform cases they always were.

Most companies asking about MDM in our assessments need the mapping by next quarter and the Program never. The vendors will forgive us eventually.