Every public agency was created to solve a specific problem, with its own logic, its own system, and its own data language. The cumulative result, after decades, is a government that feels to citizens like an archipelago: each procedure is an island, and to get from one island to the next, you have to navigate your way with photocopies, certificates, and affidavits.
Interoperability is essential for the government to function as a single entity. When one agency is cut off from another’s data, it duplicates records, asks citizens for information that is already in the public domain, and ends up making decisions based on information that is inferior to what the government itself possesses.
The government's silo trap
Silos emerge by default. Each institution built its own system when it needed to, using the technology available at the time, assuming that it was enough to address its own needs. Twenty years later, what was a sound local decision in each case has become a systemic problem: the government loses the ability to see the whole picture at once.
And the costs are borne by the public. The parent applying for child support who has to submit the death certificate that the Civil Registry has already issued. The small business that has to repeat the same information at five different counters. The social welfare program that fails to identify eligible beneficiaries because it relies on a database that no one has cross-referenced with the tax agency’s database.
Whole-of-Government: A Single Service Approach
Whole-of-Government (WoG) is, above all, a shift in approach. It means designing policies, processes, and systems that view the citizen as a single entity in relation to the entire government. The guiding principle is brutally simple: the government reuses the data it already has.
WoG involves decisions that go beyond IT: agreements between agencies, legal frameworks for sharing data, common governance, and a political leader who understands where the solution lies — in building common rules for all systems, rather than adding one more.
Public APIs: The Common Language of the State
APIs are the technical component that makes the WoG operational. A well-designed API allows one agency to retrieve data from another without having to copy it, without asking citizens to submit it, and without having to build custom integrations each time. It is the stable contract that enables two systems to evolve independently without breaking.
A public API in the government relies on versioning, documentation, authentication, access control, traceability, monitoring, and SLAs. When managed properly, it becomes an institutional asset: a capability that survives changes in leadership and can be reused in every new public policy that requires it.
What Makes a Good Public API
- Contract stability: consumers can be confident that any changes will be compatible or announced well in advance.
- Living documentation: open, navigable, and always in sync with the actual implementation.
- Clear identities and permissions: who accesses what, for what purpose, and with what level of access.
- Full traceability: every query is logged, auditable, and reversible.
- 24/7 Operations: including monitoring, usage metrics, and incident response.
Data shared with governance
Sharing data between organizations requires deciding what data circulates, with whom, for what purpose, and under what conditions. Without governance, interoperability becomes a vulnerability: sensitive information circulating without clear rules, without traceability, and without the possibility of reviewing its use.
Data governance in the State rests on three layers: a legal layer that defines what can be shared and under what legal basis; a technical layer that implements those limits in the systems; and an institutional layer that monitors compliance and resolves disputes. All three are indispensable and mutually reinforcing.
The “one-time” principle
The international standard for digital government (the Once-Only Principle) stipulates that citizens and businesses should only have to submit each piece of data to the government once. It is a principle that is simple to state but challenging to implement: it requires reliable records, unique identification, stable APIs, and the political will for the entire government to adhere to the rule—even when a particular agency would prefer to continue requesting paper documents.
Interoperability as an institutional decision
|rawInteroperability is decided in the political and legal arena before it reaches the technical level. Sharing data means relinquishing control, being subject to audits, and accepting that one's own database is part of the state's common heritage. The software component is only implemented once the institutional dialogue has defined the rules of engagement.
That is why interoperability requires political leadership, legal frameworks, and an architecture that combines common platforms—service catalogs, master registries, and digital citizen identity—with the autonomy of agencies to develop their own systems. The way forward is federation with common rules: each institution preserves what makes it unique while connecting under a shared language.
Why does this matter?
Because an integrated government has a direct impact on citizens’ lives: fewer bureaucratic procedures, less time wasted, better-targeted programs, reduced fraud, and public policy based on real data. Every step toward integration unlocks institutional capacity that has already been funded through the public budget but currently lies dormant within silos.
At Sofis, we have been working for years on concrete interoperability projects: social protection systems that cross-reference data between ministries, shared registries between pension agencies, and platforms that expose auditable APIs to those with the legitimacy to use them. Integration is built decision by decision, one API at a time, in each system designed with this approach from the outset.