Three layers solve the restructuring problem. Transactions (immutable facts), Master Records (entity properties), Master Data (classification structures).
We’ve covered why embedding structures in transactions creates architectural and business challenges. As I explained in The Three-Layer Architecture Pattern, separating these layers enables strategic flexibility.
Now: Master Data specifically. Because this is the layer that the Authority Rule changes the most. Reference Data is not Master Data – that’s easy to understand. Master Data as Structure – can be a bit harder to get your head around.
What Master Data Actually Is
Master Data is structures, not entities.
Not individual customers. Not specific products. Not particular locations, those are Master Records. Instead, Master Data is the organizational framework you use to classify and organize those entities.
Classification structures: Territory hierarchies that organize customers by strategic importance and geographic coverage. Product taxonomies that group items by function, market, or business line. Org structures that define teams, divisions, and reporting relationships. Customer segmentation models that classify accounts by revenue potential, service requirements, or strategic value.
Relationship structures: Party-to-location assignments that map which customers use which shipping addresses. Cross-system mappings that connect CRM-12345 = ERP-98765 = same real-world entity. Corporate hierarchies that define subsidiary relationships, ownership structures, and consolidation rules.
Operating structures: Payment terms (Net30, Net60, Net90) – the standardized payment timing options you offer. Service tiers (Bronze, Silver, Gold, Platinum) – the standardized service levels you’ve structured. Party involvement types (Bill-to, Ship-to, Payee, Payer) – the standardized operational roles in your business processes. Delivery methods (Standard, Express, International) – the standardized fulfillment options you provide.
These structures are Master Data. Not because they’re “important data.” Not because they’re “golden records.” Because they’re organizational frameworks that management controls and they change when the strategy changes. As I explained in Master Data vs Reference Data, authority determines classification.
What Master Data Is NOT
This distinction matters.
Master Data is NOT individual entities. Customer #12345 is a Master Record. Product SKU-789 is a Master Record. Ship-to Location SL-10001 is a Master Record. Employee S-456 is a Master Record.
Master Data is NOT entity properties. Customer’s address is a Master Record property. Product specifications are Master Record properties. Location delivery hours are Master Record properties. Employee hire date is a Master Record property.
Master Data is NOT transaction data. The sales order is a Transactional Record, governed by Contract Authority (the agreement). The invoice and payment are also Transactional Records.
Master Data is the STRUCTURES organizing these entities. The hierarchies. The classifications. The mappings. The assignment rules. Not the things themselves. The frameworks for organizing things.
As I explained in Master Data, Master Records, and Transactions: The Distinction That Clarifies Everything, authority type determines how data changes. Master Data has internal strategic authority – management controls these structures and changes them when strategy changes. Territory structures, product taxonomies, org hierarchies – all under management’s authority.
The Three Structure Types In Detail
Classification structures organize entities into hierarchies.
Territory hierarchy example:
Enterprise Sales├── North Region│ ├── Strategic Accounts│ │ └── Criteria: Revenue > $1M, Country = US/CA/UK│ └── Growth Accounts│ └── Criteria: Revenue $250K-$1M└── South Region └── Emerging Markets```Management controls this structure. They can reorganize, split the North Region into North Enterprise and North Mid-Market, combine the South Region with Emerging Markets, and redefine the Strategic Accounts threshold from $1M to $5M.
The structure is mutable, strategic, under management authority.
Operating structures define how your business operates.
Payment terms:
Net30
Net60
Net90
Due on Receipt
2/10 Net 30
These are strategic choices. Management decides which payment options to offer, can add new terms (Net45), remove unused terms, change terms based on market conditions.
Service tiers:
Bronze: Basic support, 48-hour response
Silver: Priority support, 24-hour response
Gold: Dedicated support, 4-hour response
Platinum: 24/7 support, 1-hour response
Management defines these tiers, can restructure service levels, add premium tiers, consolidate tiers, change response time commitments.
The structures define operating reality. Management controls them. They change when strategy changes.
Relationship structures map connections between entities.
Party-to-location assignment example:
Customer: #12345 (Acme Corporation)Ship-to Locations: - Warsaw plant - Krakow distribution - Berlin office - Prague warehouse - Budapest facility - Vienna office - London headquarters```This mapping is Master Data. The customer entity is a Master Record. Each location is a Master Record. The party-to-location relationship structure maps which locations belong to which customer.
When Acme acquires a new facility or closes an existing one, you update the relationship structure. Customer Master Record unchanged. Location Master Record unchanged (or added/inactivated). Relationship structure updated.
Real-world entity: Acme Corporation
Real-world entity: Acme CorporationCRM System: CRM-12345ERP System: ERP-98765Billing System: BILL-45678The mapping structure connects these. No golden record needed. Just well-governed mappings maintained as Master Data.
Why This View Is Different
I initially thought there might be two types of Master Data. Classification structures (territories, taxonomies) felt different from operating structures (Net30, service tiers). They seemed like separate categories requiring different treatment.
But working through the Authority Rule framework revealed a pattern: it’s ALL structures. Just structuring in different ways.
Classification structures organize entities into hierarchies. Operating structures define how your business operates. Relationship structures map connections between entities. All three are organizational frameworks management creates to run the business.
None of them are the entities themselves. That’s the distinction.
To my understanding, traditional Master Data Management conflates Master Records (the entities) with Master Data (the structures organizing them). “Master Data Management” becomes “manage all the important stuff” without separating what things are from how you organize them. They want to create ‘golden records’ for these – the focus is on the entities
This framework separates them. Master Data = structures. Master Records = entities. Different authority. Different mutability. Different governance.
Authority Determines Mutability
From Master Data, Master Records, and Transactions: The Distinction That Clarifies Everything: authority type determines how data changes.
Reference Data (external authority): You can’t redefine ISO 3166 country codes. They change when ISO changes them. Immutable from your perspective.
Master Data (internal strategic authority): Management controls these structures. They redefine when strategy demands. Territory hierarchies reorganize. Product taxonomies restructure. Service tiers change. Mutable by design.
Master Records (internal operational authority): Properties change when entity facts change. Customer relocates, revenue grows, status changes. Time-stamped changes, not strategic restructuring.
As I explored in Contracts: The Fifth Authority Type, Contractual Authority is Bilateral binding agreement that locks specific versions of Master Data and Master Records for the contract duration. Neither party can unilaterally change the bound terms. Courts arbitrate disputes.
Transactions (captured authority): What happened stays what happened. Immutable truth. Customer bought product for amount on date – that’s a fact that doesn’t change.
Different authority. Different mutability. Different governance. Keep them separate in architecture.
Versioning Master Data
Since Master Data structures change when strategy changes, version them independently from Transactions and Master Records.
Territory structure v1.0 (effective 2020-01-01 through 2025-12-31):
Regional Sales containing North Region and South Region.
Territory structure v2.0 (effective 2026-01-01 onwards):
Enterprise Sales containing North Region Enterprise and South Region Enterprise, plus Mid-Market Sales containing North Region Mid-Market and South Region Mid-Market.
Both versions exist. Historical transactions use v1.0 when reporting 2023 data. Current transactions use v2.0 when reporting 2026 data. Trending across the change? System joins transaction date with appropriate structure version automatically.
No reposting. No migration. Update structure, version it, reporting adapts.
This works because the transaction never stored the classification. It only stored Customer ID and date. The system determines which territory structure to apply at query time, not storage time. Nothing to convert because nothing was classified when the transaction was captured.
This is different from the mapping tables rejected in the previous post about restructuring. Those mappings translated between versions of embedded structures—Old_Territory → New_Territory chains that compound forever.
Instead, these structures ARE Master Data—first-class architectural components that define entity connections. Party-to-location assignments don’t fix bad architecture. They ARE the architecture for managing relationships.
Does This Architecture Work?
I haven’t implemented this exact Master Data versioning architecture in a production system. But across insurance, manufacturing, banking – 12+ years as business architect – every restructuring nightmare I’ve seen comes so far from the same pattern: mutable structures embedded in immutable transactions.
Authority Rule reveals what’s needed: separate by authority type. Master Data (strategic, mutable structures) in one layer. Master Records (operational, time-stamped entities) in another layer. Transactions (captured, immutable facts) in a third layer. When you separate them, restructuring becomes routine instead of exceptional.
I’m testing this separation principle against real architectural scenarios. Every domain I’ve applied it to validates the pattern. Embedded structures always create a restructuring problem. Separated layers always enable flexibility.
The framework suggests this is what enables strategic flexibility without breaking operational stability. I’m working to prove it.
Governance By Authority Type
Master Data governance is strategic, not operational.
Who governs Master Data: Management, architecture, business stakeholders who define strategic frameworks. Not operational teams who maintain entity data.
What they govern: Classification structures, operating standards, relationship mappings. Not individual entity properties.
How it changes: Strategic decision-making. Territory reorganization requires management approval. Service tier restructuring requires executive sign-off. Cross-system mapping changes require architectural governance.
Why it matters: Master Data changes affect reporting, analytics, strategic metrics. Changes aren’t just “data updates” – they’re strategic decisions with business impact.
Contrast with Master Records governance (operational – sales ops maintains customer properties, product managers maintain SKU specs) and Transactional Records governance (none – transactions are immutable).
Different authority requires different governance. Separate the layers, separate the governance models.
Why This Matters
Strategic flexibility requires architectural separation.
If management can’t restructure territories without 3-month projects, architecture constrains strategy. If product teams can’t reorganize taxonomies without data migration, architecture blocks evolution. If finance can’t redefine cost centers without reposting transactions, architecture creates rigidity.
Master Data as versioned structures enables strategic flexibility. Restructure when business needs it. Version the change. Reporting adapts automatically. Transactions unchanged. Master Records unchanged. No migration. No reposting.
Business moves at business speed. Not IT speed.
That’s not “cleaner data architecture.” That’s competitive advantage. Competitors stuck with embedded structures take months to adapt. You take days. That’s the difference between architecture that enables and architecture that constrains.
The Test
Next time someone says “We need to restructure territories,” ask: “How long will it take?”
If the answer involves reposting transactions or migrating master data, structures are embedded where they shouldn’t be.
If the answer is “Update the structure, version it, done,” structures are properly separated as Master Data.
One architecture enables strategy. The other constrains it.
Next post: Master Records: The Entities Themselves – the entities that Master Data structures organize.
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/