MDM Implementation Patterns: Registry vs Consolidation vs Coexistence vs Centralized

TL;DR

• Bottom line: Four MDM styles exist — Registry (read-only cross-reference), Consolidation (golden record for analytics), Coexistence (bidirectional sync), and Centralized (hub as sole system of record). Most enterprises start with Consolidation and evolve to Coexistence as governance matures.
• Key limit: Consolidation hubs have 4-24h refresh latency and cannot serve real-time operational lookups; Coexistence requires conflict resolution logic before go-live or race conditions corrupt golden records.
• Watch out for: Treating MDM as a one-time ETL project instead of an ongoing governance program — Gartner projected 75% of MDM programs fail when governance is absent.
• Best for: Multi-ERP landscapes (2+ ERPs from M&A or organic growth) where customer, vendor, product, or chart-of-accounts data is fragmented across systems.
• Decision shortcut: Federated org with autonomous BUs? Start with Registry or Consolidation. Centralized org with uniform processes? Go straight to Coexistence or Centralized.

System Profile

This card compares MDM architecture patterns — not specific platform implementations. The patterns are vendor-agnostic, but implementation choices are shaped by which MDM platform you select. SAP MDG is tightly coupled to the SAP ecosystem and acts as a centralized/coexistence hub natively within S/4HANA. Informatica and Reltio are vendor-neutral hubs. Profisee offers the fastest deployment for Microsoft-centric shops. Stibo STEP is strongest for product data (PIM + MDM combined). [src1, src2]

API Surfaces & Capabilities

MDM platforms expose APIs for three purposes: data ingestion, golden record retrieval, and match/merge operations. The pattern you choose determines which APIs are critical. [src3]

Rate Limits & Quotas

Platform API Limits

Match/Merge Processing Limits

Authentication

Authentication Gotchas

• SAP MDG API access requires a Communication Arrangement in BTP — the OData endpoint is not exposed without explicit configuration. [src7]
• Informatica SIF uses a separate auth mechanism from the IDMC REST API — REST API tokens do not work for SIF calls. [src3]
• Reltio tokens are tenant-scoped — multi-tenant deployments need separate OAuth clients per tenant. [src4]

Constraints

• Registry does NOT write back: It provides a cross-reference index only. Any recommendation to "use registry to improve source system data quality" is incorrect.
• Consolidation is not real-time: Typical 4-24h refresh cycles. Cannot serve real-time operational lookups.
• Coexistence requires conflict resolution before go-live: Without predefined rules for concurrent updates, race conditions corrupt golden records.
• Centralized MDM blocks self-service: All master data creation must go through the hub. Existing direct-create workflows in ERPs must be re-engineered.
• SAP MDG is SAP-coupled: Non-SAP data sources require middleware (SAP CPI, MuleSoft, Boomi). SAP MDG cannot natively consume REST APIs from non-SAP systems.
• Match key design is irreversible in production: Changing match keys on a hub with millions of records triggers a full rematch, potentially unmerging existing golden records.
• Survivorship per-attribute, not per-record: Record-level survivorship discards correct attribute values from non-winning sources. Always define survivorship rules per individual attribute.

Integration Pattern Decision Tree

START — Organization needs cross-ERP master data consistency
├── How many ERP systems?
│   ├── 1 ERP + satellite apps
│   │   ├── Data governance within single ERP? → Use native MDG (SAP MDG, Oracle DRM)
│   │   └── Need 360-degree view for analytics? → CONSOLIDATION (lowest cost)
│   └── 2+ ERPs (multi-vendor or M&A)
│       ├── Organizational structure?
│       │   ├── FEDERATED (autonomous BUs, own ERPs, own processes)
│       │   │   ├── Need cross-BU reporting only? → REGISTRY
│       │   │   ├── Need harmonized analytics? → CONSOLIDATION
│       │   │   └── Need operational data consistency? → COEXISTENCE
│       │   ├── CENTRALIZED (single IT, uniform processes)
│       │   │   ├── Greenfield / ERP consolidation? → CENTRALIZED
│       │   │   └── Brownfield / phased harmonization? → COEXISTENCE
│       │   └── HYBRID (central standards, local execution)
│       │       └── → COEXISTENCE (most common choice)
│       └── Data governance maturity?
│           ├── LOW → Start with CONSOLIDATION, evolve to COEXISTENCE (12-18 months)
│           ├── MEDIUM → COEXISTENCE
│           └── HIGH → CENTRALIZED or COEXISTENCE
├── Data domains?
│   ├── Customer/Account → Highest ROI domain — start here
│   ├── Vendor/Supplier → Second priority — compliance benefits
│   ├── Product/Material → Consider PIM + MDM (Stibo STEP, Informatica PIM)
│   ├── Chart of Accounts → Financial consolidation — often SAP MDG or Oracle DRM
│   └── Employee → HR systems often already centralized
└── Budget and timeline?
    ├── < $500K, < 6 months → Registry or Consolidation
    ├── $500K-$2M, 6-12 months → Coexistence (single domain)
    └── > $2M, 12-24 months → Centralized or multi-domain Coexistence

Quick Reference

Step-by-Step Integration Guide

1. Assess current state and define data domains

Map all master data domains (customer, vendor, product, chart of accounts, employee) across every ERP and satellite system. Document who creates each entity, how often, and what the authoritative source is today. [src5, src6]

Domain Assessment Template:
+-----------------+---------------+--------------+-------------+----------------+
| Data Domain     | Systems       | Record Count | Create Rate | Current Source  |
|                 |               |              | (per month) | of Truth       |
+-----------------+---------------+--------------+-------------+----------------+
| Customer        | SF, SAP, NS   | 2.3M total   | 5K          | Salesforce     |
| Vendor/Supplier | SAP, Oracle   | 180K total   | 200         | SAP            |
| Product         | SAP, PIM, WMS | 500K total   | 1K          | SAP MM         |
| Chart of Acct   | SAP, Oracle   | 12K total    | 50          | SAP FI         |
| Employee        | Workday, SAP  | 45K total    | 300         | Workday        |
+-----------------+---------------+--------------+-------------+----------------+

Verify: Count total unique entities across systems — if cross-system overlap > 30%, MDM ROI is likely positive.

2. Select MDM pattern using the decision tree

Use the decision tree above. Key factors: org structure (federated vs centralized), number of ERPs, data governance maturity, and budget/timeline. [src1, src2]

Verify: Confirm pattern selection with stakeholders before proceeding to platform selection.

3. Define match rules and survivorship strategy

Design match keys per data domain. Match keys determine which records are candidates for merging. Survivorship rules determine which attribute value wins when merging. [src3]

Survivorship Rules (per attribute):
+---------------+----------------------+-------------------------------+
| Attribute     | Survivorship Rule    | Rationale                     |
+---------------+----------------------+-------------------------------+
| Legal Name    | Most trusted source  | ERP > CRM (ERP has contracts) |
| Email         | Most recent          | Email addresses change often  |
| Phone         | Most complete        | Pick non-null, longest value  |
| Address       | Most trusted source  | ERP for billing, CRM for ship |
| Tax ID        | Most trusted source  | ERP (validated at PO creation)|
| Credit Limit  | Highest authority    | Finance system always wins    |
| Industry      | Most recent          | CRM updated by sales reps    |
+---------------+----------------------+-------------------------------+

Verify: Test match rules against a sample of 10K records — false positive rate < 2%, false negative rate < 5%.

4. Configure data flow and sync patterns

Set up integration pipelines based on selected pattern. For coexistence: implement CDC listeners on source ERPs, conflict detection in the hub, and writeback channels. [src3]

# Coexistence pattern: conflict detection pseudocode
def resolve_conflict(incoming_change, golden_record, survivorship_rules):
    conflicts = []
    for attr in incoming_change.changed_attributes:
        golden_val = getattr(golden_record, attr)
        incoming_val = getattr(incoming_change, attr)
        if golden_val != incoming_val:
            rule = survivorship_rules.get(attr)
            if rule.type == "most_trusted_source":
                winner = rule.evaluate_trust(
                    golden_record.source, incoming_change.source)
            elif rule.type == "most_recent":
                winner = max(golden_record, incoming_change,
                           key=lambda r: r.last_modified)
            else:
                conflicts.append({"attribute": attr,
                    "golden_value": golden_val,
                    "incoming_value": incoming_val})
                continue
            if winner == incoming_change:
                setattr(golden_record, attr, incoming_val)
    if conflicts:
        create_steward_task(golden_record.id, conflicts)
    return golden_record

Verify: Run conflict resolution against historical change log — unresolved conflicts < 10% of total changes.

Code Examples

Python: Informatica MDM REST API — Search and Match

# Input:  Customer record attributes (name, address, tax_id)
# Output: Matched golden record ID and confidence score

import requests

INFORMATICA_BASE = "https://your-org.informatica.com/mdm/api/v2"
TOKEN = "Bearer <your_oauth_token>"

def search_and_match(customer_data):
    headers = {"Authorization": TOKEN, "Content-Type": "application/json"}
    search_payload = {
        "searchType": "MATCH",
        "recordData": {
            "companyName": customer_data["name"],
            "postalCode": customer_data["postal_code"],
            "country": customer_data["country"]
        },
        "matchRuleSet": "CustomerMatchRules",
        "maxResults": 10
    }
    resp = requests.post(f"{INFORMATICA_BASE}/match/Customer",
                        json=search_payload, headers=headers, timeout=30)
    resp.raise_for_status()
    matches = resp.json().get("matchedRecords", [])
    if not matches:
        return {"status": "no_match", "action": "create_new_golden_record"}
    best = max(matches, key=lambda m: m["matchScore"])
    if best["matchScore"] >= 95:
        return {"status": "auto_merge", "golden_record_id": best["recordId"],
                "confidence": best["matchScore"]}
    elif best["matchScore"] >= 70:
        return {"status": "steward_review", "golden_record_id": best["recordId"],
                "confidence": best["matchScore"]}
    return {"status": "no_match", "action": "create_new_golden_record"}

cURL: SAP MDG — Read Master Data via OData

# Input:  SAP MDG OData endpoint, OAuth token, business partner ID
# Output: Master data record in JSON format

# Step 1: Get OAuth token from SAP BTP
curl -X POST "https://your-btp.authentication.eu10.hana.ondemand.com/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_SECRET"

# Step 2: Read Business Partner master data from MDG
curl -X GET "https://your-s4hana.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000042')" \
  -H "Authorization: Bearer <token>" \
  -H "Accept: application/json" \
  -H "sap-client: 100"

Data Mapping

Master Data Domain Mapping Across ERPs

Data Type Gotchas

• Name fields: SAP stores names in structured fields (NAME1-NAME4, max 35 chars each); Salesforce uses Name (max 255 chars, single field). MDM merge must concatenate or truncate carefully. [src3]
• Currency representation: SAP stores amounts in smallest currency unit (cents); Oracle stores as decimal. MDM survivorship rules must normalize before comparison. [src3]
• Date/time zones: SAP stores in user timezone; Salesforce in UTC; NetSuite in company timezone; Oracle in UTC. Cross-system timestamp comparison without timezone normalization leads to incorrect "most recent" survivorship. [src3]
• Tax ID format: Varies by country (US: EIN 9 digits, DE: USt-IdNr 11 chars, UK: VAT 9-12 digits). MDM must normalize format before match key generation. [src3]

Error Handling & Failure Points

Common Error Scenarios

Failure Points in Production

• Initial data load overwhelms match engine: Loading millions of records triggers quadratic match comparison. Fix: Use blocking keys to partition match scope. Load in 50K batches. [src3]
• Survivorship produces "Frankenstein records": Different attributes survive from different sources, creating records that never existed in any source. Fix: Add cross-attribute consistency rules (if country from Source A, city/postal must also come from Source A). [src3]
• CDC lag causes stale golden records: Source ERP commits change, but CDC event is delayed, causing stale data. Fix: Use streaming CDC (Debezium, Oracle GoldenGate, SAP SLT) instead of polling. Set max lag SLA and alert on breach. [src3]
• Match key change triggers mass unmerge: Modifying match rules on production hub splits existing golden records. Fix: Never change match keys without parallel run. Compare results against snapshot before cutover. [src3]

Anti-Patterns

Wrong: Treating MDM as an ETL project

// BAD — "We'll just deduplicate with an ETL job"
1. Extract customer data from 3 ERPs nightly
2. Run SQL DISTINCT on name + address
3. Load "deduplicated" records into data warehouse
4. Declare "MDM done"

Problems:
- No match/merge engine — misses fuzzy duplicates
- No survivorship rules — arbitrary record wins
- No writeback — source ERPs still create duplicates daily
- No governance — data quality degrades immediately

Correct: Implement proper MDM with match engine and governance

// GOOD — proper MDM implementation
1. Define match rules: deterministic (Tax ID) + fuzzy (name similarity > 0.85)
2. Define survivorship: per-attribute rules based on source trust ranking
3. Load into MDM hub with match/merge engine
4. Auto-merge high-confidence, route ambiguous to stewards
5. Publish golden records with stable cross-reference IDs
6. Continuous CDC: source changes -> hub update -> writeback
7. Governance: stewards review exceptions, refine rules quarterly

Wrong: Ignoring data stewardship ("fully automated MDM")

// BAD — "AI will handle all matching, no stewards needed"
1. Deploy MDM with default match rules
2. Set auto-merge threshold to 60% confidence
3. No steward queue, no exception handling

Problems:
- 60% threshold causes mass false merges
- Legal entities merged that should remain separate
- Unmerge requests pile up with no one to process them

Correct: Tiered automation with steward escalation

// GOOD — tiered approach
1. Auto-merge: confidence >= 95% (exact Tax ID match)
2. Auto-merge with notification: 85-94% (steward can review retroactively)
3. Manual steward review: 70-84% (approve/reject within SLA)
4. No match: < 70% (separate records)
5. Weekly spot-check of auto-merged records
6. Quarterly match rule tuning based on false positive/negative rates

Wrong: Boiling the ocean — all domains, all systems, day one

// BAD — "Master all data domains across all 7 ERPs simultaneously"
Scope: Customer + Vendor + Product + Employee + CoA across 7 ERPs
Timeline: 6 months, Budget: $800K
Result: 18 months later, $3M spent, 2 domains partially live,
  project sponsor replaced, organizational trust in MDM destroyed

Correct: Start small, prove value, expand

// GOOD — phased domain rollout
Phase 1 (months 1-4): Customer domain, 2 highest-volume ERPs ($300K)
Phase 2 (months 5-8): Add vendor domain, same 2 ERPs
Phase 3 (months 9-14): Expand to remaining ERPs
Phase 4 (months 15-20): Add product domain
Each phase: Measurable ROI before next phase funding approved

Common Pitfalls

• "MDM = technology project": Organizations buy a platform expecting it to solve data quality without governance changes. Fix: Allocate 40% of MDM budget to people and process. Technology is only 30-40% of total cost. [src5, src6]
• No executive sponsor with operational authority: IT-driven MDM projects lack business buy-in. Fix: Secure VP/Director-level sponsor from an operational business unit — not just IT. [src5]
• Mismatched style to org structure: Deploying centralized MDM in a federated organization triggers political resistance. Fix: Use decision tree. Federated orgs must start with consolidation or coexistence — never centralized. [src1, src2]
• Match rules designed without business context: IT creates match keys on obvious fields but misses business rules (e.g., same Tax ID but different divisions should NOT merge). Fix: Involve business data owners in match rule design. Test with business users validating merge candidates. [src5]
• Ignoring the "Day 2" problem: MDM goes live with clean data, but no process prevents new duplicates in source systems. Fix: Implement duplicate-prevention at source: real-time duplicate check API called before new record creation. [src3]
• Over-investing in pre-MDM data quality: Spending 12 months cleansing source data before loading delays value. Fix: Load messy data, let match/merge engine handle dedup. Clean iteratively with steward review. [src6]

Diagnostic Commands

# Check golden record duplicate rate (Informatica MDM REST API)
curl -X GET "$INFORMATICA_BASE/mdm/api/v2/statistics/Customer/duplicates" \
  -H "Authorization: Bearer $TOKEN" -H "Accept: application/json"

# Check match queue depth (steward tasks pending)
curl -X GET "$INFORMATICA_BASE/mdm/api/v2/tasks?status=PENDING&type=MERGE_REVIEW" \
  -H "Authorization: Bearer $TOKEN"

# SAP MDG: Check change request status
curl -X GET "$SAP_HOST/sap/opu/odata/sap/API_MASTERDATA_GOVERNANCE_SRV/ChangeRequests?\$filter=Status eq '01'" \
  -H "Authorization: Bearer $SAP_TOKEN" -H "Accept: application/json"

# Reltio: Check entity resolution statistics
curl -X GET "https://your-tenant.reltio.com/reltio/api/entities/_stats" \
  -H "Authorization: Bearer $RELTIO_TOKEN"

# Check CDC replication lag (Debezium / Kafka Connect)
curl -X GET "http://kafka-connect:8083/connectors/erp-cdc/status" | jq '.tasks[0].state'

Version History & Compatibility

When to Use / When Not to Use

Cross-System Comparison

Important Caveats

• MDM platform pricing varies dramatically by edition, domain count, and record volume — cost ranges in this card are rough estimates. Always request vendor-specific pricing.
• Gartner projected that 75% of MDM programs fail to meet business objectives — the primary cause is lack of governance, not technology failure. Budget for people and process, not just software.
• SAP MDG Cloud Edition on BTP is relatively new (2025) and has feature parity gaps with the on-premise version. Verify capabilities against current SAP MDG feature scope document.
• Reltio's SaaS-only deployment model means no on-premise option. Organizations with strict data residency requirements should verify regional availability.
• The "right" MDM style often evolves — most enterprises start with Consolidation and migrate to Coexistence within 12-24 months. Plan for style evolution in your architecture.
• Match quality depends more on data preparation than platform choice. A $200K Profisee deployment with well-designed match keys will outperform a $2M Informatica deployment with poor match keys.