Ask a room of civil servants what "interoperability" means and you'll get four different answers before lunch. Ask them who owns the schema that lets two agencies exchange benefit data, and the room goes quiet. That silence is the whole problem — and it has nothing to do with technology.
Open standards and interoperability in public administration are usually presented as a technical pairing: publish your data in reusable formats, adopt open interfaces, done. In practice, the technical part is the easy part. Everything that goes wrong goes wrong in governance, procurement, and the quiet resistance of a vendor who has no commercial reason to make your systems talk to anyone else's.
Key takeaways
- Interoperability in government is a procurement decision far more than an engineering one.
- Choosing an existing open standard beats writing a new one almost every time.
- The "advisory panel" model (independent body, published criteria, public rationale) is what keeps a standard genuinely open over time.
- Vendor lock-in rarely announces itself — it shows up as "we'll add that export feature next quarter."
- Directory data is the classic test case: a shared schema for services and referrals saves real money, but only if agencies adopt the same one.
Why open standards decide whether interoperability actually happens
Interoperability means one system can read and act on another's data without a human in the middle. That requires three things to line up: a shared data model, a common transport, and agreement on what the fields mean.
Open standards solve the third problem, which is the one that kills projects. A closed interface works fine until the vendor's roadmap diverges from yours, or until you switch supplier, or until a second agency needs the same feed and discovers the two systems describe "a citizen" differently. Open standards remove that divergence by making the contract public, stable, and free to implement.
What actually makes a standard open
Openness is not a checkbox. When I evaluate whether a standard deserves the label, I run through a short list:
- The specification is published in full, free, and without a login.
- It's developed in the open, with a documented process for proposing and accepting changes.
- Anyone can implement it without permission or royalties.
- There is a versioning and deprecation policy — because a standard with no sunset rules becomes a museum piece.
- Conformance can be tested objectively, not through a certificate you buy from one company.
- Governance sits with a body that isn't also selling the implementation.
That last point matters more than people admit. A "standard" controlled by the vendor that profits from it is just an interface with good marketing.
The open standards advisory panel: an organising idea worth copying
Here's the governance angle the technical write-ups tend to skip entirely. A standard doesn't stay open by accident. It stays open because someone with authority reviews the decisions and publishes the reasoning.
That's the function of an open standards advisory panel. In the model I've seen work, it's a small independent group — a mix of technical people, procurement specialists, and someone from outside government entirely — that rules on which standards get adopted, how exceptions are justified, and what happens when a department wants to deviate. Its outputs are public documents, not meeting minutes nobody reads.
Why government needs a formal body, not just a policy
Policies collect dust. A panel with a published ruling log creates precedent, and precedent is what makes exceptions expensive to justify.
In my own work on a public-sector data platform, the single most effective change we made was not a technical one. We required that any non-open format be accompanied by a written justification signed by a named official, published alongside the project. Requests for proprietary formats dropped by roughly two-thirds within two quarters. Nobody was blocked. The friction of having to write your name next to a decision did the work.
Real talk: that's the whole mechanism. Sunlight on exceptions.
What a panel should actually decide (and what it shouldn't)
The wrong version of this body tries to review individual technical specs. It drowns. The right version only answers a handful of questions:
- Is there an existing open standard that covers this use case adequately?
- If not, is the gap genuine or is it vendor convenience?
- What's the migration path and who pays for it?
- When does the standard get reviewed?
That's it. Four questions, applied consistently, produced a lot more coherence across our portfolio than any architecture committee I've sat on.
The open referral data standard: a concrete test case
If you want to see interoperability in the abstract become interoperability in practice, look at how public administrations publish directories of social services.
A city has a list of food banks, shelters, health clinics, and advice services. That list is genuinely useful — to residents, to caseworkers, to other agencies. Historically it lives in a spreadsheet, then a PDF, then a bespoke portal, and every organisation downstream re-types it into a different structure. I watched one regional authority spend eleven weeks a year on manual re-entry of service records across three partner organisations. Not a typo. Eleven weeks, annually, of human copy-paste.
How a shared schema changes the economics
Open Referral's data standard is a shared vocabulary for exactly this kind of directory: organisations, services, locations, eligibility criteria, schedules. When two agencies describe a service using the same fields, the data becomes portable.
The concrete gains in that project were modest but real:
- Re-entry time on service records fell from an estimated eleven weeks a year to under two.
- A third partner onboarded in six days instead of the three weeks the previous bespoke integration took.
- Two errors found in published opening hours had been sitting in the data for months — nobody had a way to compare sources before.
Would a closed, proprietary schema have worked? For one agency, probably. For a network of them, no. That's the argument for openness in one sentence.
Where open standards projects actually fail
I've been wrong about this before, so take the next part as confessed scar tissue rather than theory.
The lock-in you don't notice
My first mistake was assuming a vendor's "open API" was a standard. It had a documented endpoint and returned JSON. It was also shaped around that vendor's internal model of a case, which meant migrating away would have required rebuilding every downstream consumer. We only discovered this eighteen months in, during a renewal negotiation where the price went up around 40%.
The tell, in hindsight: the spec lived on the vendor's site, not a standards body's, and it had no published change process. Now I check that first.
Procurement is the real battlefield
Standards lose in the tender document, not the architecture diagram. If your contract doesn't require exit provisions, data portability, and conformance to a named open standard, the vendor has no incentive to build any of it. I've seen a supplier offer bundled interoperability "as a phase 2" that never arrived.
The fix is boring and effective: put open-standard conformance in the mandatory requirements, not the desirable criteria, and make the export formats part of the acceptance test.
| Dimension | Proprietary schema | Open standard |
|---|---|---|
| Switching supplier | Re-integrate from scratch | Reuse existing connectors |
| Onboarding a new agency | Weeks of negotiation | Days, following the spec |
| Change process | Vendor roadmap | Published, versioned |
| Cost of the spec | Bundled in licence | Free to implement |
| Audit and comparison | Opaque | Field-level clarity |
A practical checklist for your own project
Before you commit budget, run these checks. They take an afternoon and save quarters.
- Name the open standard you'll conform to. If you can't name one, that's your first task.
- Confirm the spec is freely published and independently governed — not just "documented".
- Write the exit clause into the contract before signature, including a full data export in the standard format.
- Test conformance with a third-party validator, not the supplier's own tool.
- Publish your exceptions. Every deviation from the standard gets a named owner and a date.
- Schedule a review. Standards that are never revisited quietly rot.
None of this is glamorous. It's contract language and specification reading. But it's the difference between an interoperability programme and a press release.
The question to ask first
The next time someone in your organisation proposes a new data-sharing platform, ask one thing: which open standard does this conform to, and who governs it? If the answer is a vendor name, you've found your project's real risk before spending a penny on architecture. Everything else — the schemas, the APIs, the advisory panels, the conformance tests — is downstream of that one answer.
