A Sovereignty Transformation Has Five Dimensions. Open Source Covers One

Picture the start of a typical sovereignty program. There is a mandate from the board. A budget has been approved. A shortlist of open source platforms sits on the table. The team discusses architecture, explores data residency requirements, and leaves the kickoff feeling like the work has begun.

Three years on, the platform is running. The governance framework is still a draft. Staff trained on cloud-native tooling are deploying into an ecosystem still structurally dependent on the original vendor. The data residency policy sits in a document that has not changed a single underlying dependency.

Will every digital sovereignty strategy go wrong at first?

I’ve been close enough to Lean, DevOps, and Cloud Native to watch the same pattern unfold each time.

When Lean arrived in software organizations, people bought whiteboards and ran stand-ups. When DevOps emerged, teams deployed CI/CD pipelines (continuous integration and delivery toolchains) and called themselves DevOps engineers. When Cloud Native appeared, organizations stood up Kubernetes clusters and declared the job done. In every case, early adopters confused the tools with the transformation.

The organizations that actually succeeded did something different. They built a capability. 

• Lean had its Black Belts: trained practitioners who understood waste elimination as an organizational discipline, not a manufacturing technique. 
• DevOps had its coaches, embedded in teams to change how work flowed, not just which tools ran it. 
• Cloud Native generated Site Reliability Engineers (SREs) whose function was to bridge architecture decisions with operational reality and developer experience.

In each case, a new class of professionals emerged whose job was to hold the whole transformation in their head, not just one piece of it. The tools were necessary. The change leadership was what made them stick.

Sovereignty has five dimensions: technology is only one of them

This is where I see most organizations getting sovereignty wrong.

When I ask a technology leader what their sovereignty strategy is, I usually get an answer about infrastructure: open source platforms, on-premise deployments, European cloud providers. Architecture comes up. Data residency comes up often. But governance and workforce capability? Almost never. And when data residency does come up, it tends to sit in isolation, disconnected from the architecture, contracts, and vendor dependencies that actually determine whether those policies have any practical effect.

But digital sovereignty is not an architecture decision. It is a sovereignty framework consisting of  five interdependent dimensions that only work when all five are moving together.

• Governance without the others produces compliance documentation but not operational resilience. You can map your dependencies. You cannot resolve them.
• Architecture without the others builds portable infrastructure that the organization lacks the skills to operate, the contracts to protect, and the governance to sustain.
• Ecosystem without the others renegotiates vendor terms while the underlying architecture remains locked and the workforce cannot support alternative suppliers.
• Workforce without the others trains people on cloud-native technologies they cannot deploy, because the architecture, contracts, and governance frameworks are not yet in place.
• Data without the others creates residency policies and classification frameworks that have no practical effect on the structural dependencies that actually determine data control. It is the dimension most organizations know they need to address. It is also the one most often treated as a standalone workstream rather than as part of a coordinated transformation.

Open source technology sits at the heart of a sovereignty architecture, and SUSE, trusted by more than 60% of the Fortune 500 for mission-critical infrastructure, has spent more than 30 years building the open source foundation that makes this possible. 

But open source addresses one dimension, not five. Organizations that treat it as the whole answer will build something fragile: a technically sound stack sitting on top of governance gaps, workforce shortfalls, and unresolved vendor dependencies. At that point, sovereignty becomes a marketing claim, not an operational reality.

The role that doesn’t exist yet, but needs to

Here is what I think is missing from many sovereignty programs: a dedicated Sovereignty Transformation Lead.

Not a procurement decision-maker. Not an infrastructure architect. Someone who understands all five dimensions and can hold them in tension. Someone who speaks the board’s language on governance and regulatory risk, the engineering team’s language on architecture, and the HR function’s language on capability gaps, treating the whole thing as a change management program, not a technology project.

The lesson from every generation of transformation, from Lean to DevOps to Cloud Native, is consistent: the tools rarely fail. The change leadership fails. Black Belts, Agile coaches, SREs. Each of these roles emerged because organizations discovered that a transformation this cross-functional does not succeed without someone whose job it is to hold the whole thing together.

Sovereignty is at the same inflection point. The organizations ahead right now are not the ones with the most advanced architecture. They are the ones that have appointed someone to own the full transformation, with the mandate, the skills, and the seniority to drive all five dimensions in parallel.

This is not a new idea. It is a very old one, applied to a new problem.

The window is open. For now.

I make this argument not from theory but from the conversations I have every week with organizations who are in the midst of sovereignty journey: organizations that built one dimension well and are now held back by the other four.

The pattern from Lean, DevOps, and Cloud Native offers something encouraging: organizations that invest early in transformation leadership consistently emerge with structural advantages that are very hard for late movers to close. Not because they had better tools. Because they built better capabilities, and the capabilities outlasted any individual platform decision.

Digital sovereignty is the next generation-defining transformation for technology organizations.

LinkedIn outputs

Imagine a year into a sovereignty program the platform running is, but governance framework is still a draft. I have seen this pattern before. Three times, actually. Lean. DevOps. Cloud Native. Each time, the technology delivered. The transformation didn’t. Those are two very different outcomes.

Sovereignty is heading the same way. And I think most leaders seriously underestimate what they are signing up for.

The scope of the problem is bigger than most programs are built to handle. Digital sovereignty is not a platform decision. It covers five dimensions that all depend on each other: Governance, Architecture, Ecosystem, Workforce, and Data. Tackle one and the others will eventually undo it.

Data residency comes up in almost every conversation I have with customers. Almost always as a standalone compliance task. Disconnected from the architecture choices and vendor dependencies that actually determine whether those policies hold in practice.

Lean only worked where organizations invested in Black Belts. DevOps required real SRE and Agile coaching commitments. Cloud Native needed dedicated platform engineering teams.

Sovereignty is no different. SUSE’s open source foundation gives you a strong Architecture base. That still leaves four dimensions most organizations have not even mapped a program around yet. I rarely see that person in the room.

The question is not which platform you are running. It is whether you have someone capable of leading the whole change.

Read more on the SUSE Blog

What is your experience: are sovereignty programs stalling because of the technology gap, or the change leadership gap?

#DigitalSovereignty #OpenSource #SUSE #EnterpriseIT #CloudNative