Remember Post 12? Three months to restructure sales territories.
Now you know why.
Posts 12-18 established the framework. Master Data = structures (classification, operating standards, relationships). Master Records = entities with minimal properties. Three separate layers with different authority patterns, different mutability, different governance.
Now let’s go back to that restructuring nightmare and see exactly what went wrong.
Because once you see it with framework language, you can’t unsee it.
What You Actually Embedded
When you put territory in a transaction, you embedded Master Data.
From Post 13: Master Data is structures. Classification structures that organize entities into hierarchies. “Regional Sales > North Region” isn’t an entity. It’s a classification structure. Management created it to organize customers. Management controls it. Management changes it when strategy changes.
That’s Master Data.
You embedded it in a transaction.
Sale Transaction (Embedded Structure):Customer: #12345Product: SKU-789Territory: Regional Sales > North RegionAmount: £10,000Date: 2023-06-15“Regional Sales > North Region” is Master Data. Strategic authority. Mutable by management decision. Subject to restructuring when business needs change.
The transaction is immutable. What happened on 2023-06-15 doesn’t change. Customer bought product for amount. That’s a captured fact.
When you embed Master Data (mutable structure) in Transaction (immutable fact), you create an architectural violation.
The unchangeable contains the changeable. When structure changes, historical facts break.
What You Should Have Referenced
From Post 14: Master Records are entities with minimal intrinsic properties.
Customer #12345 is a Master Record. Product SKU-789 is a Master Record. These are things that exist. Entities with properties.
Transactions should reference Master Records by ID. Just the ID. Not properties. Not classifications. Not structures.
Sale Transaction (Minimal):Customer: #12345Product: SKU-789Amount: £10,000Date: 2023-06-15Just IDs pointing to entities. The transaction captures what happened. The Master Records contain entity properties (time-stamped). The Master Data structures contain classifications (versioned).
Reporting joins them at query time using dates and versions.
That’s the separation that prevents the restructuring nightmare.
The Authority Violation
From Post 6: Authority Rule determines how data changes.
Master Data has internal strategic authority. Management controls territory structures. They can redefine what territories exist. They change structures when strategy changes. Strategic authority means strategic mutability.
Transactions have captured authority. What happened stays what happened. The sale on 2023-06-15 is a fact. Facts don’t change. Captured authority means immutability.
When you embed strategic authority (mutable) in captured authority (immutable), authority patterns conflict.
Management needs to change territory structures. But changing structures breaks historical transactions. The architectural violation creates the three-month project.
Different authority. Different mutability. Can’t coexist in same data structure.
The Three Structure Types You Embed
Post 13 identified three Master Data structure types. You embed all three in transactions.
Classification structures embedded:
Territory hierarchies. Product taxonomies. Org structures. Customer segments. “Regional Sales > North Region” stamped in transaction. “Desktop Computing > Business Laptops” stamped in order. “Finance Division > Cost Center 4520” stamped in expense. “Enterprise Tier” stamped in customer interaction.
Every restructure becomes a data migration project.
Operating standard structures embedded:
Payment terms. Service tiers. Delivery methods. “Net30” stamped in invoice. “Gold Service Level” stamped in support ticket. “Express Delivery” stamped in shipment.
Every operational change requires updating historical records.
Relationship structures embedded:
Party-to-location assignments. Corporate hierarchies. Network memberships. “Ships to Warsaw Plant” stamped in order. “Subsidiary of Holdings” stamped in revenue record. “Member of Consortium with 15% discount” stamped in transaction.
When party opens new locations (Post 20 Scenario 1), when corporate hierarchy restructures (Post 20 Scenario 2), when network memberships change (Post 20 Scenario 3) — every transaction with embedded relationships requires updating.
All three structure types are Master Data. All three are mutable. All three get embedded in immutable transactions. That’s the architectural violation repeated across every structure type.
Why Traditional Fixes Fail
Post 11 showed three traditional fixes. Now you can see why they fail.
Fix 1: Repost everything
Update every transaction from Master Data v1.0 structure to Master Data v2.0 structure.
Why it fails: You’re overwriting captured facts with new classifications. The transaction says it happened in “North Region Enterprise” but it actually happened in “North Region” (v1.0 didn’t have Enterprise/Mid-Market split). Historical truth lost. Query-time classification would preserve both: what structure existed when transaction happened, and how that transaction would classify under current structure.
Fix 2: Mapping tables
Map old structure to new structure. “North Region” → “North Region Enterprise” mapping.
Why it fails: You’re mapping Master Data v1.0 to v2.0, but you still embedded structures in transactions. The mapping is relationship structure Master Data trying to correct embedded structure Master Data. Two structure types, both needing governance, both needing versioning, compounding complexity. Should have separated structures from transactions from the start.
Fix 3: Keep both structures
Add new field. Territory_v1, Territory_v2, Territory_v3 as structures change.
Why it fails: You’re embedding multiple Master Data structure versions in same transaction. Schema changes every time management restructures. Bloat increases with each version. Reporting conditional logic explodes. Should have versioned structures separately, not added fields to transactions.
All three fixes try to work around embedded structures. None fix the root problem: structures shouldn’t be in transactions at all.
Territory Restructuring Revisited
Let’s return to Post 11’s main example with framework language.
What you embedded: Classification structure Master Data (“Regional Sales > North Region”)
What you should reference: Customer Master Record ID (#12345)
What should be separate: Territory structure Master Data, versioned independently
How reporting should work: Join transaction (customer #12345) + Master Record properties (revenue, country as of date) + Territory structure version → territory assignment for that date
When territory restructures: Version structure to v2.0. Transactions unchanged. Reporting with v2.0 reclassifies same transaction as “North Region Enterprise.” Both classifications available. No reposting.
The same pattern applies to product reclassification (taxonomy changes), org restructures (hierarchy changes), and customer segmentation (classification rule changes). Different structure types. Same violation. Same fix. Separate structures from transactions.
What Minimal Transactions Enable
From Post 14: Master Records contain minimal intrinsic properties. No derived classifications. No calculated values. Just what’s true about the entity.
Transactions follow the same principle. Minimal. Just what happened.
Customer ID, Product ID, Amount, Date. Not customer properties. Not product properties. Not territory structures. Not taxonomy classifications. Just references to things and facts about the event.
Why minimal? Because everything you embed creates dependencies.
Embed territory: Dependent on territory structure version. When structure changes, transaction needs updating or mapping or dual-fielding.
Embed customer properties: Dependent on property values at transaction time. Customer relocates, property changes, historical transaction has outdated property. Time-stamped Master Records handle this. Transactions just reference ID.
Embed product classification: Dependent on taxonomy version. Taxonomy changes, classification changes, transaction becomes historically inaccurate. Versioned Master Data handles this. Transactions just reference ID.
Minimal transactions have minimal dependencies. Maximal flexibility. When business changes, minimal transactions don’t need changing.
The Three-Layer Pattern Completed
Posts 11-12 introduced problem and solution. Territory restructure takes three months because structures are embedded. Three-layer pattern separates them.
Post 13 explained Master Data. Structures that organize. Classification, operating standards, relationships. Strategic authority, mutable, versioned.
Post 14 explained Master Records. Entities with minimal properties. Operational authority, time-stamped, stable IDs.
Posts 19-20 showed relationship structures as Master Data. Cross-system mappings, party-to-location, corporate hierarchies, network memberships. All relationship structures. All Master Data. All separate from entities.
Post 17 showed Contracts as bilateral agreements. What belongs in contracts versus what stays in structures.
Now Post 21 completes the pattern. Transactions are immutable captured facts with minimal references. No embedded properties. No embedded structures. Just IDs pointing to Master Records.
Three layers:
- Transactions (minimal, immutable – just IDs and facts)
- Master Records (entity properties, time-stamped)
- Master Data (structures, versioned independently)
Reporting joins them at query time. Transaction date + Master Record effective date + Master Data version = correct classification for that point in time.
No reposting. No migration. No three-month projects. Routine structural change.
Why Embedding Breaks Everything
The title isn’t hyperbole.
When you embed mutable structures in immutable facts, three things collapse:
Strategic flexibility stops. Management can’t restructure without IT projects. Business decisions wait for technical implementation. Territory restructure? Three months. Taxonomy change? Migration project. Org reorganization? Mass data update. Every strategic shift becomes a technical obstacle. Competitors who can adapt quickly gain advantage while you’re stuck in implementation.
Historical accuracy disappears. Reposting overwrites what actually happened. Mapping tables approximate relationships. Dual-fielding creates confusion about which version to trust. The sale that rolled up to “North Region” in 2023 now claims it was always “North Region Enterprise.” Query results don’t match what people remember. Original truth lost.
Architecture ossifies. Every structure change requires transaction updates. Every property change requires field additions. Every new classification requires schema changes. The system becomes a cage instead of an enabler. Adding capabilities means touching immutable records. Evolution stops because change is too expensive.
Everything breaks because you embedded mutable structures in immutable facts.
What Separation Enables
Separate structures from transactions, and architecture transforms:
Strategic flexibility returns. Management restructures territories. Version the structure. Transactions unchanged. Reporting adapts. Days instead of months. New taxonomy? Version it. Org change? Version it. Business agility becomes routine, not exceptional.
Historical accuracy preserves. Transaction captured what happened. Master Record properties time-stamped. Master Data structures versioned. Query any point in history with correct context. Compare across time using appropriate classifications. Users verify accuracy against their memory. Trust builds because data proves consistent.
Architecture enables. Add structures without touching transactions. Change classifications without migration. Evolve organization without reprocessing. System adapts instead of constraining. New capabilities extend structures, not schemas. Growth becomes architectural, not disruptive.
Everything works because immutable facts stay separate from mutable structures.
The Test Returns
From Post 11: Next time someone says “We need to restructure territories,” ask “How long will it take?”
Now you can diagnose why:
If answer is “three months” → structures embedded in transactions
If answer is “need to repost historical data” → Master Data not versioned separately
If answer is “need mapping tables” → trying to fix embedded structures instead of separating
If answer is “can’t compare historical to current” → lost query-time composition capability
If answer is “update the structure, version it, reporting adapts” → proper separation achieved
One architecture requires three months. The other requires structure update. Same business decision. Completely different implementation cost.
The difference is whether you embedded structures in transactions or separated them as Master Data.
Understanding why embedding structures breaks everything explains why separation matters. Not just cleaner architecture. Strategic flexibility. Business agility. Competitive advantage.
Architecture that enables rather than constrains.
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