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/