Post 5 of The Authority Rule Series
When one “innocent” deviation from an ISO standard costs thousands (or more) every year.
A Swedish developer made a reasonable decision. Their system needed country codes. Sweden is “Sverige” in Swedish. The natural abbreviation is “SV.” So they coded Sweden as “SV” in the database.
Seemed perfectly logical. Got the project done. Moved on.
Except ISO 3166 assigns “SV” to El Salvador.
What Happened Next
When the company started selling to El Salvador, they hit a wall. “SV” was already taken. So El Salvador got a different code, which meant permanent mapping tables in every integration. The data warehouse team discovered this variation years later when conforming data from multiple systems, and by then, the original developer was gone. The decision wasn’t documented; it seemed obvious at the time.
Every migration touched this issue. Every integration required mapping logic. Every data warehouse layer needed transformation rules for fifteen years and counting.
This wasn’t malicious or incompetent. It was one reasonable person making one local decision under project deadline pressure.
The problem: Nobody told them ISO has authority over country codes.
How It Really Happened
Here’s what was missing: No one had decided “we use ISO 3166 for country codes.” No one had documented that country codes have external authority. QA had no policy to check against. Architecture hadn’t defined the pattern; they might not even have existed at the time of this project. So when project pressure hit and the developer needed a solution, they made the call themselves.
Reasonable. Local. Wrong authority level.
The failure wasn’t the developer’s. It was organizational—no one owned the decision about which external standards to follow.
The Lifecycle Cost Nobody Captures
Business cases model three to five years of maintenance. But systems run for fifteen to twenty years, or more, and this single ‘innocent’ decision touches every part of the software lifecycle.
In development, you need permanent mapping tables in every system that integrates.
During integration, every external connection requires special handling—forever.
In the data warehouse, someone years later has to discover this variation when conforming data from multiple systems, often without documentation explaining why it exists.
New developers are likely to assume the custom code is standard and are at risk of propagating the error.
During migration, you have to remember, discover, or reverse-engineer the mapping, or everything breaks.
The business case said three years. The system ran for twenty. One innocent decision. Decades of compounding technical debt.
Where Responsibility Sits
Someone must own the decision about which external standards the organization follows. If you have a Chief Data Officer, this sits in their domain. If you don’t have a CDO it is likely to be the Enterprise Architecture team. If you have neither, someone still needs to be responsible; in small organizations, it might be the Head of IT or Tech Lead.
It doesn’t matter who. It matters that someone owns it.
That role decides: “We use ISO 3166 for country codes. Non-negotiable.” Then QA checks compliance, and developers know they can’t redefine Sweden.
The Authority Rule Prevents This
The Authority Rule asks: Who has the authority to define what this means?
For country codes, can you redefine what “Sweden” should be coded as tomorrow? Actually, no. ISO 3166 has that authority—every external system expects ISO codes, every industry standard uses them, every data exchange requires them. You don’t own this definition. That makes it reference data.
Which means you follow the external authority. You don’t redefine it, create “helpful” variations, or make it fit local preferences.
One question. One moment of clarity. Years of technical debt prevented.
What This Means Monday Morning
Identify who owns external standards decisions in your organization—CDO, Architecture, CTO, someone must have this responsibility. Document which external authorities you follow: ISO 3166 for countries, ISO 4217 for currencies, SWIFT for bank identifiers. Create guardrails that prevent deviation through architectural patterns and QA checks. When developers ask “can we just use our own codes?” the answer is already documented.
Recognize that reference data needs policy, not governance. No approval workflow. No committee discussion. Just a rule: Follow the external authority.
Why This Matters
The Swedish developer wasn’t wrong to want “SV.” They just didn’t know ISO already owned that decision, and nobody in the organization took responsibility for telling them.
That one missing policy created technical debt that compounds annually across the entire enterprise for decades. When you ignore reference data, you don’t just create one mapping table; you create permanent complexity that touches every system, every integration, every migration, every new developer, for the entire lifecycle of your estate.
The Authority Rule prevents this by asking one simple question that reveals where authority actually sits: Can you redefine this? No. Then follow the standard.
The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? If you need others to accept = reference data. If you don’t = master data.
Read the full series at authorityrule.com/
Leave a Reply