Data Authority Rule

Tag: Business Strategy

  • Master Data: The Layer That Changes

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

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

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