Skip to content

Master Data Management

Governance program — instantiates Source-of-Truth Assignment

A standing enterprise program that assigns data stewards, carves which system is authoritative for each data domain across business units, and sets the synchronization and duplicate-resolution policy the point mechanisms execute.

Master Data Management (MDM) is the umbrella governance program that ties source-of-truth work together across many applications and business units. Its distinguishing contribution is not any single artifact but ownership and coordination: it names the stewards accountable for each data domain, decides which system is authoritative for which domain enterprise-wide, and sets the standing policy for how records synchronize and how duplicates are resolved — then delegates the actual execution to registries, consolidation methods, and sync jobs. It is what keeps those point mechanisms from drifting into a dozen local answers.

Example

A manufacturer holds "supplier" data in three systems: ERP, procurement, and finance — each with its own supplier list, none agreeing on names, IDs, or banking details. Rather than reconcile forever, they stand up an MDM program for supplier master data. They appoint a supplier-data steward accountable for the domain; they carve authority boundaries — procurement governs supplier onboarding status enterprise-wide, finance governs banking and payment details — and they set the standing policy for how supplier records synchronize across the three systems and how duplicate suppliers get resolved. The steward owns disputed cases and reviews the boundaries as the org changes. "Supplier" stops being three conflicting lists and becomes one governed domain with a named owner and a coherent rulebook.

How it works

MDM operates at the governance layer, one level up from the mechanisms that touch data directly. It (1) assigns stewardship — a named, accountable owner per data domain; (2) defines authority boundaries across systems and business units, deciding which system governs which slice of a domain; and (3) sets synchronization and duplicate-resolution policy that downstream mechanisms carry out. Distinctively, it does not itself run the sync, mint the identifiers, or perform the merge — it coordinates the mechanisms that do, providing the ownership and cross-domain boundaries none of them can set for themselves.

Tuning parameters

  • Centralization degree — a central MDM hub that masters data itself versus a federated model where domains self-steward under shared rules. Central is consistent but heavy; federated is agile but drifts.
  • Domain scope — how many master-data domains (customer, supplier, product, employee) the program governs at once. Fewer domains done well beats many done nominally.
  • Steward authority — how much power stewards actually hold to override source systems versus merely advise. Real authority is what separates governance from paperwork.
  • Governance cadence — how often boundaries and policies are reviewed as the organization and its systems change.

When it helps, and when it misleads

Its strength is giving sprawling, multi-system data a single accountable owner and a coherent policy — the connective tissue that stops each point mechanism from answering the same question differently. Its failure modes are institutional: MDM programs bloat into heavyweight bureaucracies that model everything and govern nothing, or stewardship exists on an org chart with no real authority behind it. The classic misuse is buying an MDM tool and declaring the problem solved without assigning owners or drawing boundaries — a platform with no governance.[1] The discipline that guards against this is real stewards with real override authority, and governing only the few domains that actually matter rather than boiling the ocean.

How it implements the components

  • stewardship_owner — its signature contribution: a named, accountable owner for each master-data domain, responsible for disputed cases and boundary upkeep.
  • authority_boundary — carves which system is authoritative for which slice of a domain across business units, at enterprise scope.
  • synchronization_rule — sets the standing policy for how records propagate and how duplicates resolve, which the runtime mechanisms then execute.

It does not run the propagation itself (that is Synchronization Job), perform the duplicate merge (that is Golden Record Consolidation), or hold the canonical identifier list (that is Canonical Registry) — it governs those.

Notes

MDM is unusual among its siblings in that several of them are the very mechanisms it coordinates. Reading it as the governance layer — stewards, cross-domain boundaries, and policy — keeps it distinct from the registry it maintains, the consolidation it commissions, and the sync jobs it schedules.

References

[1] "Data stewardship" — the assignment of named, accountable owners for defined data domains — is the human core of master data management. Tooling can enforce rules, but only a steward with real authority can adjudicate the cases the rules do not cover and revise the boundaries as the business changes. ↩