Master Data Management Design: [Domain] at [Organisation]
Solution design for a master data management (MDM) hub: domains and
scope, the implementation style (registry, consolidation, coexistence
or centralised), the master data model and golden record, the system
of record matrix, match and merge, survivorship, stewardship workflow,
hierarchies and reference data, quality KPIs, distribution, security
and privacy, governance and rollout. The structure is aligned with the
Reference and Master Data knowledge area of DAMA-DMBOK 2nd Edition
Revised (2024). Replace every [bracketed] value and every row marked
Example. Worked examples follow a customer domain for a retailer
with four source systems.
Document control
| Field | Value |
|---|
| Document ID | [MDM-001] |
| Master data domain(s) | [Customer / Product / Supplier / Location / Employee] |
| Implementation style | [Registry / Consolidation / Coexistence / Centralised] |
| MDM product or build | [Product name and version / Custom build] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@mdm-architect] |
| Data owner (business) | [@domain-data-owner] |
| Approvers/reviewers | [@chief-data-officer], [@enterprise-architect], [@dpo], [@source-system-owners] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
Approvals
| Role | Name | Decision | Date |
|---|
| Business data owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
| Source system owners | [@names] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for customer domain, consolidation style |
| 1.1 | YYYY-MM-DD | [@name] | Example: Moved to coexistence; CRM writes back golden attributes |
Contents
1. Scope, domains and drivers
1.1 Drivers
| ID | Driver | Current impact | Target |
|---|
| MDR-001 (Example) | The same customer exists in POS loyalty, e-commerce and CRM with different identifiers | Marketing sends duplicate mail; 8 % estimated duplicate rate | One customer identifier across channels; duplicate rate below 1 % |
| MDR-002 (Example) | Consent preferences differ between systems | Complaints and regulatory risk | Consent held once and distributed within 15 minutes |
| MDR-003 (Example) | Finance cannot report revenue per customer group | Manual spreadsheet mapping each quarter | Customer hierarchy maintained in the hub |
| [MDR-NNN] | [Driver] | [Impact] | [Target] |
1.2 Domain scope
| Entity | Mastered attributes | Not mastered (left in sources) | Consuming processes |
|---|
| Customer (person) (Example) | Name, date of birth, email, phone, postal address, consent flags, loyalty tier | Order history, payment tokens, web behaviour | Marketing, service, loyalty, finance reporting |
| Customer (organisation) (Example) | Legal name, registration number, VAT number, addresses, parent | Credit limit (owned by ERP) | B2B sales, invoicing |
| [Entity] | [Attributes] | [Attributes] | [Processes] |
Reference data (code lists such as country, currency, customer
segment) is in scope in section 8 because the golden record depends on
it.
2. Implementation style
2.1 Style comparison
| Style | How it works | Golden record stored | Write-back to sources | Typical use | Organisational impact |
|---|
| Registry | Hub holds identifiers and match links only; attributes stay in sources and are assembled at read time | No (virtual) | No | Fast cross-reference, read-only analytics | Low |
| Consolidation | Hub copies source records, matches and merges them into a golden record for downstream reading | Yes | No | Analytics and reporting on a single view | Low to medium |
| Coexistence | Golden record built as in consolidation and published back so sources align; several systems still create records | Yes | Yes | Operational alignment while keeping existing entry points | Medium to high |
| Centralised (transactional) | Records are created and maintained in the hub and distributed to sources, which stop creating them | Yes, authoritative | Hub is the source | Strong control, regulated data | High |
2.2 Decision
| Criterion | Weight | Registry | Consolidation | Coexistence | Centralised |
|---|
| Meets MDR-001 (single identifier) (Example) | 5 | 4 | 4 | 5 | 5 |
| Meets MDR-002 (consent distributed) (Example) | 5 | 1 | 2 | 5 | 5 |
| Source change effort (Example) | 3 | 5 | 5 | 3 | 1 |
| Time to first value (Example) | 3 | 5 | 4 | 3 | 2 |
| Weighted total (Example) | | 55 | 57 | 68 | 59 |
The weighted total is the sum of weight multiplied by score. Coexistence:
5 x 5 + 5 x 5 + 3 x 3 + 3 x 3 = 68. Centralised: 25 + 25 + 3 + 6 = 59.
Consolidation: 20 + 10 + 15 + 12 = 57. Registry: 20 + 5 + 15 + 15 = 55.
Add criteria for cost, product fit and regulatory control before deciding;
recompute every total when a score or weight changes.
Example decision: coexistence for the customer domain, starting as
consolidation in phase 1 (read-only golden record) and adding write-back
in phase 2. Record the decision as an ADR in the Architecture Decision
Log (architecture/architecture-decision-log).
3. Master data model and golden record
3.1 Entities
The Example hub model uses a party pattern: one golden party with
addresses, contacts, consents and relationships, and one cross-reference
row per contributing source record.
3.2 Golden record attributes
| Attribute | Type | Mastered from | Survivorship rule | Quality rule | Classification |
|---|
| master_id (Example) | String (opaque, generated) | Hub | Never changes; merged records keep a pointer to the survivor | Unique, not null | Internal |
| given_name, family_name (Example) | String | CRM, e-commerce, POS loyalty | SRV-001 | Not null, no digits | Personal |
| email (Example) | String | E-commerce, CRM | SRV-002 | Valid syntax, verified flag | Personal |
| postal_address (Example) | Structured address | CRM, e-commerce | SRV-003 | Validated against address reference | Personal |
| consent_marketing_email (Example) | Boolean plus timestamp and channel | Consent service | SRV-004 | Timestamp required | Personal, consent |
| loyalty_tier (Example) | Code (reference data) | POS loyalty | Source of record only | Code in list | Internal |
| [Attribute] | [Type] | [Sources] | [Rule ID] | [Rule] | [Class] |
Keep attribute definitions in the Data Dictionary
(architecture/data-dictionary) and link each attribute here to its
dictionary entry. Store, for every golden attribute, the contributing
source, the source timestamp and the rule that selected it, so that any
value can be explained to an auditor or a data subject.
3.3 Identifier policy
- Generate the master identifier in the hub; never derive it from
personal data.
- When two golden records merge, keep the survivor's identifier and keep
the retired identifier as an alias pointing to the survivor, so
downstream systems that stored it can still resolve it.
- When a merge is reversed (unmerge), restore both identifiers and
publish correction events (section 10).
4. Sources and system of record
| Source system | Owner | Records | Customer person | Customer organisation | Consent | Integration | Latency |
|---|
| CRM (Example) | @crm-owner | 3.5 million | C R U | C R U | R | Change events and API | Near real time |
| E-commerce (Example) | @ecom-lead | 5.0 million | C R U | None | C R U | CDC | Near real time |
| POS loyalty (Example) | @retail-ops | 2.8 million | C R U | None | R | Nightly file, then CDC in phase 2 | Daily |
| ERP (Example) | @erp-owner | 0.7 million | R | C R U | None | Batch API | Daily |
| MDM hub (Example) | @mdm-architect | Golden records | R U (golden) | R U (golden) | R | Publishes events and API | Under 15 minutes |
| [System] | [@owner] | [Count] | [CRUD] | [CRUD] | [CRUD] | [Method] | [Latency] |
The Example sources hold 3.5 + 5.0 + 2.8 + 0.7 = 12.0 million source
records. Section 5.4 sizes matching from this total.
5. Match and merge
5.1 Standardisation before matching
- Normalise case, whitespace and diacritics in names.
- Parse and validate addresses against the address reference service.
- Normalise phone numbers to international format.
- Lower-case email addresses and remove known alias patterns only where
the provider documents them.
- Keep the original value alongside the standardised one.
5.2 Blocking and match rules
| ID | Type | Blocking key | Comparison | Outcome |
|---|
| MR-001 (Example) | Deterministic | Verified email | Exact email and same family name | Auto-merge |
| MR-002 (Example) | Deterministic | Phone (international) | Exact phone and date of birth | Auto-merge |
| MR-003 (Example) | Probabilistic | Postcode plus first 3 letters of family name | Weighted score on name, address, birth date, phone | By threshold (5.3) |
| MR-004 (Example) | Organisation | VAT or registration number | Exact identifier | Auto-merge |
| [MR-NNN] | [Type] | [Key] | [Comparison] | [Outcome] |
5.3 Thresholds
| Score band | Decision | Owner |
|---|
| 0.92 and above (Example) | Auto-merge | System |
| 0.75 to below 0.92 (Example) | Steward review task | Data steward |
| Below 0.75 (Example) | No match | System |
Measure precision (merged pairs that are true duplicates) and recall
(true duplicates found) on a labelled sample of at least [2,000] pairs
per country. False merges are usually more harmful than missed matches:
they mix two people's personal data. Set the auto-merge threshold for
precision first.
5.4 Workload sizing (Example)
| Step | Calculation | Result |
|---|
| Comparisons without blocking | 12,000,000 x 11,999,999 / 2 | about 7.2 x 10^13 pairs (infeasible) |
| Blocks at an average of 20 records each | 12,000,000 / 20 | 600,000 blocks |
| Comparisons per block | 20 x 19 / 2 | 190 |
| Comparisons with blocking | 600,000 x 190 | 114,000,000 pairs |
| Records in the review band (0.5 %) | 12,000,000 x 0.005 | 60,000 review tasks |
| Steward capacity (5 stewards x 120 tasks per day) | 5 x 120 | 600 tasks per day |
| Initial backlog duration | 60,000 / 600 | 100 working days |
Consequence: a 100-day backlog is longer than the phase 1 timeline. Raise
the auto-merge band only if the labelled sample still shows precision of
at least [99.5 %], add temporary stewards for the initial load, or
prioritise review tasks for active customers (purchase in the last 12
months) first. Ongoing daily volume is much smaller: size it from new
records per day multiplied by the review-band rate.
6. Survivorship
| ID | Attribute | Rule type | Rule | Tie-break |
|---|
| SRV-001 (Example) | Names | Source priority with recency | CRM over e-commerce over POS loyalty, unless the lower-priority value is newer by more than 180 days and verified | Steward review |
| SRV-002 (Example) | Email | Validated wins | Verified email (confirmed link) wins; otherwise most recent | Most recent |
| SRV-003 (Example) | Postal address | Validated and recent | Address validated by reference service and most recently used for delivery | Source priority |
| SRV-004 (Example) | Consent | Most recent event | Latest consent event from any channel, with timestamp and channel retained | Never merged by priority |
| SRV-005 (Example) | Any attribute | Steward override | Steward value locked until a newer verified source value arrives | Steward |
| [SRV-NNN] | [Attribute] | [Type] | [Rule] | [Tie-break] |
7. Stewardship workflow
| Task type | Created by | Service level (Example) | Escalation |
|---|
| Potential match review | MR-003 band 0.75 to 0.92 | 5 working days | Data owner after 10 days |
| Quality exception | Quality rules in section 9 | 3 working days | Domain lead |
| Hierarchy change request | Business user request | 10 working days | Data owner |
| Unmerge request | Steward or customer complaint | 1 working day | DPO when personal data was mixed |
| Data subject request | Privacy team | Within the legal deadline, internal target 10 days | DPO |
| [Task] | [Source] | [SLA] | [Escalation] |
Log every steward decision with the user, time, before and after values
and reason. Use the log to retrain or adjust match rules each quarter.
8. Hierarchies and reference data
8.1 Hierarchies
| ID | Hierarchy | Levels | Source of truth | Change approval | Effective dating |
|---|
| HIE-001 (Example) | Corporate customer family | Ultimate parent, parent, legal entity | Hub, enriched from a business register | Data owner | Valid from and valid to |
| HIE-002 (Example) | Customer segment | Segment, sub-segment | Hub | Marketing data owner | Monthly versions |
| [HIE-NNN] | [Name] | [Levels] | [Source] | [Approver] | [Dating] |
8.2 Reference data
| Code list | Standard or owner | Version control | Distribution |
|---|
| Country (Example) | ISO 3166-1 alpha-2 | Updated when the maintenance agency publishes changes | Published to all sources |
| Currency (Example) | ISO 4217 | As above | Published to all sources |
| Customer segment (Example) | Marketing | Versioned in the hub | Event on change |
| [Code list] | [Standard or owner] | [Control] | [Distribution] |
9. Data quality KPIs
| ID | KPI | Definition | Target (Example) | Frequency |
|---|
| KPI-001 (Example) | Duplicate rate | Estimated true duplicates among golden records, from a monthly sample | Below 1 % | Monthly |
| KPI-002 (Example) | False merge rate (detected) | Unmerges divided by merges in the period; validate quarterly against a labelled sample, because unmerges show only the false merges someone noticed | Below 0.1 % | Monthly |
| KPI-003 (Example) | Completeness of mandatory attributes | Golden records with all mandatory attributes populated | 98 % | Weekly |
| KPI-004 (Example) | Address validity | Addresses that pass reference validation | 95 % | Weekly |
| KPI-005 (Example) | Steward backlog age | Open tasks older than the service level | Below 5 % | Weekly |
| KPI-006 (Example) | Distribution latency | Time from golden record change to receipt by subscribers (p95) | Under 15 minutes | Daily |
| [KPI-NNN] | [KPI] | [Definition] | [Target] | [Frequency] |
10. Distribution and integration
| ID | Channel | Consumers | Content | Contract |
|---|
| DST-001 (Example) | Change events (created, updated, merged, unmerged) | CRM, e-commerce, marketing | Golden record plus retired identifiers on merge | AsyncAPI 3.1.0 document |
| DST-002 (Example) | Lookup API by master or source key | Service desk, web | Golden record and cross-reference | OpenAPI document |
| DST-003 (Example) | Daily snapshot to the data platform | Analytics | Golden records, cross-reference, hierarchy | Data contract (ai-data/data-contract) |
| [DST-NNN] | [Channel] | [Consumers] | [Content] | [Contract] |
Require every subscriber to handle merge and unmerge events: on merge,
replace the retired identifier with the survivor; on unmerge, split the
local data or flag it for review. Interface details belong in the
Integration Design (architecture/integration-design).
11. Security and privacy
| Topic | Design (Example) |
|---|
| Access | Stewards see only their countries; search results limited and logged |
| Privileged actions | Merge, unmerge and bulk updates need a steward role and are logged with reason |
| Encryption | At rest with customer-managed keys; TLS in transit |
| Data minimisation | Only attributes needed by two or more processes are mastered (section 1.2) |
| Erasure | An erasure request deletes or anonymises the golden record and publishes an erasure event that every subscriber must honour within [30] days |
| Lawful basis and records | Processing recorded in the record of processing activities (compliance/gdpr-ropa); DPIA in compliance/dpia |
| Residency | Golden records stored in the region of the customer's country; see compliance/data-residency-sovereignty-assessment |
| Threats | Mass export, insider browsing, false merges that disclose data to the wrong person; analysed in security/privacy-threat-model |
12. Governance and RACI
| Activity | Data owner | Data steward | MDM architect | Source system owner | DPO |
|---|
| Define mastered attributes | A | R | C | C | C |
| Approve match and survivorship rules | A | R | R | C | C |
| Review match tasks | I | R, A | I | I | I |
| Approve hierarchy changes | A | R | I | I | I |
| Change integration contracts | C | I | A | R | I |
| Handle data subject requests | A | R | I | R | C |
| Report quality KPIs | A | R | C | I | I |
Run a monthly data governance meeting for the domain with the KPI report,
open escalations and rule change requests. Record rule changes with a
version number and an effective date.
13. Non-functional requirements and sizing
| ID | Requirement | Target (Example) | Derivation |
|---|
| MNF-001 | Golden record count after initial load | About 9.6 million | 12.0 million source records with an estimated 20 % overlap: 12.0 x 0.8 = 9.6 million |
| MNF-002 | Initial match run duration | Under 8 hours | 114 million comparisons in 8 hours is 114,000,000 / 28,800 = about 3,958 comparisons per second |
| MNF-003 | Steady-state updates | 50,000 per day, peak 20 per second | Source change rates from section 4 |
| MNF-004 | Lookup API latency | p95 under 200 ms | Service desk screen budget |
| MNF-005 | Availability | 99.9 % for lookup API | Operational dependency in coexistence |
| MNF-006 | Recovery | RPO 15 minutes, RTO 4 hours | Resilience tier 2 |
| [MNF-NNN] | [Requirement] | [Target] | [Derivation] |
Record cross-cutting targets in the NFR Catalogue
(requirements/nfr-catalogue).
14. Rollout, migration and risks
14.1 Phases
| Phase | Scope | Exit criteria |
|---|
| 1. Consolidation (Example) | Load CRM, e-commerce and POS loyalty; golden record read-only to analytics | Precision at least 99.5 % on labelled sample; backlog plan approved |
| 2. Coexistence (Example) | Publish golden attributes and consent back to CRM and e-commerce | All subscribers pass merge and unmerge tests |
| 3. Organisation customers (Example) | Add ERP and the corporate hierarchy | Finance confirms revenue by customer family |
| [Phase] | [Scope] | [Criteria] |
The initial load follows the Data Migration Strategy
(architecture/data-migration-strategy); reconcile counts per source with
the Data Migration Reconciliation Report
(project/data-migration-reconciliation).
14.2 Risks
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| RSK-001 (Example) | False merges expose one customer's data to another | Medium | High | Precision-first thresholds, unmerge in 1 day | @data-steward-lead |
| RSK-002 (Example) | Source owners keep creating duplicates | High | Medium | Search-before-create API in phase 2 | @mdm-architect |
| RSK-003 (Example) | Steward backlog never clears | Medium | Medium | Section 5.4 actions, KPI-005 | @data-owner |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
15. Glossary and references
| Term | Meaning |
|---|
| Golden record | Best available single version of a master entity, assembled from sources |
| Cross-reference | Link from a golden record to each source record that contributed |
| Blocking | Grouping records by a key so that only records in the same group are compared |
| Survivorship | Rules that choose which source value becomes the golden value |
| Steward | Person who resolves data issues and match decisions for a domain |
| Unmerge | Reversal of a merge that combined records of different real-world entities |
| Reference data | Controlled code lists used to classify other data |
References: DAMA-DMBOK 2nd Edition Revised (DAMA International, 2024),
Reference and Master Data and Data Quality knowledge areas (names only);
ISO 3166-1 and ISO 4217 code lists; AsyncAPI Specification 3.1.0
(asyncapi.com, January 2026); [MDM product documentation, version];
[Internal data governance policy].
Standard and licence note
Structure aligned with the Reference and Master Data knowledge area of
DAMA-DMBOK 2nd Edition Revised (DAMA International, 2024); only the
knowledge area names are used and no text, figures or definitions from
the book are reproduced. The four implementation styles are described in
original wording from common industry practice. This template is
original text written for this collection. Check the current official
editions and your MDM product documentation before use. DAMA-DMBOK is a
trademark of DAMA International; this template is not affiliated with or
endorsed by it. Template licence: MIT.