Glossary
Master data management
Master data management governs shared records for core entities across systems and organizational uses.
Identity and entity resolution
Master data management is the set of practices for maintaining consistent descriptions of core entities such as organizations, products and locations. It addresses identifiers, ownership, quality rules and distribution of approved records across systems. Its scope is organizational as well as technical: different departments may use the same term at different levels of granularity, so a shared record requires explicit definitions and responsibilities.
In practice, an organization identifies source systems, defines canonical entities and reconciles duplicates and conflicting attributes. Policies govern who can change records, how evidence is reviewed and how updates reach consumers. A golden record can be one output, but some use cases need multiple context-specific views rather than one universal value for every field.
Defensibility requires knowing which system asserted an attribute, why the shared view uses it and which consumers saw which version. A single source of truth slogan is insufficient when source authority differs by property. Entity resolution establishes identity; survivorship rules select attributes; provenance and audit trails make the resulting decisions inspectable.
Example
Fictional Halden Therapeutics AG finance and research systems use different addresses; governance specifies which address each business purpose requires.
Scope and the usual implementation styles
Master data are the core entities that many systems share: customers, suppliers, products, organisations, sites, accounts. Master data management is the discipline of keeping a consistent, governed view of them across those systems. DAMA's body of knowledge places it inside data management alongside data quality, governance and integration, and the Wikipedia overview summarises the practice. The implementation styles below are the ones usually distinguished. In a registry style the hub stores only identifiers and links, leaving attributes in the source systems. In a consolidation style the hub holds a derived golden copy for reporting. In a centralised style the hub is the system of entry and publishes changes to the others. A coexistence style combines these. The choice determines where corrections are made and how quickly they reach consumers.
Whatever the style, the working parts are the same: matching to decide when records describe one entity, survivorship rules to decide which values prevail, stewardship workflows for cases that automation cannot settle, and publication of the result with its identifiers. Each part can be audited, and each leaves a trail that the others depend on.
Governance decisions that matter more than software
The failures of master data programmes are mostly failures of decision rights. Someone must own each entity type and each attribute, with authority to resolve disputes between systems. Rules for survivorship should be written, versioned and approved, not embedded in a configuration nobody reads. A change to a rule should be tested against a sample and its effect on existing records reported before it is applied. A data steward needs a queue of cases that is short enough to clear and a record of each decision. A correction in a source needs a defined path to the master and from the master to consumers.
Measure the programme by outcomes. Useful measures include the proportion of records matched without review, the error rate found in sampled reviews, the time from source change to consumer visibility, and the number of conflicts open beyond a stated age. They tell a reviewer more than counts of records loaded. The article on auditing the multiple-sources-of-truth assumption offers a way to test whether the organisation really has one authoritative account for a given fact.
A worked example
A manufacturer's finance, procurement and quality systems each hold a supplier record. A master data hub matches them on tax number and address, creates a supplier identifier, and applies rules: legal name from the tax authority extract, payment terms from finance, audit status from quality. A merger changes the supplier's legal name. Procurement updates its record on Monday; finance updates on Thursday; quality never does. The hub detects the legal-name mismatch against the tax-authority extract on Friday, opens a steward task, and publishes the corrected name to all three systems once approved, with the decision logged. The value of the hub is visible in the log: who knew what, when, and who decided.
Related terms and boundaries
Master data management relies on entity resolution, produces golden records under survivorship rules, and stands next to the idea of a system of record. Its audit needs an audit trail. It is a governance practice with technical supports and not a product, and the best technical design cannot compensate for the absence of agreed ownership.
Common misreadings
- Assuming one source owns every attribute.
- Publishing a shared record without source lineage.
- Ignoring different entity granularity across departments.
Appears in
- Master data management vs knowledge fusion
MDM governs shared business entities; knowledge fusion reconciles assertions drawn from multiple sources.
References
- Otto (2012), How to design the master data architecture: Findings from a case study at Bosch, International Journal of Information Management 32(4).
- DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.
- Wikipedia, Master data management.
- Wikidata, Help:Ranking (preferred, normal and deprecated statements).
- Hogan et al. (2021), Knowledge Graphs, ACM Computing Surveys 54(4).
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Where does "Master data management" bear on a decision of yours?
This entry sits under identity and entity resolution. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.
Or write to [email protected] in your own words.