Master data management strategy sounds reasonable. Maintain one authoritative source for customer data, product catalogs, or organizational hierarchies. All systems read from this golden record. Updates flow through the MDM system to ensure consistency.
This works in architecture diagrams. Production tells a different story, the same gap described in data strategies that fail in production.
Systems that were supposed to use the MDM system still maintain local copies because they cannot tolerate the latency. The golden record exists, but so do dozens of divergent copies. Changes propagate at different speeds. Conflicts emerge that the merge logic was not designed to handle.
The strategy assumes the MDM system can win every fight. It cannot.
The Golden Record Problem
A golden record is supposed to be the single source of truth. Customer data exists in the CRM, billing system, support ticketing, and analytics warehouse. The MDM system merges these into one authoritative record.
The merge logic must resolve conflicts. The CRM says the customer email is old@example.com. The billing system has new@example.com. Which one wins?
Most MDM strategies use precedence rules, although platform guidance such as Microsoft Purview data-quality rules makes clear that rules only help when ownership and meaning are explicit. Billing data takes priority because payment requires accurate contact information. This works until the CRM receives a direct customer update after the billing system updated but before the MDM sync ran.
Now you have:
- CRM:
new@example.com(customer update at 10:02) - Billing:
new@example.com(system update at 10:00) - MDM:
old@example.com(last sync at 9:55)
The next MDM sync sees the CRM update at 10:02 and billing update at 10:00. Billing has precedence, so it takes new@example.com from billing and overwrites the CRM with the same value. Everything looks consistent.
Then a support ticket arrives via urgent@example.com, which does not exist in any system. The customer cannot be identified. The ticket sits unrouted.
The golden record was consistent but wrong. The actual current email was never in any source system.
When Sync Delays Exceed Business Tolerance
MDM systems sync on intervals. Every 5 minutes, every hour, nightly. The interval determines how stale the golden record can be.
Real-time sync sounds better but scales poorly. Every source system update triggers an MDM update, which triggers writes back to other source systems. A single customer change can generate dozens of database writes.
Under load, the sync queue grows. The 5-minute interval becomes 20 minutes, then an hour. Systems that depend on current data start querying source systems directly instead of the MDM system.
Now you have two data paths:
- The MDM path with merge logic and governance but high latency
- The direct path with low latency but no consistency guarantees
A customer updates their address in the CRM. The support agent queries the MDM system and sees the old address. They update it manually in the ticketing system. The MDM sync runs and overwrites the ticketing system with the CRM data. Now the ticketing system has the new address from the CRM but lost the agent’s notes that were attached to their manual update.
Data was not lost. Context was lost. The merge preserved records but destroyed meaning.
Match and Merge Logic at Scale
MDM systems must identify when different records refer to the same entity. This is the match problem. Then they must combine those records into one golden record. This is the merge problem, and it sits close to the broader question of which data can be trusted for analysis.
Matching seems straightforward. Compare email addresses, phone numbers, customer IDs. If two records share an email, they are the same customer.
This breaks immediately:
def match_customers(record_a, record_b):
"""Naive matching logic."""
if record_a['email'] == record_b['email']:
return True
if record_a['phone'] == record_b['phone']:
return True
return False
# Breaks on:
# - Shared family email addresses
# - Shared business phone numbers
# - Typos that changed one character
# - Format differences (+1-555-1234 vs 5551234)You add fuzzy matching. Now records that are 80% similar get matched. This catches typos but creates new problems. Different customers with similar names get merged incorrectly. The golden record represents two people, not one.
Merge logic must decide which fields from which records to keep:
def merge_records(records, precedence_order):
"""Merge multiple records into golden record."""
golden = {}
for field in ['email', 'phone', 'address', 'name']:
for source in precedence_order:
source_records = [r for r in records if r['source'] == source]
if source_records and source_records[0].get(field):
golden[field] = source_records[0][field]
break
return golden
# This loses minority values
# If 4 systems have old address, 1 has new address,
# and old address has higher precedence, the new address is lostThe merge creates a synthetic record that never existed in any source system. Queries against the golden record return data combinations that would fail validation in the original systems.
When Source Systems Refuse to Sync Back
The MDM system creates a golden record. Now it must propagate this back to source systems so they stay consistent.
Source systems often reject these updates.
The billing system has a foreign key constraint requiring every customer to have a payment method on file. The MDM golden record does not include payment methods because those are considered transactional data, not master data. The sync fails.
The CRM has custom fields that the MDM system does not track. When the MDM writes back to the CRM, it only updates the fields it manages. The CRM sees this as a partial update and rejects it for violating the application’s update policy.
You can make the MDM system aware of every source system’s validation rules and custom fields. Now the MDM schema includes the union of all source system schemas. It has billing-specific fields that only matter to billing and CRM fields that only matter to the CRM.
The golden record is no longer a simplified authoritative view. It is a denormalized union of every system’s data model. Changes to any source system’s schema require MDM schema changes.
Duplicate Detection After the Fact
MDM strategies assume duplicates are caught before they enter the system. They are not.
Two sales reps create customer records for the same company within minutes of each other. The MDM system has not synced yet. Both records enter source systems. Both get synced to MDM. Now the MDM system must detect that these are duplicates and merge them retroactively.
This requires:
- Identifying which existing golden record each new record should match
- Merging the golden records
- Propagating the merge back to source systems
- Updating all references to the old golden record IDs
The last step breaks most systems. The billing system has invoices referencing customer ID 1234. The MDM system determines 1234 is a duplicate of 5678 and merges them. Now the billing system should update all invoices from customer 1234 to reference customer 5678.
Most billing systems do not support retroactive customer ID changes. The foreign key is immutable after invoice creation. The MDM system cannot propagate the merge.
You can maintain a mapping table in the MDM system that says 1234 and 5678 are the same customer. Queries must join against this mapping to resolve the true golden record ID. This works until the chain grows: 1234 maps to 5678, which later maps to 9012, which maps to 3456.
Now a single customer lookup requires recursive joins through a mapping table that grows without bound.
Data Lineage When the Golden Record Lies
The golden record says the customer’s address is “123 Main St”. The support agent needs to know where this came from. Was it the CRM? Billing? A manual update?
Data lineage tracking in MDM systems records which source contributed which field. In practice, this breaks down quickly.
The address came from the CRM, which got it from a web form, which got it from the customer. But the customer typo’d their zip code. The billing system corrected the zip code based on address verification. The MDM merge took the street address from the CRM and the zip code from billing.
The golden record lineage says the address came from CRM and billing. It does not say which parts came from which system. The support agent cannot tell if the zip code is verified or user-entered.
You can track field-level lineage. Now the lineage table stores one row per field per record. The customer record has 30 fields. There are 10 million customers. The lineage table has 300 million rows. Queries against lineage become slower than queries against the actual data.
Most MDM systems compromise by tracking lineage at the record level, not the field level. The lineage says the customer record came from multiple sources but not which fields came from where. This is accurate but not useful.
When Business Rules Conflict Across Domains
MDM systems enforce business rules. Customer emails must be unique. Products must have SKUs. Organizations must have tax IDs.
These rules make sense within a domain. They break across domains.
The rule says customer emails must be unique. A customer uses shared@family.com for personal purchases and business purchases. The MDM system rejects the business customer creation because the email already exists.
The sales team escalates. They need a business customer record with this email. The MDM admin adds an exception: emails can be duplicated if the customer type differs.
Now you have:
- One personal customer with
shared@family.com - One business customer with
shared@family.com - Queries that filter by email return two customers
The marketing system sends two emails to the same address. The customer receives duplicate communications and complains. The marketing team adds logic to deduplicate by email before sending. This works until a different customer legitimately uses the same email as their spouse.
The business rule was correct for the narrow case. It failed when applied globally.
MDM Strategies That Survive Production
Effective master data management strategy assumes the golden record will diverge from source systems and plans for it.
Track divergence instead of preventing it:
def measure_mdm_consistency():
"""Compare MDM golden record vs source systems."""
inconsistencies = []
for customer_id in get_all_customer_ids():
golden = mdm.get_customer(customer_id)
crm_record = crm.get_customer(customer_id)
billing_record = billing.get_customer(customer_id)
for field in ['email', 'phone', 'address']:
values = {
'mdm': golden.get(field),
'crm': crm_record.get(field),
'billing': billing_record.get(field)
}
unique_values = set(v for v in values.values() if v)
if len(unique_values) > 1:
inconsistencies.append({
'customer_id': customer_id,
'field': field,
'values': values
})
return inconsistenciesWhen the MDM system and source systems disagree, you need visibility into which fields differ and by how much. This makes divergence measurable rather than invisible.
Accept that some source systems will never fully adopt the MDM system. Build read-through caching that queries the MDM system first and falls back to source systems:
class CustomerDataAccess:
def get_customer(self, customer_id):
"""Try MDM first, fall back to source systems."""
try:
customer = self.mdm_client.get_customer(customer_id)
if self._is_fresh(customer):
return customer
except MDMUnavailable:
pass
# MDM failed or data too stale, query sources directly
return self._build_customer_from_sources(customer_id)
def _is_fresh(self, customer):
"""Check if MDM data is recent enough."""
last_update = customer.get('_mdm_sync_time')
if not last_update:
return False
age_seconds = time.time() - last_update
return age_seconds < 300 # 5 minute thresholdThis does not enforce consistency. It provides availability when the MDM system cannot meet latency requirements, a tradeoff that resembles eventual consistency where it is not acceptable.
Make merge conflicts explicit rather than hiding them in precedence rules:
class ConflictAwareGoldenRecord:
def __init__(self, customer_id):
self.customer_id = customer_id
self.fields = {}
self.conflicts = {}
def add_field(self, field_name, value, source, timestamp):
"""Track all values from all sources."""
if field_name not in self.fields:
self.fields[field_name] = []
self.fields[field_name].append({
'value': value,
'source': source,
'timestamp': timestamp
})
def get_field(self, field_name):
"""Return most recent value, but expose conflicts."""
values = self.fields.get(field_name, [])
if not values:
return None
# Sort by timestamp, most recent first
sorted_values = sorted(values, key=lambda x: x['timestamp'], reverse=True)
# Check if multiple recent values exist
most_recent = sorted_values[0]
recent_window = most_recent['timestamp'] - 3600 # 1 hour window
recent_values = [
v for v in sorted_values
if v['timestamp'] >= recent_window
]
if len(recent_values) > 1:
unique_values = set(v['value'] for v in recent_values)
if len(unique_values) > 1:
self.conflicts[field_name] = recent_values
return most_recent['value']This exposes when the merge logic is making arbitrary choices between equally valid recent values. Applications can handle conflicts explicitly rather than receiving silently chosen data.
The Limits of Master Data Management
Master data management strategy fails when it assumes perfect synchronization is achievable. Systems designed for perfect synchronization break under partial synchronization.
Real MDM deployments have source systems that refuse to sync, golden records that diverge, and merge logic that cannot handle the conflict patterns that actually occur.
Effective strategies acknowledge this. They optimize for visibility into divergence, graceful degradation when sync fails, and explicit handling of merge conflicts.
This does not mean abandoning the golden record concept. It means building systems that continue functioning when the golden record is stale, incomplete, or wrong, which happens constantly in production.
The goal is not perfect consistency. The goal is knowing when consistency breaks and having systems that tolerate it.
There Is More Than One MDM Architecture
Master data management is often discussed as though every implementation follows the same model.
It doesn’t.
Industry guidance commonly distinguishes four broad implementation styles:
- registry
- consolidation
- coexistence
- centralized
Each places authority in a different part of the architecture.
That means each fails differently.
See: IBM’s overview of MDM implementation styles and Informatica’s MDM integration architecture guide.
Registry
A registry does not usually replace the records held in source systems.
It creates a central index that identifies which records refer to the same customer, supplier, product or organisation. The source systems continue to own their data, while the registry stores identifiers, cross-references and enough information to resolve identity.
This reduces the pressure to synchronize every attribute into a central hub.
It also means the registry can tell you that several records represent the same entity without necessarily telling you which record is correct.
The failure mode is ambiguity.
The organisation gains a shared identity but not always a shared version of the truth.
Consolidation
A consolidation model copies master data from source systems into a central repository.
The consolidated record is commonly used for reporting, analytics, compliance or customer views, while operational updates continue to happen in the original systems.
This is less disruptive because source applications don’t have to surrender control.
The failure mode is latency.
The central view is authoritative for analysis but may already be stale when an operational system makes its next decision.
Coexistence
A coexistence model allows both the MDM hub and source systems to update master data.
Changes move in both directions.
This is attractive during long migrations because applications can adopt the MDM platform gradually rather than being replaced at once. It is also where ownership becomes difficult to explain.
If the CRM changes an address and the MDM hub changes it again before synchronization completes, both systems have behaved as authorities.
The failure mode is competing ownership.
Coexistence can preserve operational flexibility, but it requires precise rules about which system controls each attribute and what happens when those rules conflict.
Centralized
A centralized model makes the MDM platform the system where master data is created and maintained.
Applications consume that data rather than managing independent versions themselves.
This produces the clearest authority model.
It also creates the strongest dependency.
If the MDM platform becomes unavailable, too slow or too rigid for a domain’s requirements, teams start creating local workarounds. Once that happens, the centralized model gradually becomes coexistence without admitting it.
The failure mode is organisational resistance.
The architecture can centralize data.
It cannot force every team to accept the same operational model.
Identity Resolution Is More Than Precedence
Precedence rules answer one question:
Which source wins?
Identity resolution has to answer an earlier and more difficult one:
Do these records describe the same entity at all?
Deterministic matching works when reliable identifiers exist. Two records with the same verified customer number, tax identifier or product code can often be linked with high confidence.
Real enterprise data is rarely that clean.
Names change.
Addresses are reformatted.
Phone numbers are shared.
Identifiers are missing.
Fields contain typographical errors.
Modern MDM platforms therefore combine several approaches. IBM, for example, documents deterministic, probabilistic and rule-based matching as configurable options rather than treating matching as a single comparison rule.
Probabilistic matching assigns weight to evidence.
A matching date of birth may be useful.
A matching surname may be useful.
A matching surname, date of birth, phone number and postal address together provide much stronger evidence that two records represent the same person.
The result is usually a confidence score rather than a simple true-or-false answer.
High-confidence matches can be merged automatically.
Low-confidence matches can remain separate.
The difficult cases sit between them.
Those are the records that require review.
Survivorship Is a Separate Decision
Matching determines which records belong together.
Survivorship determines which values remain after they are grouped.
The newest value isn’t always the most accurate.
The most frequently occurring value may simply be the oldest value copied across the most systems.
The system with the highest general precedence may not be authoritative for every field.
A CRM might own a customer’s preferred name.
Billing might own the verified billing address.
An identity platform might own the legal name.
A customer portal might hold the most recent phone number.
Survivorship rules can combine source authority, recency, validation results and confidence scores. Oracle documents configurable survivorship rules for selecting master records, while Informatica describes trust and survivorship scoring rather than relying on one winning source for the entire entity.
This produces a more defensible golden record.
It does not make the answer objective.
The result is still based on rules the organisation chose.
Some Conflicts Require Data Stewards
MDM programmes often begin with the assumption that better matching rules will eventually automate every merge.
They won’t.
Some records are difficult because the data is incomplete.
Others are difficult because the business itself is ambiguous.
Two companies may have merged legally while continuing to trade under separate names.
A supplier may operate through several subsidiaries but use one payment account.
A customer may deliberately maintain separate personal and business identities.
Two products may look identical but have different regulatory classifications.
No matching algorithm can resolve those questions from similarity scores alone.
Someone has to understand what the records mean.
That is the role of data stewardship.
DAMA-DMBOK treats data management as a combination of governance, defined responsibilities and operational practices rather than a software deployment alone. MDM sits within that wider framework of data quality, metadata, integration and governance.
A practical stewardship workflow might look like this:
- The MDM system detects a possible duplicate or attribute conflict.
- Deterministic rules resolve high-confidence cases automatically.
- Ambiguous cases are assigned a confidence score.
- Cases below the automatic-merge threshold enter a review queue.
- A steward compares the records, source evidence and business context.
- The decision, reasoning and affected identifiers are recorded in an audit trail.
- The matching or survivorship rules are reviewed if the same conflict appears repeatedly.
The steward is not there to manually repair everything the technology failed to solve.
The steward exists because some decisions are semantic rather than statistical.
Effective governance also defines who is allowed to make those decisions.
A customer data steward may resolve identity conflicts.
A finance owner may decide which tax record is authoritative.
A product team may control product classification.
The MDM platform can route the disagreement.
Governance determines who has the authority to resolve it.
IBM describes stewardship tooling, audit trails and assisted match decisions as part of its MDM offering, while Informatica recommends using data-quality scores to prioritize low-confidence records for manual review.
Event-Driven MDM Reduces Delay, Not Divergence
Scheduled synchronization makes divergence predictable.
If updates run every hour, the golden record can be almost an hour behind.
Event-driven synchronization reduces that window by publishing changes when they occur rather than waiting for the next batch.
A customer updates their address.
The CRM publishes an event.
The MDM platform receives it, applies matching and survivorship rules, then publishes the resulting change to interested systems.
The delay may fall from hours to seconds.
That is an improvement.
It is not the same as immediate consistency.
Events can arrive late, and sequence numbers carry meaning when consumers need to reconstruct order.
They can arrive out of order.
They can be delivered more than once.
Consumers can be unavailable.
A source transaction may commit while publication of its event fails.
An event-driven design therefore needs more than a message broker.
It needs durable event publication, idempotent consumers, ordering rules where sequence matters, and reconciliation for events that never reach their destination.
The Transactional Outbox pattern is one common way to reduce the gap between updating a source record and publishing the corresponding event. The application writes the business change and an outbox entry in the same local transaction. A separate publisher then sends the event to the broker. Consumers still need to handle duplicate delivery safely.
Even with those controls, source systems and the MDM hub can temporarily disagree.
Event-driven MDM reduces the duration of divergence.
It doesn’t eliminate the conditions that create it.
┌──────────────────┐
│ Source System │
│──────────────────│
│ Update Customer │
│ Write Outbox Row │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Event Publisher │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Message Broker │
└────────┬─────────┘
│
▼
┌──────────────────────────┐
│ MDM Hub │
│──────────────────────────│
│ Match │
│ Apply Survivorship Rules │
│ Record Conflicts │
│ Publish Mastered Change │
└────────┬─────────────────┘
│
▼
┌──────────────────────────┐
│ Downstream Applications │
└──────────────────────────┘The architecture moves changes faster.
It still requires a plan for delayed, duplicated, rejected and conflicting updates.
Where the Global Model Should Stop
A golden record becomes harder to maintain when it tries to represent every meaning an entity has across the organisation.
The word customer is a useful example.
To sales, a customer may be a prospect or account.
To billing, a customer is an entity responsible for payment.
To support, a customer is someone entitled to assistance.
To compliance, a customer may be a legally verified person or organisation.
Those models overlap.
They are not identical.
Domain-Driven Design addresses this problem through bounded contexts. A bounded context defines the boundary within which a particular model and vocabulary remain valid. Large organisations can therefore use several related models without pretending that one universal representation works everywhere.
This changes the role of MDM.
The MDM platform does not have to own every field used by every domain.
It can own shared identity, cross-domain identifiers and the small set of attributes that genuinely require enterprise agreement.
Domains retain authority over the information that only has meaning inside their own boundaries.
For example:
| Data | Likely authority |
|---|---|
| Enterprise customer identifier | MDM |
| Legal entity name | Identity or compliance domain |
| Billing status | Finance domain |
| Support entitlement | Support domain |
| Marketing preferences | Marketing or consent domain |
| Current shopping basket | Commerce domain |
This is not abandoning the golden record.
It is limiting the golden record to data that can realistically have one enterprise-wide meaning.
The integration between domains must then become explicit, because execution often fails at interfaces. Context maps, APIs, events and translation layers define how one model is interpreted by another.
This is usually more work than forcing every system into one canonical schema.
It is also more honest.
The organisation already has multiple meanings for the same entity.
A bounded-context approach makes those differences visible instead of burying them inside an ever-growing MDM model.
Governance Is the Missing Architecture
DAMA-DMBOK describes data management as a collection of connected disciplines, including governance, architecture, quality, metadata, integration and reference and master data management. That framing matters because MDM cannot succeed as an isolated technical platform.
The technology can:
- identify possible duplicates
- calculate confidence scores
- apply survivorship rules
- preserve lineage
- distribute mastered records
- route conflicts for review
It cannot decide:
- what
customermeans in every domain - which team owns a disputed attribute
- whether two legal entities should be merged
- how much matching risk the business will accept
- when a local domain rule should override an enterprise standard
Those are governance decisions.
Gartner’s historical descriptions of MDM hubs similarly treated registry, consolidation, coexistence and transaction-oriented approaches as different ways of supporting different use cases rather than one universal deployment model.
The MDM architecture should therefore document more than data flows.
It should document authority.
For each mastered field, the organisation should be able to answer:
- Which domain defines its meaning?
- Which system is allowed to create it?
- Which systems may update it?
- Which validation rules apply?
- Which source wins during ordinary conflicts?
- Which conflicts require human review?
- Who has authority to make the final decision?
- How is that decision audited and propagated?
Without those answers, the golden record is governed by whichever integration ran last.
A More Realistic Master Data Management Strategy
A production MDM strategy should assume that:
- different implementation styles have different failure modes
- identity resolution produces uncertainty rather than certainty
- survivorship rules encode business policy
- some conflicts require human judgment
- event-driven synchronization reduces latency but preserves distributed-systems failure modes
- domains need local authority over context-specific data
- governance determines ownership when technology cannot
The goal is not to build one data model powerful enough to replace every source system.
The goal is to create a reliable mechanism for identifying shared entities, establishing authority where enterprise agreement is necessary and resolving disagreement when it occurs.
A golden record does not eliminate competing versions of the truth.
It gives the organisation a governed place to understand and resolve them.
