Data Sovereignty and Open Architecture in Government Platforms: Design Principles

Designing digital platforms for the State comes with a constraint that barely exists in the private sector: today's technical decisions shape the sovereignty and room to maneuver of institutions for decades.

I worked on the architecture of cross-cutting systems of the Dominican State. This article doesn't describe specific systems, but the principles I find most useful when designing this kind of platform, along with their real costs.

What I Mean by "Data Sovereignty"

It's not a slogan or a single technical requirement. It's the ability to answer "yes" to these questions:

• Do we know where the data lives and under which jurisdiction?
• Can we take out our data and migrate it to another solution without the vendor's permission or disproportionate cost?
• Can we replace one component without rewriting the rest?
• Who decides who accesses what, and is there an auditable record?

If the answer to any of them is "it depends on the vendor", there is a dependency worth making explicit.

Principle 1: Technology Neutrality

A neutral design describes what the system must do and under which contracts, not which product does it. Examples:

• Specify "authentication via OpenID Connect" instead of "use product X".
• Specify "S3-compatible object storage" instead of tying yourself to a specific service.
• Require open formats for exchanged data.

Neutrality doesn't mean avoiding commercial products. It means that the product is replaceable because the contract is a standard.

Principle 2: Interoperability by Contract, Not by Shared Database

In an ecosystem with many institutions, the temptation is to integrate by "reading the other's database directly". It's quick, and it's a trap:

• It couples systems to each institution's internal schema.
• It prevents each one from evolving its system.
• It makes it impossible to audit who consumes what.

The alternative is API-first: each institution exposes versioned contracts (for example, with OpenAPI), documented and access-controlled. The internal schema stays private and can change without breaking anyone.

Principle 3: The Source of Truth Is Single and Identified

When the same piece of data (a person, a territory, a company) lives copied across ten systems, inconsistencies appear. Every critical piece of data should have:

• A custodian institution responsible for its quality.
• A source of truth queryable via API.
• A clear copy policy: what can be replicated, how often and how it is synchronized.

This reduces duplication and makes it clear who is accountable when a piece of data is wrong.

Principle 4: Exit Strategy from Day One

Before adopting any solution, ask: how do I get out of it?

• Is data exported in complete, open formats?
• Are the integration contracts standard or proprietary?
• Is there a copy of the code, or access to it, if the vendor disappears?
• How much would it cost, and how long would it take, to migrate?

The answer doesn't have to be "free and fast". It has to be estimated before signing, not after.

Principle 5: Classify Data Before Deciding Where It Lives

Not all data demands the same level of control. A simple classification helps avoid both excess (everything on owned infrastructure, at an unmanageable cost) and shortfall (everything on the public cloud without analysis):

The specific classification is defined by each institution's legal framework and policy. What matters is that it exists and is applied before choosing the infrastructure.

The Real Trade-offs

An open, sovereign design is not free, and it's worth saying so:

• More upfront design work. Defining contracts, standards and boundaries takes time that a "turnkey" solution avoids.
• Possibly slower delivery at first. Integration by contract takes longer than the shared-database shortcut.
• More operational responsibility. If you control more, you operate more. You need internal or contracted technical capacity.
• Standards maintenance costs. Versioning contracts and maintaining documentation is continuous work.

The benefit shows up in the medium and long term: less dependency, better negotiating power and the ability to evolve without starting over.

Questions for Evaluating Any Solution

A short list I use when reviewing proposals:

1. Which open standards does it use for authentication, integration and data?
2. Can we export all our data, in an open format, at any time?
3. Where is the data stored and processed, and under which jurisdiction?
4. Which components are replaceable and which aren't? How much would replacing them cost?
5. What happens if the vendor changes prices or terms, or disappears?
6. How is access to the data audited?
7. What is the operating model and who sustains it?

If a proposal can't answer these questions, that's a sign the dependency is hidden.

Conclusion

• Data sovereignty is achieved through concrete architectural decisions, not declarations.
• Open, versioned contracts are the foundation of interoperability and of the ability to change vendors.
• The exit strategy is designed before adopting a solution, not after.
• An open design costs more at the start and protects more in the long run. That decision should be made consciously.

If you work on public platforms or long-lived systems, I'd like to know which principles have worked for you and which ones you've had to adjust.