Interoperability in Government IT: Why It's Harder Than a Framework

The meeting that changed how I think about interoperability

Years into digital transformation work across fifteen countries, I sat in a room where two government agencies were trying to share a single dataset. Both ran SAP. Both were in the same country. Both reported to the same ministry. And they could not agree on what a "customer" was — whether it meant a citizen, a business, a legal representative, or all three depending on context.

That meeting lasted four hours. We left without a decision. The integration project slipped by three months.

I think about that room every time someone hands me a framework document and says interoperability is a technical problem. It is not. It is a governance problem that sometimes has a technical solution. The European Interoperability Framework — the EIF — is a genuinely useful document. But if you go into a public sector digital project thinking the framework is the hard part, you will be surprised by what actually breaks things.

What the EIF actually says — and what it leaves out

The EIF, published by the European Commission and now reinforced by the Interoperable Europe Act that came into force in 2024, organises interoperability across four layers: legal, organisational, semantic, and technical. That structure is correct and useful. Most integration failures I have seen touch all four layers simultaneously, which is exactly why the framework insists you cannot solve just one and call it done.

Legal interoperability means the data sharing is actually permitted — by legislation, by data protection rules, by sector-specific regulation. This is where GDPR intersects with interoperability in ways that teams underestimate. You cannot share personal data across agencies just because it would be efficient. You need a lawful basis, a data sharing agreement, a data protection impact assessment, and often a legal opinion. I have seen projects where the technical integration was finished and tested before anyone confirmed the legal basis existed. The integration then sat idle for eight months.

Organisational interoperability is about agreeing on processes, responsibilities, and governance before you agree on APIs. Who owns the data? Who is the authoritative source? Who decides when a record changes? Who resolves conflicts? These questions sound administrative. They are actually the hardest questions in the project, because they redistribute power between organisations that have been operating independently for decades.

Semantic interoperability — shared meaning — is where the meeting I described earlier was stuck. Two systems can exchange a file perfectly and still disagree on what the data inside it means. Vocabularies, classifications, and reference data matter enormously in public sector contexts. The European Commission publishes controlled vocabularies and supports initiatives like ESCO for skills data and Europass for qualifications precisely because semantic alignment at scale requires shared infrastructure, not just goodwill.

Technical interoperability — APIs, data formats, protocols, security standards — is the layer that gets the most attention and is usually the least of the problem. Not because it is easy, but because it is the layer where the problem is most visible and where engineers have the most tools.

Three things that actually break interoperability projects

After working on integration programmes across multiple countries and sectors, I keep seeing the same failure patterns. They are not in the framework document.

Data quality is worse than anyone admits at the start

Every organisation believes its data is reasonably clean until it tries to share it. Then it discovers duplicates, missing mandatory fields, values that mean different things in different regional offices, and records that have not been updated since a system migration in 2009. Interoperability projects expose data quality problems that organisations have been hiding from themselves for years.

This is not a criticism. It is a structural reality. Systems built to serve internal processes do not need the same data discipline as systems built to share data externally. When you start sharing, the discipline requirement rises immediately. Budget for data cleansing. It will take longer than the integration work itself.

The authoritative source question is political, not technical

Every interoperability design eventually asks: when two systems have different values for the same thing, which one wins? The answer determines which agency has authority over that data domain. That is a political question inside government, and agencies fight over it — sometimes quietly, sometimes not. A project manager who treats this as a technical decision to be made by architects will hit a wall. It needs to be escalated, decided by someone with actual authority, and documented. Without that decision, integration designs go in circles.

Governance after go-live is almost never designed

The EIF and the Interoperable Europe Act both emphasise sustainability — the idea that interoperability is not a one-time achievement but an ongoing state that requires maintenance. In practice, projects design the integration and forget to design the governance that keeps it working. What happens when one agency changes its data model? Who approves changes to the shared API? Who monitors for failures? Who pays for upgrades when a dependency changes?

I have seen integrations that worked perfectly at launch and were effectively broken eighteen months later because one agency upgraded a system without telling the others, and no one had a process for coordinating that kind of change. The Interoperable Europe Act introduces peer reviews and the Interoperable Europe Board partly to address this at a European level. But inside a national programme, you have to design the governance yourself.

What I would do differently on the next interoperability project

Start with the legal and organisational layers, not the technical ones. I know this sounds obvious. It is still the most common mistake. Engineers are hired, APIs are designed, and the data sharing agreement is "in progress" for six months. Reverse that sequence. Confirm the legal basis first. Agree on ownership and governance before writing a line of integration code.

Run a data quality audit on both sides before designing the integration. Not after. The audit results will change your design, your timeline, and your budget. Better to know that in week three than in week twenty.

Name a data steward in each organisation and give them actual authority. Not a coordinator. Someone who can make decisions about data definitions and escalate conflicts. Interoperability projects need human connective tissue, not just technical connective tissue.

Design the post-launch governance as a deliverable, not an afterthought. Document who approves changes, who monitors the integration, and what the process is when something breaks. Make it part of the acceptance criteria for the project.

And use the frameworks — the EIF, the Interoperable Europe Act, the controlled vocabularies, the reference architectures. They exist because people made the same mistakes repeatedly and wrote them down. They are not bureaucracy. They are accumulated experience. Treat them that way.

Interoperability is one of those problems that looks solved when the first successful API call goes through. It is not solved. It is started. The real work is everything that keeps it working after the project team disbands. That is the part no framework can do for you.