Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25642:2023 — Master Data Management Reference Architecture
A blueprint for enterprise master data ecosystems
ISO/IEC 25642:2023 defines a reference architecture for Master Data Management (MDM) — the integrated set of processes, governance structures, and technical capabilities for managing an enterprise’s core business entities (customers, products, suppliers, locations, assets) as trusted, authoritative, and shareable assets. The standard provides a vendor-neutral architectural blueprint that organizations can use to design, evaluate, or mature their MDM capabilities. As the capstone of the ISO/IEC data management standards family (alongside 25389 on data quality, 25422 on provenance, and 25434 on reference data), 25642 integrates these concerns into a cohesive architecture.
ISO/IEC 25642 is technology-agnostic and applies to any MDM implementation — whether on-premises, cloud-native, or hybrid. The reference architecture is expressed in terms of functional components, data flows, and integration patterns, not specific products or platforms.
1. MDM Architecture Layers and Components
The reference architecture is organized into five layers: (L1) Data Source Layer — the operational systems (CRM, ERP, SCM) that create and consume master data; (L2) MDM Hub Layer — the core processing engine that ingests, cleanses, matches, merges, and publishes master data; (L3) Data Consumption Layer — analytical systems (data warehouse, BI, AI/ML) and operational systems that consume mastered data; (L4) Governance and Stewardship Layer — the tools and workflows for data governance, quality monitoring, and exception handling; and (L5) Infrastructure and Security Layer — identity management, access control, encryption, and audit logging.
The MDM Hub Layer (L2) is further decomposed into seven functional components: (1) data ingestion and parsing, (2) data cleansing and standardization, (3) identity resolution (matching/merge/survivorship), (4) golden record creation and versioning, (5) relationship management (hierarchy and cross-entity links), (6) data distribution and synchronization, and (7) hub administration and monitoring.
| Layer | Components | Key Engineering Considerations |
|---|---|---|
| L1 — Data Source | CRM, ERP, SCM, legacy systems | API versioning, change data capture (CDC), data quality at source |
| L2 — MDM Hub | Ingestion, cleansing, matching, merging, golden record | Scalability (horizontal), matching algorithm accuracy, latency |
| L3 — Consumption | Data warehouse, BI, operational apps | Data freshness SLAs, bidirectional sync conflicts |
| L4 — Governance | Stewardship console, quality dashboards, workflow | Role-based access, audit trail, exception handling |
| L5 — Infrastructure | IAM, encryption, logging, monitoring | GDPR compliance, data residency, encryption at rest/transit |
A common architectural mistake: building the MDM hub as a passive registry that only stores golden records without actively synchronizing corrections back to source systems. This creates a ‘golden record graveyard’ — mastered data that exists in the hub but is never used operationally because source systems continue to operate with unclean data.
2. MDM Implementation Patterns
The standard identifies five MDM implementation patterns: (P1) Registry — a lightweight index that stores only identifiers and pointers to source records; (P2) Coexistence — the hub stores a golden record alongside the source records and publishes via API; (P3) Transaction Hub — the hub becomes the authoritative system for master data transactions, with source systems forwarding write operations through it; (P4) Composite — a hybrid approach where some entities use Registry and others use Transaction Hub; and (P5) Data Federation — no central store; master data is assembled on-the-fly via query routing.
For most large enterprises, the Composite pattern (P4) is the most practical. Customer master data may warrant a Transaction Hub due to compliance and privacy requirements, while supplier master data may be adequately served by a Coexistence pattern. The standard provides decision criteria (data volume, update frequency, consistency requirements, regulatory constraints) for selecting the appropriate pattern per entity type.
A Fortune 500 retailer implemented the Composite MDM pattern using the 25642 reference architecture: Transaction Hub for customer data (GDPR compliance), Coexistence for product data (catalog-driven updates), and Registry for location data (low change frequency). The project achieved 99.97% identity resolution accuracy across 120 million customer records.
3. Identity Resolution and Golden Record Construction
Identity resolution — the process of determining whether two records refer to the same real-world entity — is the most technically challenging component of any MDM system. The standard recommends a probabilistic matching approach (using the Fellegi-Sunter model or machine learning-based classifiers) over deterministic matching for all but the simplest use cases. The matching engine should consider multiple attributes with weightings, handle missing values gracefully, and produce a match confidence score.
The golden record construction process (survivorship) defines how conflicting attribute values from multiple source records are reconciled into a single authoritative value. The standard defines five survivorship rules: (1) most recent update wins, (2) most trusted source wins, (3) longest value wins (for string attributes), (4) specific source priority (e.g., CRM over ERP for customer name), and (5) manual stewardship override. These rules should be configurable per attribute and per source system.
A critical operational risk: automated merging without human review for low-confidence matches. The standard mandates that matches below a configurable confidence threshold must be routed to a data steward for manual review. Automatically merging low-confidence matches creates golden records that compound data quality issues rather than resolving them.
Frequently Asked Questions
Q: How does ISO/IEC 25642 differ from the MDM patterns described in Gartner or Forrester reports?
Those reports describe implementation patterns and product evaluations from an analyst perspective. ISO/IEC 25642 provides a formal reference architecture with explicit layer definitions, component responsibilities, and data flow specifications that can be used as a requirements baseline for procurement or as a blueprint for custom development.
Those reports describe implementation patterns and product evaluations from an analyst perspective. ISO/IEC 25642 provides a formal reference architecture with explicit layer definitions, component responsibilities, and data flow specifications that can be used as a requirements baseline for procurement or as a blueprint for custom development.
Q: What is the role of machine learning in MDM according to 25642?
The standard identifies three ML application areas: (1) matching algorithm enhancement — ML-based classifiers can outperform traditional Fellegi-Sunter models in accuracy; (2) golden record enrichment — predicting missing attribute values from known ones; and (3) anomaly detection — flagging records that deviate unexpectedly from established master data patterns.
The standard identifies three ML application areas: (1) matching algorithm enhancement — ML-based classifiers can outperform traditional Fellegi-Sunter models in accuracy; (2) golden record enrichment — predicting missing attribute values from known ones; and (3) anomaly detection — flagging records that deviate unexpectedly from established master data patterns.
Q: Can 25642 be applied to multi-domain MDM (customer, product, supplier in one platform)?
Yes. The reference architecture is domain-agnostic. The standard recommends a multi-domain MDM hub with separate entity type configurations rather than separate physical instances. This allows cross-domain relationship management (e.g., linking customer to product via purchase history) within a single hub.
Yes. The reference architecture is domain-agnostic. The standard recommends a multi-domain MDM hub with separate entity type configurations rather than separate physical instances. This allows cross-domain relationship management (e.g., linking customer to product via purchase history) within a single hub.
Q: How does the standard address master data quality in real-time integration scenarios?
The standard recommends a ‘measure at ingestion, enrich at rest, verify on read’ strategy. Data quality checks should run during ingestion (L2), enrichment and survivorship should be computed asynchronously, and the golden record served at read time should include a quality score that consumers can use to assess fitness for purpose.
The standard recommends a ‘measure at ingestion, enrich at rest, verify on read’ strategy. Data quality checks should run during ingestion (L2), enrichment and survivorship should be computed asynchronously, and the golden record served at read time should include a quality score that consumers can use to assess fitness for purpose.
📥 Standard Documents Download
No download files available yet