Data Authority Rule

Tag: System Design

  • The Three-Layer Architecture Pattern

    The premise is that embedding Master Data in transactions makes restructuring expensive and brittle.

    Territory hierarchies baked into sales records. Product classifications locked into invoices. Customer segmentations part of financial transactions. When management wants to reorganize, you need either to repost transactions. Or you build mapping tables. Or you accept broken historical reporting.

    The Authority Rule points to a different Architecture. The distinction between master data, master records, and transactions separates what happened from how you classify it.

    Three layers. Separate what happened from how you classify what happened. Separate entity facts from organizational structures. Each layer governed differently, each layer versioned differently, each layer serving its own purpose.

    Keep them separate, and restructuring becomes (hopefully) trivial.

    The Three Layers

    Layer 1: Transactions – What happened. Immutable facts captured at the moment of occurrence.

    Layer 2: Master Records – Entity properties that define specific entities: this customer, this product. Time-stamped so you know what was true when.

    Layer 3: Master Data – Classification structures and operating standards that organize entities. Versioned independently so management can restructure without touching operational data.

    Each layer has different authority. Different mutability. Different governance. The architecture works because you keep them separate and join them only when reporting.

    Layer 1: Transactions – Immutable Facts

    Store the absolute minimum. Entity identifiers, amounts, dates. Reference Data that’s a fact about this specific transaction.

    Transaction ID: TXN-2025-10-15-001Amount: $50,000Customer ID: #12345Product ID: SKU-789Salesperson ID: S-456Date: 2025-10-15Currency: USD

    That’s it. No territory hierarchy. No product classification. No customer segmentation. Just the facts about what happened.

    As I explored in Transactions: Why Embedding Structures Breaks Everything, transactional records have ‘captured authority – the system recorded what happened, and you can’t change what happened. This transaction stays this way forever.

    Everything else – how you classify this sale, which territory you assign it to, which product hierarchy you organize it under – lives in other layers.

    Layer 2: Master Records – Entity Properties

    Time-stamped properties that define specific entities. Customer moved from England to Scotland? Product specifications changed? Location delivery hours updated? Time-stamp the change in the Master Record.

    Customer #12345:

    Effective 2020-03-01 to 2025-09-30:- Country: UK- Address: 45 London Road, ManchesterEffective 2025-10-01 onwards:- Country: UK- Address: 123 Main St, Glasgow

    Every transaction references the entity ID. When reporting, the system joins transaction date with Master Record effective dates automatically. Transaction from June 2025? System uses the English properties. Transaction from November 2025? System uses Scottish properties.

    No reposting. No manual updates. Time-stamping handles it.

    Master Records have “your authority, typically operational” – these are the entities your business operates with, and you control when their properties change. I explore this in depth in Master Records: The Entities Themselves.

    Layer 3: Master Data – Classification Structures

    This is where organizational strategy lives. Territory hierarchies. Product taxonomies. Org structures. Operating standards like payment terms and service tiers. Relationship mappings like party-to-location assignments.

    These structures change when strategy changes. This is why master data is the layer that changes. Version them independently from transactions and Master Records.

    Territory structure effective Q1 2025:

    Enterprise Sales├── North Region│   ├── Strategic Accounts (Revenue > $1M, Country = US/CA/UK)│   └── Growth Accounts (Revenue $250K-$1M)└── South Region    └── Emerging Markets

    Territory structure effective Q1 2026 (strategy shifted):

    Enterprise Sales├── Global Strategic (Revenue > $5M, any country)├── Regional Enterprise (Revenue $1M-$5M)│   ├── North America│   └── EMEA└── Growth Segment (Revenue < $1M)

    Same transactions. Same Master Records. Different classification structure.

    How Reporting Joins the Layers

    Query: “Show me sales by territory for Q4 2025”

    System process:

    1. Transactions layer – Pull all transactions from Q4 2025, get Customer IDs
    2. Master Records layer – Join Customer IDs with properties effective during Q4 2025
    3. Master Data layer – Apply territory rules effective during Q4 2025
    4. Result – Sales classified by territory as it was structured in Q4 2025

    Now run the same query for Q4 2026. The system automatically uses the territory structure effective in Q4 2026. Different classifications. Same transactions. Same Master Records.

    When you restructure territories in January 2026, you update the Master Data layer. Version it. Effective date: 2026-01-01.

    Transactions unchanged. Master Records unchanged. Historical reporting uses old structure. Future reporting uses new structure. Trending across the change? System handles it automatically by joining appropriate versions.

    No reposting. No mapping tables. No data migration. Update the structure, version it, reporting adapts.

    Why This Matters

    The traditional approach embeds structures in transactions. Want to reorganize territories? In several systems, you then have to repost every transaction to reflect the new hierarchy. Or change your Data warehouse. Want to change product taxonomy? Update thousands of records. Want to implement new customer segmentation? Potentially a data migration project, not between systems, between structures.

    Expensive. Slow. Error-prone.

    Three-layer architecture separates immutable facts (transactions) from stable properties (Master Records) from mutable structures (Master Data). Each layer governed independently. Each layer versioned appropriately.

    Management changes strategy? Update Master Data. New effective date. Done. Transactions and Master Records stay untouched. Historical reporting still works. New reporting uses new structure automatically.

    That’s strategic flexibility. That’s operational stability. That’s architecture that enables business to move at business speed rather than IT speed.

    Next post: Master Data: The Layer That Changes – what Master Data actually is, what it contains, and how versioning classification structures independently creates flexibility without chaos.

    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/

  • When Management Restructures, Systems Break

    Three months to restructure sales territories.

    Not because the business decision is hard. That took one meeting. Sales leadership decided to organize by customer size instead of geography. Split “North Region” into “Enterprise” and “Mid-Market.” Simple strategic shift.

    But every transaction in the system has the old territory embedded in it.

    Change the territory structure, and you break history. So you spend three months (or more) reposting transactions, updating reports, fixing analytics, rebuilding dashboards. All because someone decided to split to split regions differently.

    This happens everywhere. Insurance, banking, manufacturing, government, retail. Management makes a strategic decision in one hour. IT spends three months implementing it.

    Not because the change is complex. Because something is architecturally wrong. Because something is architecturally wrong. As I explored in Master Data vs Reference Data, understanding data authority explains why

    The Pattern Repeats Everywhere

    Territory restructuring: Sales leadership decides to reorganize by customer size instead of geography. IT and Finance spends months reposting every sales transaction with new territory assignments. Historical reports break. Year-over-year comparisons stop working. The 2023 North Region isn’t the same as the 2026 North Region, but the system treats them as identical.

    Product reclassification: Product management decides laptops should be under “Mobile Computing” instead of “Desktop Computing.” IT spends weeks updating the system. Historical product reports show laptops that never existed under “Mobile Computing” in 2023 suddenly appearing there. Data integrity questions follow.

    Org restructure: Executive team reorganizes divisions. Finance spends months reclassifying expenses, updating cost centers, rebuilding management reports. Department budgets from 2023 get compared against completely different organizational structures in 2026. Trending becomes meaningless.

    Customer segmentation: Marketing redefines “Enterprise” vs “Mid-Market” based on new criteria. Analytics team spends weeks recalculating historical segments, updating every customer interaction. Three years of customer behavior reports become unreliable because the definition of “Enterprise” changed halfway through.

    Same problem. Different domains. Different systems.

    Management wants to change how things are classified. IT has to change every transaction that references that classification.

    Every. Single. Transaction.

    What It Actually Costs

    Time cost: Three months to restructure territories. Six months to reclassify products. Quarterly cycles to update cost centers. Strategic decisions get delayed because implementation takes too long. The market moves faster than your systems can adapt.

    Opportunity cost: Management can’t adapt to market changes because they’re stuck with old structures. Change is too expensive. “We’d like to restructure, but IT says it’ll take three months and disrupt operations.” Competitors who can restructure quickly gain advantage. You watch opportunities pass while waiting for IT capacity.

    Quality cost: Reposting introduces errors. Someone makes a mistake in the transformation logic. Historical data loses integrity. Reports stop matching. Finance questions the numbers. “Is this report accurate or did someone mess up the territory mapping?” Trust in data erodes.

    Innovation cost: You can’t experiment with new structures. Too expensive to try. Too expensive to revert if it doesn’t work. Business model evolution gets constrained by technical implementation costs. “Let’s test this new segmentation approach” becomes “Let’s spend three months implementing it first, then see if it works.”

    Strategic cost: Architecture determines what the business can do. Strategy becomes limited by system constraints. The business exists to serve the systems instead of systems serving the business. The tail wags the dog.

    Why Traditional Fixes Don’t Work

    In my experience organizations try three approaches, none which truly solve the problem.

    Fix attempt 1: Just repost everything

    Three months of work every time management restructures. 2023 data gets reclassified using 2026 structure, so you can’t see what territories actually were in 2023. You lose historical truth. Reposting logic has bugs. Data quality degrades. Trust erodes.

    Ultimately unsustainable. Management can’t restructure when business needs it because they have to wait for IT capacity.

    Fix attempt 2: Keep mapping tables

    Create mappings between old structure and new structure. Old “North Region” maps to new “North Enterprise” plus “North Mid-Market.” Now you have two problems: the original embedded structures, plus mapping tables to maintain forever.

    Mappings compound with each version. v1 → v2 mapping, then v2 → v3, then v1 → v3 derived mapping. Exponential complexity. Multi-hop mappings lose precision as the chain of transformations accumulates ambiguity.

    Historical analysis still breaks. You can map forward but lose the original classification. Trending across the transition becomes interpretation, not fact.

    Fix attempt 3: Keep both structures

    Add new fields. Keep old territory, add new territory. Bloat every transaction.

    Sale Transaction (Bloated):Territory_v1: Regional Sales > North RegionTerritory_v2: Enterprise Sales > North Region EnterpriseTerritory_v3: ... (next restructure)Territory_v4: ... (next restructure)

    Schema changes every time management restructures. You can’t add fields retroactively to historical transactions without reprocessing anyway. Reporting becomes a nightmare. Which territory field to use depends on transaction date, creating conditional logic everywhere.

    None of these solve the problem. They just manage the symptoms.

    The Real Question

    Why does changing a classification structure require changing every transaction?

    Why does a strategic decision in one hour require three months of implementation?

    Why does reorganizing territories break historical reports?

    Territory is how you organize customers. Customer is the thing being organized. Why does changing the organization require changing the things?

    When you restructure your filing cabinet, you don’t rewrite every document in it. You reorganize the folders. Documents stay unchanged. You pull them from different locations, but the documents themselves are immutable.

    So why do systems work differently?

    Something Is Architecturally Wrong

    This isn’t a data problem. It’s an architecture problem.

    The structure shouldn’t be embedded in the transaction. The organization shouldn’t be embedded in the thing being organized. The mutable (master data that changes) shouldn’t be embedded in the immutable

    But current systems embed structures everywhere. Territory in every sales transaction. Product category in every order. Org structure in every expense. Customer segment in every interaction.

    When structure changes, everything breaks. The three-layer architecture pattern shows why this happens.

    There must be a better way.

    The Pattern

    Once you notice this pattern, you see it everywhere.

    Any time a strategic restructuring takes months to implement, structures are embedded where they shouldn’t be.

    Any time management says “We’d like to reorganize but…” they’re blocked by architecture constraints.

    Any time historical reports break after a restructuring, immutable facts contain mutable structures.

    The pattern is universal. The cost is enormous. The solution isn’t obvious.

    But the problem is clear: something fundamental about how we build systems is wrong.

    Next post: Why this happens – and what it reveals about how we classify data.

    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/