Tag: Enterprise Architecture

One customer, seven locations. Management wants to restructure territories. How long will it take?

If your architecture requires updating every location record, you’ve embedded structures in entities. If it versions a single structure, you’ve separated them correctly.

Let’s test the Three-Layer framework under increasing complexity.

Scenario 1: Basic Party-to-Location

Acme Corporation has seven ship-to locations: Warsaw plant, Krakow distribution center, Berlin office, Prague warehouse, Budapest facility, Vienna office, London headquarters.

The temptation: Store locations as properties on the customer record. Seven address fields. Or create a locations table with customer ID stamped on each row.

The problem: When Acme opens an eighth facility, what changes? When they close Prague warehouse, what updates? Every change touches either the party record or requires updating stamped location records.

Framework approach:

Acme Corporation = Master Record. Minimal intrinsic properties: legal name, tax ID, registration date, entity type. No locations embedded.

Each location = Master Record. Warsaw plant, Krakow distribution, Berlin office — each is an entity with its own minimal properties: address, delivery hours, loading dock capacity, operational status.

Party-to-location assignments = Master Data. Relationship structure connecting party to locations:

Acme Corporation (Party)├── Warsaw plant├── Krakow distribution├── Berlin office├── Prague warehouse├── Budapest facility├── Vienna office└── London headquarters

This is Master Data from Post 13. Relationship structures. Maintained by operations. Versioned when changes occur.

When Acme opens eighth facility: Create location Master Record for new facility. Add relationship in party-to-location structure. Party Master Record unchanged. Existing location Master Records unchanged. Just relationship structure updated.

When Acme closes Prague warehouse: Update location Master Record status to inactive. Remove relationship in party-to-location structure (or version it with end date). Party Master Record unchanged. Other locations unchanged.

When Acme restructures operations: Reassign locations to different operational roles. Relationship structure versions. Party and location Master Records stay unchanged unless actual properties like delivery hours change.

The separation holds. Changes affect relationship structures. Master Records stay minimal.

Scenario 2: Corporate Hierarchy

Acme Corporation isn’t standalone. It’s a subsidiary of Acme International Holdings, which is owned by Global Industrial Corp.

Three-level corporate hierarchy. How do you trace ownership chains? How do you handle reorganizations?

The temptation: Add parent company ID to party Master Record. Acme record includes “Parent: Acme International Holdings” as property.

The problem: When Global Industrial restructures — sells division, acquires competitor, merges subsidiaries — every party Master Record in the affected hierarchy requires updates. Parent IDs change. Historical reporting breaks unless you’ve time-stamped every ownership change at the party level.

Framework approach:

Each entity = Master Record. Acme Corporation, Acme International Holdings, Global Industrial Corp — all party Master Records with minimal properties. No parent IDs embedded.

Corporate hierarchy = Master Data. Relationship structure defining ownership:

Global Industrial Corp└── Acme International Holdings    └── Acme Corporation        └── (7 ship-to locations from Scenario 1)

This is classification structure Master Data — hierarchical, but mapping relationships between entities. Versioned independently.

When Global Industrial acquires competitor: Add competitor parties as Master Records. Update corporate hierarchy structure to show new ownership relationships. Version the structure. Historical reporting uses historical hierarchy version. Current reporting uses current version. Existing party Master Records unchanged.

When Acme International Holdings is sold: Update corporate hierarchy structure. Acme International (and all subsidiaries) move to new parent. Version the structure with effective date. Historical transactions use historical hierarchy. Current transactions use current hierarchy. Party Master Records unchanged.

The pattern holds. Relationship structures handle hierarchies. Master Records stay minimal. Changes version structures, not entities.

Scenario 3: Network Membership

Acme Corporation is member of European Manufacturing Consortium. The consortium negotiated supplier agreements providing 15% volume discount with preferred vendors.

How do you know Acme gets the discount? How do you apply it to transactions? How do you handle when Acme joins or leaves networks?

The temptation: Add discount percentage to Acme’s Master Record. Or add “Network: EMC” as property with associated discount terms.

The problem: When consortium renegotiates terms — 15% becomes 18% — you update every member party record. When party leaves consortium, you remove discount from their record. Party Master Records become repositories for contractual terms that belong elsewhere.

Framework approach:

European Manufacturing Consortium = Master Record. The network itself is an entity with minimal properties: name, registration details, contract terms. The discount terms (15% volume discount) are intrinsic properties of the consortium entity.

Network membership = Master Data. Relationship structure connecting parties to networks:

European Manufacturing Consortium (Master Record: 15% discount)├── Acme Corporation (member)├── TechMfg Industries (member)├── Alpine Manufacturing (member)└── Nordic Production Group (member)

Parties don’t have discounts stamped on them. Networks have discount terms in their Master Records. Membership connects parties to networks through relationship structures.

How does transaction get the discount?

Transaction ships product to Acme Corporation. Query process:

1. Check party-to-network mapping (Master Data) → Acme is member of EMC
2. Query EMC Master Record → discount terms = 15%
3. Apply discount to transaction pricing

Query-time composition. Not pre-stamped discount on party record.

When consortium renegotiates discount: Update EMC Master Record. 15% becomes 18%. Time-stamp the change. Party Master Records unchanged. Membership structure unchanged. All members automatically get new discount for new transactions. Historical transactions used historical discount percentage from EMC Master Record effective date.

When Acme leaves consortium: Update membership structure. Remove Acme from EMC membership. Version with end date. Party Master Record unchanged. EMC Master Record unchanged. Future transactions query membership, find no match, no discount applies.

The framework holds. Network terms live in network Master Records. Membership is relationship structure. Compose at query time. No party records bloated with contractual terms.

Scenario 4: Territory Restructuring

Management restructures sales territories. Currently organized by country offices. Changing to regional model.

Current structure: Six country offices (Poland, Germany, Czech, Hungary, Austria, UK) each managing their local Acme locations.

New structure: Two regional offices (Western Europe, Eastern Europe) managing consolidated territories.

Six country offices become two regional offices. Territory restructure. This is the Post 11 problem applied to parties.

The embedded approach:

Sales office assignment is a property on location Master Records. Update every affected location:

• Warsaw Master Record: Change “Sales Office: Poland” to “Sales Office: Eastern Europe”
• Prague Master Record: Change “Sales Office: Czech” to “Sales Office: Eastern Europe”
• Berlin Master Record: Change “Sales Office: Germany” to “Sales Office: Western Europe”
• Vienna Master Record: Change “Sales Office: Austria” to “Sales Office: Western Europe”

Every location in Europe requires Master Record update. Historical reporting breaks unless you’ve time-stamped every sales office change at the location level.

This is exactly the problem Post 11 described. Territory restructure requires reprocessing Master Records.

Framework approach:

Location Master Records contain minimal properties: address, delivery hours, operational capacity. No sales office assignment embedded.

Sales territory assignment = Master Data. Classification structure organizing locations by sales responsibility:

Sales Territory Structure v1.0 (through 2025-12-31):├── Poland Sales Office│   ├── Warsaw plant│   └── Krakow distribution├── Germany Sales Office│   └── Berlin office├── Czech Sales Office│   └── Prague warehouse├── Hungary Sales Office│   └── Budapest facility├── Austria Sales Office│   └── Vienna office└── UK Sales Office    └── London headquartersSales Territory Structure v2.0 (from 2026-01-01):├── Western Europe Sales Office│   ├── Berlin office│   ├── Vienna office│   └── London headquarters└── Eastern Europe Sales Office    ├── Warsaw plant    ├── Krakow distribution    ├── Prague warehouse    └── Budapest facility

Sales office assignment is Master Data. It’s a classification structure organizing locations by operational responsibility. Management controls it. Changes when strategy changes.

When management restructures: Create new structure version. Effective date 2026-01-01. New regional model.

What changes: One structure.

What stays stable: All location Master Records, party Master Records, party-to-location relationships, corporate hierarchies, network memberships, transactions.

Historical reporting: “Show me sales performance by office for 2025.”

Query uses Sales Territory Structure v1.0. Warsaw rolls up to Poland office. Berlin rolls up to Germany office. Historical structure preserved.

Current reporting: “Show me sales performance by office for 2026.”

Query uses Sales Territory Structure v2.0. Warsaw rolls up to Eastern Europe office. Berlin rolls up to Western Europe office. Current structure applies.

Trending across change: “Show me Warsaw plant performance 2025 vs 2026 by responsible sales office.”

• 2025: Query with v1.0 structure → Poland office
• 2026: Query with v2.0 structure → Eastern Europe office

Both correct for their time periods. No location Master Records changed. Structure versioned.

This applies the same principle from Post 11 to a different layer. Territory restructures version Master Data structures. Master Records stay unchanged. Transactions stay unchanged. Reporting adapts using version dates.

If you embedded sales office in location Master Records: Three-month project to update every location record. Migration scripts. Data validation. Testing across all systems consuming location data. Reporting breaks if you don’t update historical assignments.

Embedded structures create the restructuring nightmare Post 11 described. Separated structures enable routine strategic changes.

What The Scenarios Reveal

Four scenarios. Increasing complexity. Multiple relationship types. Real-world changes.

The framework holds because:

Master Records stay minimal. Parties, locations, networks, corporate entities — all contain only intrinsic properties. No embedded relationships. No stamped structures.

Relationship structures handle connections. Party-to-location, corporate hierarchy, network membership, territory assignment — each is separate Master Data. Each versions independently. Each governs independently.

Query-time composition assembles views. Reporting joins transactions, Master Records, and relationship structures using dates and versions. No pre-consolidated data. No forced migration.

Changes affect structures, not entities. Open location, update structure. Restructure hierarchy, update structure. Change membership, update structure. Reassign territories, update structure. Master Records unchanged. Transactions unchanged.

What breaks if you embed:

Embed locations in party record: Opening location changes party. Closing location changes party. Every location change touches party Master Record.

Embed hierarchy in party record: Acquisition changes every subsidiary party. Restructuring changes every affected party. Corporate changes cascade through Master Records.

Embed discount in party record: Renegotiate terms, update every member party. Leave network, update party. Join network, update party. Contractual changes require mass party updates.

Embed territory in location record: Restructure territories, update every location. Strategic changes become migration projects.

Embedded structures create cascading changes. Separated structures enable isolated updates.

The pattern is consistent across all four scenarios: separate by authority, version independently, compose at query time. Master Records hold operational authority over entity properties. Master Data holds strategic authority over structures. When structures change, Master Records stay stable.

This isn’t just cleaner data models. It’s architecture that scales with complexity instead of breaking under it. Each new relationship type is a new structure. Each strategic change is a structure version. No migration. No reprocessing. No cascading updates.

The Three-Layer framework separates immutable transactions from mutable structures in Post 11. The Master Data / Master Records separation prevents embedding mutable structures in entity properties. Same principle. Different application. Consistent framework.

Understanding relationship structures as Master Data changes what’s architecturally possible. Not just theory. Strategic flexibility through proper separation.

---

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/

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-99887

These 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 T

This 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/

Last post established the distinction: Master Data = structures, Master Records = entities, Transactions = events. Let’s now deep dive into Master Records and how we could architect them differently.

What Master Records Are

Master Records are specific entities. Individual things that exist in your business.

Customers:

• Customer #12345 (Acme Corporation)
• Customer #67890 (TechCo Inc)

Products:

• Product SKU-789 (Business Laptop Model X)
• Product SKU-456 (Enterprise Server Model Y)

Locations:

• Ship-to Location SL-10001 (Acme Warsaw Plant)
• Ship-to Location SL-10002 (Acme Krakow Plant)

Employees:

• Employee S-456 (Jane Smith, salesperson)
• Employee S-789 (John Chen, account manager)

Each one is a thing. An entity. A specific instance. Not a category. Not a structure. An actual entity with properties and a state. This matters because entities have different architectural requirements than structures.

Master Records Have Properties

Customer #12345 isn’t just an ID. It’s an entity with characteristics:

Customer #12345: Acme Corporation- Legal Name: Acme Corporation Ltd- Tax ID: UK123456789- Registration Date: 2010-03-15- Primary Address: London, UK- Status: Active (i.e. its state)- Contact Email: info@acme.com

These are properties of THIS customer. They describe THIS entity. Not customers in general. This one.

Properties change over time. Address changes when they relocate. Status changes when the relationship changes. That’s why Master Records need time-stamping:

Customer #12345 properties:2020-01-01 to 2023-12-31:- Address: Manchester, UK- Status: Active2024-01-01 onwards:- Address: London, UK- Status: Active

Properties evolve. Time stamps preserve what was true when.

This is different from Master Data versioning. Master Records track property changes. Master Data tracks structural reorganizations.

Master Records You Create

Not all Master Records are discovered in the world. Some you define and create yourself.

Products you specified:

• SKU-789: 16GB RAM, 512GB SSD, Intel i7, 14″ screen
• SKU-456: 64GB RAM, 2TB SSD, Dual Xeon, Rack-mount

Your Locations you designated (or the one you outsourced production to)

• SL-10001: Berlin plant, delivery hours 8am-6pm, loading dock capacity 5 trucks
• SL-10002: Munich plant, 24-hour operations, rail access

You decided these entities exist. You defined their properties. You control when they change.

You create them. You operate with them. You govern their properties.

But you don’t organize them – that’s what Master Data structures do.

The Separation That Changes Everything

Here’s what the Master Data / Master Records distinction actually means in practice:

Master Records = Entities:

• Customer #12345
• Properties: Name, address, tax ID
• Changes: When entity facts change (moved, renamed)
• Governance: Operational (sales ops, customer service)
• Authority pattern: Operational authority over properties

Master Data = Structures organizing entities:

• Territory hierarchy (Strategic Accounts > North Region > Enterprise Sales)
• Classification rules (Revenue > $1M = Strategic Account)
• Changes: When strategy changes (territory reorganization)
• Governance: Strategic (management, architecture)
• Authority pattern: Strategic authority over organization

Customer #12345 is a Master Record. The territory structure that classifies Customer #12345 as “Strategic Account in North Region” is Master Data.

The entity exists independently of how you classify it.

That independence is architectural. You can restructure territories without touching customer records. You can change classification rules without reprocessing entities.

The structures are mutable. The entity facts are what they are.

Why Traditional MDM Fails Here

Traditional MDM conflates these. “Master Data Management” becomes “manage all the important data” without separating entities from their organizing structures.

Result: Territory restructuring requires reprocessing customer records. Taxonomy changes require updating product definitions. Org chart changes require modifying employee records.

Three months to change a classification structure.

Not because the decision is hard. Because you embedded mutable structures (Master Data) in stable entities (Master Records).

The three-layer architecture prevents this:

Transactions reference Master Records by ID. Just the ID.

Master Records contain entity properties. Time-stamped so you know what was true when.

Master Data contains classification structures. Versioned independently so management can restructure without touching operational data.

Reporting joins them at query time. Transaction date + Master Record effective date + Master Data version = correct classification for that point in time.

No reprocessing. No propagation. Query-time assembly.

Master Record Principles

Understanding Master Records as entities leads to specific architectural principles.

These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:

Master Record Principles

Understanding Master Records as entities leads to specific architectural principles.

These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:

Principle 1: Minimal necessary properties

Store intrinsic entity facts – not derived classifications, not calculated values. Just what’s true about this entity.

Customer #12345 has legal name (Acme Corporation Ltd) and tax ID (UK123456789), but territory assignment belongs in Master Data structures, and customer lifetime value belongs in analytics.

Why minimal? Because every property in a Master Record requires operational governance. More properties means more governance overhead. Master Data handles classification. Analytics handles calculation. Master Records handle entity facts.

Principle 2: Time-stamped changes

Properties change over time, so preserve history with effective dates. No “current state only” architecture. You’ll need historical reporting, audit trails, answers to “what did we know about this customer on June 15?”

Time-stamp from the start because retrofitting temporal data is painful. Adding effective dates after the fact breaks everything.

Principle 3: Single source per property type

Don’t duplicate entity facts across systems. Pick authoritative source for each property type. Customer legal name comes from CRM. Customer shipping address comes from Order Management.

The Master Record exists across systems, but each property has single authority. This is different from “golden record” approaches that try to create one master copy. The entity exists in multiple systems. Who has authority over specific properties is what matters.

Principle 4: Stable identifiers

IDs don’t change, ever. Customer #12345 stays #12345 forever, even if company name changes, even if acquired, even if relocated.

Everything else in the Master Record can change. The ID never changes.

Why? Because Transactions reference Master Records by ID. If IDs change, you break transaction history. Stable identifiers enable everything else to be mutable.

Customer #12345 properties (2025-10-28)

Customer #12345 properties:2020-01-01 to 2023-12-31:Address: Manchester, UKStatus: Inactive2024-01-01 onwards:Address: London, UKStatus: Active

Let’s deep dive into Cross-System Master Records

In real enterprises, Master Records live in multiple systems.

CRM has customers. ERP has customers. Billing has customers.

Not duplicates. Not golden records. Different systems, different purposes, same real-world entity.

Understanding Master Records as entities changes how you handle this.

You don’t try to consolidate. You don’t create golden records. You map across systems.

Cross-system mapping structure (Master Data):

Entity Mapping:Real-world: Acme Corporation├── CRM: CRM-12345├── ERP: ERP-98765└── Billing: BILL-45678

The Master Records exist in their systems, with the properties each system needs. The mapping structure (Master Data) connects them.

This is why the Master Data / Master Records distinction matters architecturally.

Master Records = entities in operational systems, governed operationally. Master Data = structures that organize/map entities, governed strategically.

No golden record needed. Just well-governed mappings.

The Minimal Principle Revisited

Master Records should contain minimum necessary properties.

Not because minimalism is virtuous. Because governance overhead scales with property count.

You include identity (ID, legal name), intrinsic facts (tax ID, registration date, serial number), contact and admin details (address, email, phone), and status (active, inactive, suspended). You don’t include derived classifications like territory, segment, revenue category etc – those belong in Master Data. You don’t include structural relationships like team membership, hierarchies, or networks – those belong in Master Data. You don’t include calculated values like credit score or lifetime value – those belong in the analytics layer.

Each property you add requires operational governance (who updates, when, how), creates dependencies (who consumes this property), and adds to change management overhead (what happens when it changes). Derive classifications from properties plus structures at reporting time. Keep Master Records minimal. Push complexity to Master Data and reporting.

Implementation Sequence

The Master Data / Master Records distinction seem to change the implementation sequence.

You can’t version Master Data structures until you stabilize Master Records.

Start with Master Records. Identify your core entities – customers, products, employees, locations. Define intrinsic properties, asking what describes THIS entity, not how you classify it. Implement time-stamping to preserve property history.

Then analyse what should be Master Data. Pull out structures like territories, taxonomies, and org charts. Version these structures separately from entities. Create classification rules. Implement strategic governance where management controls structures.

Then remove the embedded structures from the Master Records – no territory assignments, no hierarchies. Establish operational governance around who updates what and when.

Lastly, join everything at reporting time where properties plus structures equals classifications.

Master Records are the foundation. Master Data structures organize them. Build a stable foundation first.

To my understanding, this is the opposite of traditional MDM, which tries to build golden records (entities plus classifications) first. Understanding the distinction changes the implementation sequence.

What This Changes

Get Master Records right – stable entities with time-stamped properties – and Master Data becomes manageable.

Get Master Records wrong – embedded structures, missing time-stamps, bloated properties – and Master Data governance becomes impossible.

The distinction isn’t semantic. It’s architectural.

Master Records = Stable entities with time-stamped properties

• Operational governance
• Property-level authority
• Changes when entity facts change

Master Data = Mutable structures organizing entities

• Strategic governance
• Structure-level authority
• Changes when strategy changes

Transactions = Minimal references to Master Records

• Just IDs
• Immutable events
• No embedded properties

Reporting = Query-time assembly

• Join Transaction + Master Record + Master Data
• Use effective dates and version numbers
• Reconstruct classification at any point in time

Clean separation. Clear governance. Operational stability. Strategic flexibility.

That’s what the Authority rules give you with regards to Master Records as entities.

Not just “entities to manage.” Foundation for architecture that scales.

---

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/