Part I of II – Exploring the Digital Sovereignty narrative

Digital sovereignty has moved from a political slogan to an enterprise constraint. Across the EU, it is shaping funding programs, procurement guidance, cloud strategies, and regulatory roadmaps. For chief architects and strategists, the problem is not whether the topic matters—it does. The problem is that the term is used inconsistently, often emotionally, and sometimes as a proxy for unrelated goals.

This post aims to make the discussion operational: define what we mean, clarify the perspectives in tension, and propose criteria we can use to evaluate initiatives and architectures.

Why the narrative is accelerating

Several forces have converged over the past few years:

Market concentration: hyperscalers deliver undeniable velocity, but also create dependency risk and asymmetry in negotiating power.
Geopolitics: sanctions, export controls, and “friend-shoring” dynamics have made technology supply chains part of diplomacy.
Fragile supply chains: COVID-era shortages and high-profile disruptions reminded leaders that “global” does not mean “reliable.”
Regulatory expectations: privacy, critical infrastructure, resilience, and sector-specific controls continue to tighten.

These forces are real. They justify action. But they do not automatically justify every “sovereignty” proposal currently attached to them.

A working definition that architects can use

For the remainder of this series, I use the following pragmatic definition:

Digital sovereignty is the ability of a state, organization, or individual to make informed choices about digital systems while maintaining effective control over critical risks and dependencies – including security, resilience, legal jurisdiction, portability, and the ability to change suppliers or solutions.

This definition avoids the trap of equating sovereignty with ownership or nationality. It focuses on measurable properties: control, choice, and credible exit options.

The three perspectives that must be reconciled

In practice, “digital sovereignty” often conflates at least three distinct lenses. Strategy fails when we optimize one while ignoring the others.

1) The state lens

From a policy standpoint, sovereignty is linked to authority, jurisdiction, and the ability to enforce rules within a territory. That lens naturally prioritizes:

regulatory control and enforcement capability
continuity of critical services
national security and strategic industry capacity

This is a legitimate set of concerns – but it is not the whole system.

2) The citizen lens

From an individual-rights standpoint, the emphasis shifts to autonomy and protection:

privacy and consent
transparency and accountability
freedom from coercive platforms or “forced adoption” patterns

This lens often clashes with state impulses for surveillance, centralized control, or “security at all costs.”

3) The enterprise lens

Enterprises operate across borders, suppliers, and regulatory regimes. For CIOs, COOs, and chief architects, sovereignty translates into:

dependency management (vendor lock-in, contractual power, switching costs)
compliance across jurisdictions
operational resilience (BCP/DR, security response, lifecycle management)
talent and capability constraints

In short: “sovereign” architectures must still be buildable, supportable, and economically defensible.

Where the narrative commonly breaks

Three failure modes show up repeatedly.

Failure mode 1: treating “sovereignty” as a brand rather than a set of criteria

Programs can become umbrellas for unrelated objectives. The result is ambiguity: different stakeholders push incompatible agendas under the same label, and success becomes impossible to measure.

Failure mode 2: equating sovereignty with protectionism

If the primary requirement becomes “local vendor” or “local ownership,” we may simply trade one dependency for another – while also incentivizing copycat fragmentation globally. Europe’s strength has long been openness and standards leadership; we should not dilute that advantage.

Failure mode 3: assuming technology alone will solve a political and economic problem

The narrative often over-focuses on infrastructure design as if a “European cloud” automatically produces resilience, autonomy, and trust. Real sovereignty outcomes require governance, procurement discipline, interoperability, operational capability, and incentives aligned across actors.

Criteria for evaluating “sovereignty” initiatives

To move from narrative to execution, I suggest evaluating any initiative, policy, program, architecture, or product – against a small set of criteria:

Portability and exit: Can we migrate workloads, data, and identities with bounded cost and time?
Interoperability and standards: Are interfaces open and implementable by multiple parties?
Transparency and auditability: Can we inspect controls, provenance, and security posture?
Resilience and continuity: Do we have credible operational continuity under stress?
Governance and incentives: Who controls the roadmap and decision rights – and are incentives aligned?
Compliance across jurisdictions: Is there a clear model for data residency, access, and legal exposure?

These criteria allow architects and policymakers to have a common conversation, and they let enterprises connect sovereignty to risk management rather than ideology.

A bridge to Part II

If we accept the above criteria, the next question becomes practical:

What operating model best creates portability, interoperability, transparency, and durable shared capability at scale?

This is where open source is frequently referenced – sometimes correctly, sometimes superficially. In Part II, I’ll argue that open source is not primarily “free code,” but a strategic framework that .when done properly – can produce sovereignty outcomes more reliably than territorial constraints.