Imagine an institution that adopted a platform years ago. It was fast to deploy, it solved the problem, and everyone was happy. Then one day a new law requires the institution to move its records to another system, or the vendor changes its pricing, or the product is simply discontinued.
Someone asks the question nobody asked at signing time: how do we get our data out?
In the private sector, a bad answer to that question is a costly migration. For a State, it's something heavier, because 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. It describes the principles I find most useful when designing this kind of platform, along with their real costs. We'll start by defining what "sovereignty" should mean in technical terms, then walk through five principles, then look at what all this 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.
Back in our imaginary institution, that's exactly where things went wrong: nobody had made the dependency explicit. So how do you design so that you can?
Principle 1: Technology Neutrality
The first defense is to describe 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.
But a single system rarely lives alone. What happens when many institutions need to talk to each other?
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.
Once institutions talk through contracts, the next question is about the data itself: who owns the truth?
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
This is the principle our imaginary institution missed. 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
You might conclude from all this that everything should live on infrastructure the State owns. That would be its own mistake, because 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):
| Class | Example | Typical implication |
|---|---|---|
| Public | Open data, catalogs | Can be published through open APIs |
| Internal | Operational data with no special risk | Public cloud with standard controls is viable |
| Sensitive | Personal and financial data | Reinforced controls, defined residency and encryption |
| Critical | Data with an impact on State security | Infrastructure under direct control with strict requirements |
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.
What It Costs
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
When a proposal lands on your desk, here is a short list I use to review it:
- Which open standards does it use for authentication, integration and data?
- Can we export all our data, in an open format, at any time?
- Where is the data stored and processed, and under which jurisdiction?
- Which components are replaceable and which aren't? How much would replacing them cost?
- What happens if the vendor changes prices or terms, or disappears?
- How is access to the data audited?
- 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.
Asking Before Signing
Go back to that institution one more time. If someone had asked those seven questions at signing time, the answer to "how do we get our data out?" would already be on paper, with a cost and a timeline attached.
That's the idea behind everything above:
- 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.
Top comments (0)