"Digital sovereignty" is one of those phrases that means very different things depending on who's saying it. To a regulator, it might mean keeping data inside national borders. To a CTO, it might mean not being held hostage by a single vendor. To a security architect, it might mean maintaining the ability to operate even if a key supplier disappears. In this InfoQ article, Jakob Beckmann, Principal Architect at Innovation Process Technology (ipt AG), argues that all of these views are partially right — and the practical question is not "are we sovereign?" but "for which systems, to what degree, and how do we get there?"
His answer: lean on open standards and design portability in as a first-class architectural property — but only where it matters, because trying to be sovereign about everything is a recipe for paralysis.
Sovereignty as a Choice, Not a Binary
The article's first move is to dispense with the myth that any organization or country can be fully digitally sovereign. Modern technology is layered: the chips come from a handful of fabs, the operating systems from a handful of vendors, the protocols from a handful of standards bodies, the cloud regions from a handful of providers. At each layer there are dependencies you cannot eliminate without rebuilding the entire stack — which no one has the time, money, or expertise to do.
So sovereignty has to be reframed:
- Sovereignty is a matter of degree, not a binary state.
- Sovereignty is a choice you make about specific systems, not a posture you adopt across the entire stack.
- The goal is having viable alternatives ("Plan B"), not eliminating dependencies entirely.
This is a useful, pragmatic frame. It moves the conversation from ideology to engineering.
The Four Axes of Sovereignty
Beckmann breaks the broad concept into four concrete axes, which makes it possible to reason about each separately:
- Data sovereignty. Who has legal control of the data? Where can it live, who can be compelled to disclose it, and under whose laws?
- Technological sovereignty. Can you use, modify, or develop the technologies you depend on without external permission?
- Operational sovereignty. Can you operate, change, and run your systems independently — or are you tethered to a vendor's roadmap and uptime?
- IT governance and strategy. Who actually decides what you build, where, and how?
Most "sovereignty" conversations conflate these. Splitting them apart lets you target investment where it matters. You may need strong data sovereignty for customer records, technological sovereignty for your core platform, and accept dependency for your CRM.
Portability as the Insurance Policy
The mechanism that makes choice-based sovereignty practical is portability — the ability to move a workload from one platform, vendor, or region to another without rebuilding it from scratch. Portability is your insurance policy. It doesn't eliminate dependency on a vendor; it makes leaving them feasible if you ever need to.
A few key implications:
- Apply portability selectively. Trying to make every system portable is enormously expensive. Reserve it for systems where vendor lock-in is an existential risk: revenue-critical platforms, regulated workloads, anything you can't tolerate losing.
- Treat "exit ramps" as first-class non-functional requirements. During design, ask explicitly: how would we move off this if we had to? If the answer is "rewrite from scratch," you've already made a sovereignty decision — possibly without realizing it.
- Beware accidental lock-in. Convenience features (proprietary databases, vendor-specific APIs, managed services with no equivalent elsewhere) accumulate silently. Each one makes leaving slightly harder. Architectural discipline is the only defense.
Open Standards Are the Building Blocks
If portability is the strategy, open standards are the tactic. Beckmann highlights specific examples that have become broadly portable across vendors and clouds:
- Kubernetes for orchestration — the same workload runs on AWS, Azure, GCP, on-prem, or sovereign clouds with relatively modest changes.
- PostgreSQL for relational storage — supported by every major cloud as a managed offering, and trivially self-hostable.
- Kafka for event streaming — multiple vendors, multiple managed offerings, well-known migration paths.
The pattern is consistent: pick technologies whose APIs and operational semantics are standardized across multiple vendors. You still get the benefit of managed services — somebody else runs it for you — but you keep the option to switch.
The contrast is illuminating. A workload built on a major cloud's proprietary serverless platform may be wonderfully productive, but moving it to another cloud is essentially a rewrite. A workload built on Kubernetes plus PostgreSQL plus Kafka is not maximally efficient on any single cloud, but it's portable to all of them. That's the trade-off Beckmann is asking architects to make consciously.
Practical Architecture Patterns
The article calls out a few concrete disciplines that turn sovereignty from aspiration into practice:
- Open APIs and standardized data formats. Avoid proprietary formats for anything you'd ever need to migrate.
- Abstract over vendor-specific services. Where you must use a managed feature, hide it behind an interface that could plausibly be implemented elsewhere.
- Hybrid-friendly architectures. Design with the assumption that some workloads may need to move between clouds, on-prem, or sovereign regions over time.
- Document the exit strategy. A literal artifact: for each critical system, write down what it would take to migrate off the current platform. Update it during architecture reviews.
When Sovereignty Suddenly Matters
The article underscores why this isn't theoretical:
- Vendor pricing changes. A SaaS or cloud provider quadruples prices. Without a Plan B, you absorb the cost — possibly indefinitely.
- Service discontinuations. Vendors deprecate or sunset services. If you've built around them, you've inherited a forced migration.
- Geopolitical disruption. Sanctions or sudden loss of access to foreign vendors. Organizations affected by recent geopolitical events have learned that "we'll figure it out later" doesn't work when the deadline is days, not quarters.
- Regulatory shifts. New data-localization laws can make existing replication topologies non-compliant overnight.
In every one of these scenarios, the question isn't whether you have full sovereignty — it's whether you have a credible Plan B. Architectures designed around portability survive these events. Architectures that aren't, don't.
Final Takeaways
Beckmann's article is a useful corrective to two common positions: the maximalist "we must build everything ourselves" stance that paralyzes organizations, and the laissez-faire "we'll just use what's convenient" stance that quietly accumulates strategic risk.
The middle path the article advocates:
- Accept that absolute sovereignty is unattainable — and stop letting that be an excuse for ignoring the question.
- Identify which systems genuinely require sovereignty along which axes (data, technology, operations, governance).
- Use open standards like Kubernetes, PostgreSQL, and Kafka as the substrate for those systems.
- Make portability a first-class non-functional requirement. Design exit ramps; document migration plans; resist accidental lock-in.
- Treat sovereignty as long-term operational flexibility, not a political talking point.
The deepest insight is that sovereignty and pragmatism aren't in tension. A well-designed portable architecture lets you choose your vendors and managed services freely — because you could leave them if you had to. That optionality is the real prize.
Reference: Architecting Portable Systems on Open Standards for Digital Sovereignty