Master data management is the discipline of keeping the identifiers and shared attributes for customers, products, suppliers, locations, employees, and other durable business objects trustworthy across systems. Growing teams usually feel the need before they use the term: the same customer has three IDs, a renamed product remains active in one channel, or finance and sales disagree about the legal entity on an invoice. MDM addresses that operating problem. It is not a promise that one database will replace every application.
The practical goal is a governed answer to four questions: what object is this, which records refer to it, which system may decide each attribute, and how is a disputed value corrected? Edilec's system of record design guide explains record authority, while the engineering notes for reliable MDM and enterprise MDM guide cover adjacent implementation choices. This field guide turns those ideas into a sequence a growing team can run.
Key takeaways
- Start with one business object and one costly cross-system failure, not an enterprise-wide data inventory.
- Assign attribute-level authority; a single application is rarely authoritative for every customer or product fact.
- Keep matching, survivorship, validation, publication, and correction as separate decisions with visible evidence.
- Measure downstream outcomes such as rejected orders and manual reconciliations alongside abstract quality scores.
- Treat stewardship as owned operational work with queues, service expectations, and escalation paths.
Choose the business object and failure to fix
Begin with a failure that has a consequence: duplicate suppliers causing payment review, missing product dimensions blocking fulfilment, or inconsistent customer legal names delaying credit checks. Name the business object, affected process, current workaround, owner, and baseline. The Government Data Quality Framework describes quality as fitness for purpose and recommends understanding users across the lifecycle. That is a better starting point than demanding that every field be perfect.
| Scoping question | Useful answer | Weak answer |
|---|---|---|
| Which object? | Business customer represented by a legal entity and its trading sites | All customer data |
| Which decision fails? | Credit approval cannot link open exposure to the legal entity | Reports look wrong |
| What is authoritative? | CRM owns sales relationship; ERP owns billing account; registry evidence supports legal identity | The data warehouse |
| What is success? | Fewer duplicate reviews and no increase in false merges | A golden record exists |
| Who resolves disputes? | Customer operations steward with finance escalation | The data team |
Write an object definition before selecting matching software. A customer may mean a person, household, legal entity, billing account, shipping location, or commercial relationship. Collapsing these into one record creates false merges; treating them all as unrelated creates duplicates. Model the relationships explicitly. Also distinguish master data from transactions: an order references a product and customer, but the order itself is not master data. This boundary keeps the first release small enough to understand.
Design identity, authority, and survivorship separately
Identity resolution decides whether records describe the same real-world object. Use deterministic keys where they exist, such as a verified registration number within a jurisdiction. Apply probabilistic or fuzzy matching only with explainable features, thresholds, and a review band. A match score is evidence, not truth. Keep the source IDs and the reason for a merge so a steward can reverse it. Never let a corrected spelling silently merge two legal entities that happen to share an address.
Record authority determines which source may set an attribute; survivorship determines which candidate value appears in the shared view. They are not interchangeable. ERP may own a billing status while CRM owns account assignment, and a verified external source may support legal name. Define precedence, freshness, effective dates, and manual override rules per attribute group. NIST's data governance definition emphasizes decision rights and accountability, which is exactly what an attribute matrix makes operational.
| Attribute group | Authority example | Validation and conflict rule | Correction owner |
|---|---|---|---|
| Legal identity | Verified registry process | Registration number must be unique by jurisdiction; conflicting evidence is held for review | Compliance or customer operations |
| Commercial relationship | CRM | Active owner must be a valid employee and segment must use current taxonomy | Sales operations |
| Billing account | ERP | Currency and payment terms require approved values; posted history is not rewritten | Finance operations |
| Delivery location | Order or logistics workflow | Normalize address but preserve user-entered evidence and effective dates | Fulfilment operations |
| Consent or preference | Consent service | Purpose, channel, source, and timestamp travel together | Privacy owner |
Make stewardship a real operating service
A steward needs more than permission to edit a record. Give the role a queue containing suspected duplicates, rejected publications, source conflicts, stale records, and downstream corrections. Each item should show the object, source evidence, affected processes, proposed action, and deadline. Set service levels by consequence: a product missing a safety classification deserves a different response from an unused marketing label. Preserve who decided, what changed, why, and which systems acknowledged the correction.
Use privacy and security constraints at the design stage. The NIST Privacy Framework can help teams connect data processing to privacy risk, while NIST's developing Data Governance and Management Profile provides a current reference point for governance outcomes. Minimize replicated sensitive attributes, limit steward access by purpose, and make export, deletion, correction, and retention behavior explicit. A consolidated record can magnify harm if it becomes an unrestricted directory.
Implement a narrow MDM release
- Map the selected object's identifiers, source systems, consumers, sensitive attributes, and known failure patterns.
- Create a canonical model that preserves source identifiers and business relationships rather than flattening every field.
- Write attribute authority, matching, validation, survivorship, and manual override rules as versioned decisions.
- Profile representative data, including duplicates, missing values, stale records, conflicting sources, and legitimate lookalikes.
- Run matching in shadow mode; have stewards label false matches and missed matches before publishing shared IDs.
- Publish through idempotent interfaces with version, effective time, and rejection feedback; do not rely on periodic blind overwrites.
- Reconcile each consumer, test correction and unmerge, then expand only after the first process shows a measurable outcome.
A useful pilot might cover active business customers used by CRM and ERP. First issue a stable enterprise customer ID without changing source ownership. Then publish verified identity and relationship links. Finally, move one high-value attribute group under governed authority. This staged approach separates matching quality from integration defects. It also lets the team stop before a bad rule propagates widely. The current UK data quality issues framework recommends defining rules, targets, performance bands, and priority according to purpose and impact; those elements translate well into MDM release gates.
Measure quality and operating impact
| Measure | What it reveals | Guardrail |
|---|---|---|
| Duplicate rate in a defined population | Whether identity rules reduce fragmented records | Track false merges and unmerge volume |
| Critical attribute rule pass rate | Whether records are fit for a named process | Do not average away high-impact fields |
| Steward queue age | Whether governance has enough capacity and authority | Segment by severity and source |
| Consumer rejection rate | Whether publication contracts and values are usable | Reconcile silent drops separately |
| Downstream rework | Whether MDM changes orders, payments, support, or reporting | Compare with a stable pre-release baseline |
Review a sample of ordinary, corrected, and disputed records monthly. Ask whether the source captured the right fact, whether matching evidence was sufficient, whether the authoritative owner could act, and whether downstream consumers applied the change. A dashboard can show volume; case review finds the faulty rule. Feed recurring issues to the source application or process rather than turning the stewardship team into permanent data-cleaning labor.
Govern schema and rule changes as product changes. A new identifier, merged hierarchy, address parser, survivorship rule, or source priority can alter thousands of records without changing the integration interface. Preview the affected population, compare old and new values, sample high-consequence objects, obtain domain approval, and provide a rollback or compensating correction. Notify consumers when meaning changes, not only when a field changes shape. Keep deprecated values long enough for coordinated migration and reconcile every consumer after cutover. This discipline prevents a technically successful MDM release from creating a business-wide semantic break.
A quarterly domain review should decide whether to deepen the current object or add another one. Expansion is justified when stewards meet service expectations, false merges remain controlled, consumers reconcile, privacy controls work, and downstream rework has fallen. If the team still resolves most cases through undocumented judgment, adding another domain spreads ambiguity. Invest first in clearer source capture, ownership, and correction tools.
Frequently asked questions
Do we need an MDM platform?
Not always. A growing team can prove the object model, source authority, rules, stewardship queue, and publication contract with existing integration and data tools. A platform becomes valuable when matching volume, hierarchy management, workflow, lineage, or multi-domain governance exceeds that foundation. Buying first often hides unresolved ownership behind configuration.
Is a golden record a single source of truth?
It is better understood as a governed shared representation. Source applications can remain authoritative for different facts. The shared record should expose provenance, effective time, and conflicts instead of pretending every value came from one omniscient database.
Which domain should a growing team start with?
Choose the domain behind a frequent, costly cross-system failure and with an owner willing to resolve policy. Customer and product are common, but supplier, location, or employee data may produce faster value. Start where correction can be measured, not where the object sounds most strategic.
Conclusion
Master data management succeeds when people can identify a shared business object, explain each important value, correct it once, and see the correction reach the work that depends on it. A narrow object model, attribute-level authority, reversible matching, an owned stewardship queue, and outcome-based measures create that capability. Scale domains only after the first one demonstrates that governance and integration can improve real decisions together.