Micronesia potentially broke our system.
Not catastrophically. Just… wrong. A Business Analyst flagged it. One potential data mismatch in a system we’d already used for years, now maybe causing issues with data mapping.
It reminded me of the Sweden/El Salvador disaster from Post 2. A Swedish developer picked “SV” for Sweden, not knowing ISO had assigned it to El Salvador. Years of mapping tables to fix someone else’s assumption.
Over the weekend, I started thinking about every procurement process I’d been part of.
We never evaluated reference data standards.
Not once.
What I Evaluated (And What I Missed)
At EDS, I evaluated vendor systems as the business expert on procurement teams. At Catalyst Housing, I led procurement projects.
We checked everything. Functionality. Integration architecture. Security. Implementation timeline. Commercial terms. Vendor stability.
Everything except reference data standards.
Not because I didn’t care. Because it seemed obvious they’d be right.
The Impact Cascade You Didn’t Price In
When a vendor doesn’t use ISO standards, you’re not just buying “some integration work.” You’re buying consequences that ripple through your entire technology estate.
Initial impact: Someone builds mapping tables. Vendor codes to ISO. Every vendor update/upgrade, you might need to update the mappings. Every ISO change, you update. Forever.
Your compliance checking service uses ISO standards. Now you need transformation logic. Test cases. Exception handling. What happens when the mapping fails?
Every new integration: Another mapping layer. More transformation logic. Compatibility testing with existing mappings. Documentation updates that future teams will need.
Every new vendor: Three vendor systems, three different definitions of “Micronesia”. System A: “Micronesia”. System B: “FM” (ISO code, wrong mapping). System C: “FSM” (wrong definition). Three mapping tables. Not to ISO—to each other. Testing matrix multiplication. Exception handling for mismatches between systems.
Test automation becomes a nightmare. Which version of “Micronesia” does each test case need? Mock data must account for every vendor’s definitions. Automated regression suites fail when mapping changes. CI/CD pipelines need transformation validation. Every automated test touching reference data needs vendor-specific variants.
Operational impact: Support tickets when data doesn’t match. Manual workarounds when automation fails. Training new team members on “why we do it this way”. Knowledge loss when key people leave.
Compliance and audit: Explaining to regulators why systems define data differently. Control weakness findings. Remediation plans. Annual re-findings when nothing fundamentally changes.
Strategic constraints: New compliance requirements require integration work before implementation. New analytics platforms need mapping before they’re useful. API integrations to partners delayed by transformation complexity. Technical debt that makes every future decision harder.
The costs aren’t just money. They’re velocity. Opportunity. Strategic flexibility.
And they compound forever.
What Should Change
This should be an explicit evaluation criterion. Not buried in technical architecture review. Not assumed. Scored.
Before vendor selection, ask which reference data standards they use. ISO 3166 for countries. ISO 4217 for currencies. ISO 639 for languages. Industry standards like ACORD, SWIFT, HL7.
Then ask how they maintain them. Automatic feed from authoritative source? Manual updates—how often, who’s responsible? Custom definitions—where’s the documented mapping?
Ask where they deviate from standards. Which entities use non-standard codes? Why? Legacy system? Customer request? Deliberate choice? What’s the mapping approach? Only in the UI?
Ask how they handle updates. New country codes from ISO? Currency changes like Bulgaria joining the Euro? Deprecated codes?
Ask what integration support they provide. Pre-built mappings to standards? Documentation of code definitions? Transformation services?
If vendors can’t answer clearly, price in the integration cost.
Why I Didn’t See This Coming
I studied Economics. You use ISO country codes, ISO currency codes, standardized data definitions. Otherwise analysis is impossible. You can’t compare GDP across countries if everyone defines “country” differently.
Most systems do use ISO standards. Countries. Currencies. Languages. All the reference data is correct.
When your academic background and your first decade of professional experience both assume standards compliance, you don’t question it.
Why would you? These are professional software vendors building enterprise systems. This is foundational.
Except it’s not foundational to everyone.
I didn’t think to ask during procurement because I’d never encountered a system that got it wrong.
The Conversation with Procurement
If you’re a Business Architect, Enterprise Architect, or data professional reading this, you might be thinking: “Yes! This! How do I get procurement to care?”
Frame it as risk management, not technical detail.
“We’re evaluating a vendor that could create ongoing integration costs because they don’t use industry standards for reference data. Should we price this into the commercial negotiation?”
Make it a standard RFP question.
“I drafted some questions about reference data standards compliance. Could we add these to the technical architecture section of our RFP template? It’ll help us identify hidden costs earlier.”
Show the business impact.
“Three vendor systems define countries differently. When we try to implement compliance checking, we’ll need months of integration work. Could we evaluate reference data standards in future procurements to avoid this?”
Offer to help.
“I can review technical architecture sections of vendor responses specifically for reference data compliance. It takes me thirty minutes per vendor and could save us significant integration costs.”
Don’t make it about governance. Don’t make it about data purity. Make it about cost, risk, and integration complexity.
Procurement teams manage cost and risk every day. Give them the business case.
What I’d Do Differently Now
If I were leading a procurement initiative today, reference data standards would be an explicit evaluation criterion.
Not a nice-to-have. A scored requirement.
Compliant with ISO/industry standards: Full marks.
Custom codes with documented mapping: Partial marks, priced accordingly.
Custom codes with no mapping plan: Major red flag.
Because I’ve seen the costs. I’ve watched integration projects stall on data transformation. I’ve heard of test automation grinding to a halt because mock data needs multiple versions for the same country.
The Authority Rule taught me: You don’t own reference data. But you own the consequences of choosing vendors who pretend they do.
What You Can Do
If you’re in procurement: Add reference data standards compliance to your evaluation criteria. Ask vendors to document their approach. Price non-compliance into commercial terms.
If you’re a Business Architect or Enterprise Architect: Review your vendor landscape. Document which systems use non-standard codes. Quantify the integration impact across the areas that touch: transformation, testing, operations, compliance, strategy. Take this to procurement with a business case.
If you’re a vendor: Understand that your customers pay forever for your architectural choices. Using ISO standards isn’t gold-plating. It’s reducing your customers’ total cost of ownership.
If you’re buying systems off the shelf: Before you sign that contract, ask: “Which reference data standards do you use?” If they can’t answer clearly, you’re buying technical debt.
The Micronesia conversation started this thinking. But it applies to every vendor system that doesn’t use reference data standards as its internal keys.
The costs are hidden. The consequences are long-term. And the decision is made during procurement, often without anyone realizing it matters.
I didn’t realize it earlier in my career.
I realize it now.
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/
Leave a Reply