One entity, multiple systems — that’s the reality of every large enterprise.
Customer #12345 exists in CRM, again in ERP, again in Billing. The immediate instinct is to fix it. One source of truth, says the playbook. Master Data Management will unify everything.
I’m questioning that premise.
Not because I’ve watched Master Data Management projects fail — although I have, repeatedly — but because I’ve watched them stall before they ever began. Teams spend months defining the business value, mapping attributes across systems, debating ownership and governance, and designing the theoretical “golden record.” Then nothing ships.
Maybe the problem isn’t execution. Maybe the premise itself is wrong — especially for enterprises that already have functioning systems.
Why One Entity Lives in Many Systems
This isn’t duplication. It’s not “the same data copied everywhere,” and it’s not a quality issue waiting to be resolved. It’s specialisation.
Different systems hold different slices of the same reality because they serve different operational purposes. CRM manages customer relationships and sales opportunities. ERP manages financial transactions. Billing manages invoices and payments. Each needs different data, different workflows, and different operational contexts.
CRM is designed for sales performance, ERP for financial integrity, Billing for payment processing. They overlap because the real world overlaps — but that overlap isn’t an error. It’s a feature of focus.
The Golden Record Promise
Traditional Master Data Management promises to fix this through consolidation.
Create a single master record — the Golden Record — that every system references. One authoritative version of the truth. One comprehensive customer profile.
The promise is seductive: instead of scattered customer data, a single authoritative source. Instead of synchronisation problems, guaranteed consistency. Systems point to one shared entity, and inconsistency disappears.
In practice, it rarely works that way.
To make it happen, every existing system has to stop using its own customer table and start using the new master table. CRM must change every query, workflow, and integration point. ERP must do the same. Billing too. What sounds like a simple reference change is actually a fundamental rewrite of each system’s data model — while those systems are still running live business operations.
The design phase can last months. The migration phase is often never completed. The risk is too high, the disruption too great, and the promised benefit too abstract to justify the upheaval.
Maybe the problem isn’t that teams can’t execute MDM. Maybe the Golden Record itself — the idea of collapsing specialisation into one master object — is the wrong architecture for brownfield systems.
Relationship Structures as Master Data
The Three-Layer Architecture framework reveals a different approach: the mappings between systems are relationship structures — the third type of Master Data from Post 13. Not a workaround or an integration patch, but the structural layer that connects specialised systems into a coherent whole.
In most enterprises, CRM holds Customer #12345 in Salesforce for sales operations, ERP holds the same entity as #98765 in SAP for financial management, and Billing keeps its own version, #45678, for invoicing. Support and Order Management have theirs as well. Each record represents the same organisation — Acme Corporation — but in a different operational context.
Each system maintains its own Master Record, containing only the intrinsic properties it truly needs to function. CRM tracks legal name, tax ID, registration date, and primary contact. ERP maintains the corporate identifiers required for accounting and compliance. Billing stores delivery and invoice preferences. Nothing duplicated, nothing redundant, nothing derived — each record remains minimal by design.
The connective tissue is the relationship structure itself:
Real-world entity: Acme Corporation├── CRM: CRM-12345├── ERP: ERP-98765├── Billing: BILL-45678├── Support: SUP-11223└── Order Management: OM-99887These mappings — the explicit relationships that say these identifiers all refer to the same entity — are relationship structures, the third Master Data type. Governed and versioned like classification structures and operating standards, but connecting entities instead of organizing them.
Most organisations treat this mapping data as a nuisance: integration scaffolding to be replaced once the mythical Golden Record arrives. That view misses the point. Cross-system mappings are not a symptom of fragmentation; they are a reflection of system specialisation.
They express how reality looks inside a mature enterprise — multiple domains, each optimised for its own purpose, connected through governed relationships rather than collapsed into a single model. When recognised as Master Data, these relationship structures stop being transient and start being architectural assets.
Architecture, Tools, Operations
The responsibility for relationship structure data divides cleanly across three functions.
Architecture defines what must be mapped: customer identifiers between CRM and ERP, party-to-location relationships, or product mappings across order management and billing.
Development provides the tools — small, focused applications that maintain these relationship structures with standard interfaces and full version history.
Operations owns the ongoing data maintenance, ensuring that when a new customer appears in ERP or a system is replaced, the relationships are updated and versioned correctly.
This is Master Data as designed structure, not as a centralised database. The emphasis shifts from consolidation to composition — from trying to eliminate boundaries to managing them transparently.
A customer-to-system mapping tool does one thing. A party-to-location mapping tool does another. Product taxonomies, sales hierarchies, regulatory codes — each lives in its own governed module. When cross-system reporting is required, the join happens dynamically. Data remains in its native systems; the relationship structures tell the query where to go. The result is coherent, without the cost and fragility of continuous synchronisation.
When someone asks, “Show me all support tickets for customers with revenue greater than £1 million,” no single Golden Record is queried. The system composes the answer. CRM identifies strategic customers. Relationship structure data locates their equivalents in the Support system. Revenue is calculated from transactions. The join occurs at query time — clean, auditable, current. Nothing is duplicated, and no nightly batch tries to keep everything in sync. Truth emerges from structure, not consolidation.
Governance Requirements
For this model to work, relationship structure data must be treated with the same discipline as any other Master Data.
Ownership sits with enterprise data governance, not individual system teams. Every relationship carries an effective date and version history. Historical states remain queryable, so reporting always aligns with the truth at that point in time.
System teams remain accountable for the accuracy of their own Master Records. Governance is accountable for the accuracy and integrity of the relationship structures that connect them. That separation keeps systems autonomous while preserving enterprise traceability.
If relationship structures are governed Master Data, integration should stop being a migration exercise. Adding a new system becomes a matter of adding relationship structure data. Replacing an existing platform means updating relationships, not rebuilding the enterprise. Even mergers become manageable: relationship alignment replaces wholesale consolidation. Truth becomes temporal and relational, not monolithic. Architecture enables composition rather than control. Systems stay focused. Data stays coherent. And the Golden Record quietly becomes unnecessary.
Connection to the Three-Layer Pattern
This entire model fits naturally within the Three-Layer Architecture Pattern — the framework that separates Transactions, Master Records, and Master Data.
Transactions are immutable events — sales, invoices, payments — always tied to specific system identifiers. Master Records define the entities themselves, with time-stamped properties that evolve over time. Master Data contains the mutable structures — classifications, operating standards, and relationship structures — that give those entities context and connect them across systems.
When all three layers work together, truth becomes traceable through time.
To understand what was true at any given point, you only need three coordinates:
Transaction date+ Master Record effective date+ Master Data structure version= Truth at Time TThis formula replaces the brittle idea of a single, universal “source of truth” with a verifiable chain of evidence.
Each layer evolves independently but remains auditable through versioning.
You can change a classification, replace a system, or restructure an organisation without rewriting history or replatforming your data.
That’s the architectural breakthrough the framework reveals: separating how the business operates from how its truth is constructed.
The Three-Layer Architecture framework reveals relationship structures as the missing governance layer. Not a workaround for MDM. Not a stepping stone to Golden Records. The actual architectural pattern for brownfield enterprises.
What This Should Enable
The framework suggests that once relationship structures are recognised as Master Data, architectural options should expand dramatically.
Cross-system reporting no longer requires consolidation projects. You define the relationship structure requirements, build or configure mapping tools, and maintain the data. Query-time joins handle composition dynamically. Adding a new system no longer means rebuilding interfaces or forcing migrations — you simply extend the relationship structures.
Replacing a legacy platform becomes incremental rather than catastrophic. You update relationship structures, maintain historical versions, and preserve continuity. Mergers or acquisitions stop being years-long data integration nightmares; instead, you link ecosystems through governed relationships. Both organisations keep operating on their existing systems while shared reporting emerges through mapped relationships.
This is the pragmatic architecture the Three-Layer framework proposes for enterprises that already run on specialised systems and can’t afford the risk or downtime of a full rebuild. It turns “integration” from a transformation programme into a living structure of governed relationships.
The difference is profound.
Traditional Master Data Management tries to fix inconsistency through consolidation — a data operation that requires every system to change.
This approach resolves inconsistency through design — an architectural separation that allows systems to remain independent while still aligning at the point of truth.
It’s not a smaller version of MDM. It’s a different pattern entirely.
One where data remains where it belongs, and relationships — not records — form the backbone of enterprise coherence.
This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/
Leave a Reply