Post 9 in The Authority Rule Series
Last post covered buying systems from vendors who don’t use ISO standards. The hidden costs, the mapping tables, the technical debt that compounds forever.
You might think: “We’ll build it ourselves. Then we control the outcome.”
You do. If you enforce standards.
Most teams don’t.
The Build vs Buy Parallel
When you buy a vendor system that doesn’t use ISO standards, you inherit their technical debt. You discover it during implementation or years later, too late to walk away.
When you build a system in-house that doesn’t use ISO standards, you create your own technical debt. Often, you don’t discover it until integration, or audit, or years later.
Same problem. Different source.
The advantage of building in-house: You can prevent it. The reality: Most teams don’t.
What Should Happen (But Often Doesn’t)
When you build a bridge, the structural engineer specifies materials before construction starts. Grade 50 steel. Class 8.8 bolts. 40MPa concrete. If those materials can’t deliver the architect’s design, they sort it out before building, not after.
In my experience software development rarely works this way.
Business requirement: “The system needs to handle international customers.” Business Analyst writes requirements. Developer builds it. Using what country codes?
Often, no one specifies. The developer makes a choice – maybe ISO 3166, maybe a custom list, maybe whatever dropdown library they found online, maybe just a text field. You discover the problem later during integration testing, when the compliance team asks why your system defines countries differently than the third-party screening service, or during the first regulatory audit.
Or you never discover it. You just accumulate technical debt and wonder why integration is always harder than thought it would be.
Why This Happens (And Why I Missed It)
I assumed developers would use ISO standards for countries, currencies, languages. Why wouldn’t they?
Maybe ISO standards cost money? Maybe developers don’t know they exist? Maybe “I only need 10 countries for this system” seems simpler than researching the standard? Maybe “Micronesia (Federated States)” versus “Federated States of Micronesia” doesn’t seem like it matters when you’re just building a dropdown?
I’ve now encountered at least three separate systems, over my career, where vendors or development teams used custom codes instead of ISO standards. Each time, I was surprised. Maybe I’m blind to this. Maybe my background made it invisible.
But the evidence is clear: there’s no profession-wide expectation that reference data means ISO standards, or an industry standard. No enforcement mechanism. No licensing requirement. No inspector who fails the build. Developers make choices under time pressure. Sometimes they choose standards. Sometimes they choose “good enough for now.”
“Now” becomes forever, and when they don’t use standards, you also pay forever.
Role Accountability That Could Work
I’ve been thinking about what could improve the situation and I think the answer is in clearer role accountability making standards enforceable. Here’s what it could look like.
Architects define which standards apply. ISO 3166 for countries. ISO 4217 for currencies. ISO 639 for languages. Industry standards like ACORD for insurance, NAICS for industry classification. Not suggestions—requirements or patterns. Documented, findable, required.
Developers use the standards. When building country fields, ISO 3166. When building currency fields, ISO 4217. No custom codes. No “we’ll fix it later.” If the standard isn’t documented, ask Architecture which one applies. Don’t invent your own. Code reviews check compliance. Architecture violations aren’t style issues—they’re technical debt with compounding costs.
Business Analysts reference standards in requirements. Most of them don’t, I didn’t the times I worked as a business analyst earlier in my career. They write “system shall capture customer country” instead of “system shall use ISO 3166-1 alpha-2 codes.” User stories should reference standards explicitly. Acceptance criteria should verify compliance.
QA verifies compliance. Test data uses correct codes. System validation enforces standards. If country codes don’t match ISO 3166, that’s a defect—flag it . Most QA plans don’t check for this.
When You Actually Need Custom Codes
Sometimes you genuinely need translations between standards and legacy reality.
Legacy system migration: Old system used “GB” to mean Great Britain. ISO 3166 uses “GB” for United Kingdom. During migration, you need to handle both. Time-boxed. Documented. Translation layer clearly identified. Removed post-migration.
Vendor integration: External system sends “Micronesia” as free text. You can’t change their system. Build a translation layer at the integration boundary. Map to ISO internally. Keep the non-compliant data at the edge.
Customer-facing display: ISO code “GB” displays as “United Kingdom” in the UI. That’s presentation layer, not data layer. ISO standard underneath, friendly text on top.
But translations live in specific places—integration boundaries, presentation layers. They don’t pollute the core data model.
What Happens Without Enforcement
Developer A uses “SV” for Sweden (thinking Svenskt). Developer B uses “SE” for Sweden (ISO correct). Developer C uses “Sweden” as free text because the field was varchar(50). Developer D uses “Sve” because they needed varchar(3) and didn’t know ISO existed.
Now you have four definitions of Sweden across your systems.
You just rebuilt the vendor problem from the previous post. Except this time, you can’t blame the vendor. You built it yourself, one developer at a time, one undocumented decision at a time.
Years later, someone tries to integrate these systems. Mapping tables everywhere. Transformation logic. Test case multiplication. All preventable. If anyone had enforced standards before the first line of code shipped.
The Cost of “We’ll Fix It Later”
“We’ll standardize it when we integrate.” No, you won’t. Integration deadlines are tight. You’ll build mapping tables and move on.
“We’ll clean it up in the next release.” No, you won’t. The next release has new features. Data cleanup never makes the roadmap.
“We’ll address it during the replatforming project.” Maybe. If the replatforming project happens. If it doesn’t get cancelled when costs overrun. If the team remembers why this matters.
Technical debt compounds. Every month, more data gets created using non-standard codes. More integration points get built assuming those codes. More reports get written around that structure. The cost of fixing it grows. The willingness to fix it shrinks.
Eventually, it becomes “how we do things here.” Accepted. Documented. Permanent.
You could have prevented it on day one.
What You Can Do
If you’re an Architect: Document reference data standards for your domain. Make them findable. Make them required. Review compliance at appropriate times.
If you’re a Developer: Don’t create custom reference data codes. Ask which standard applies. Use it. If no standard is documented, request one before you build.
If you’re a Business Analyst: Reference standards explicitly in requirements. “System shall use ISO 3166 for countries” not “system shall have a country field.” Make standards compliance part of acceptance criteria.
If you’re in QA: Add standards compliance to test plans. Verify codes match ISO or documented industry standards. Flag non-compliance as defects.
If you lead development: Enforce standards compliance in code reviews. Make it clear that architecture violations create technical debt, and technical debt has ongoing costs.
If you’re buying AND building: The previous post showed how you could evaluate vendors before you sign contracts. This post shows how to enforce standards before you write code. Same goal: prevent technical debt at the source, not manage it forever.
Vendors who don’t use standards cost you. Developers who don’t use standards cost you. You can choose better vendors. You can enforce better standards.
Make both choices.
Building in-house gives you control.
But control without enforcement just means you own the technical debt instead of inheriting it. The choice is yours. Make it before the first line of code ships.
Because after that, you’re just managing consequences.
This post is part of The Authority Rule series exploring how authority patterns determine data classification and governance. The framework emerged from real-world experience building enterprise data architecture across multiple industries.
Read the full series at authorityrule.com/