Usually, the articles in this newsletter are about high-level enterprise architecture (EA) content, the EA function, or the architect role.
This time, let us do it a bit differently. I want to step down from the usual high-level view and talk about something much more practical. It is about control, technology dependencies, and how to keep things running when situations change.
This topic has become very real for me in a recent client project. We have been helping a public sector client to design a highly integrated system. In the project, we have to think about what digital sovereignty actually means in practice for this specific solution.
The big question is not just where the data is stored, where the service runs, or which country the service provider comes from. The more interesting question is actually this: What must stay strictly under the organization’s own control, and what happens if a critical dependency suddenly changes?
Lately, digital and technological sovereignty has been a big topic here in Finland. A large part of the discussion is about how dependent Europe is on US technology giants. People also talk about the risk that access to important technology could be restricted somehow. If you work in IT here, you have definitely heard about this.
In the US, the discussion is quite different. From what I understand, the main focus there is on China. The US government and companies are worried about relying on Chinese hardware and software—and also about Chinese actors getting access to their data.
But in both cases, sovereignty is about much more than just the nationality of the vendor. It is also not just about some hypothetical “kill switch” button somewhere on another continent.
And it is definitely not something you only think about when selecting a cloud service provider. Actually, this issue touches almost all technology purchases, big and small.
As an enterprise architect, you can face these exact same questions in a very concrete situation: when choosing an EA tool. Where is the data stored? Who can see it? Which laws apply? And what happens to all your models and metadata if you decide to change the tool later? An architecture repository can hold a comprehensive picture of your organization’s business, applications, technologies, data, and dependencies. Suddenly, even choosing an EA tool becomes a decision about sovereignty.
Why Digital Sovereignty Actually Matters?
The most serious sovereignty risks are geopolitical. In a worst-case scenario, an organization could lose access to a critical technology or service completely. Another risk is that foreign authorities get access to the organization’s data based on their local laws.
For critical public services and infrastructure, both of these scenarios deserve serious attention.
However, most dependency issues in daily life are much more ordinary. A provider might change their pricing or licensing models, discontinue a product, or the service quality just drops. Sometimes ownership changes, regulations shift, or accessing your own data becomes too dependent on the provider’s tools and support. These are real concerns in almost any technology purchase.
The architecture problem starts when enough dependencies accumulate that changing direction becomes practically impossible.
A system might depend on a single provider’s identity platform, proprietary data model, integration services, development tools, and operations—not to mention their specialists’ competence. Even if the organization legally owns the data, they might still depend entirely on the provider to access, export, or recover it.
Each individual choice probably made perfect sense at the time. But together, they can create a web of dependencies that the organization can no longer realistically control. At that point, the supplier relationship has become part of the architecture.
What Does Digital Sovereignty Mean for an Architect?
Digital sovereignty is one of those terms that starts sounding obvious after you have heard it often enough. Then someone asks what it actually means, and the room becomes suddenly quiet.
At the European level, technological sovereignty generally refers to the ability to act independently in the digital world by controlling important technologies, data, and infrastructure, and by reducing excessive dependencies.
An individual organization needs something more concrete. From an architecture perspective, I find two ideas particularly useful:
Verifiable control over critical digital assets and decisions.
The ability to keep acting when providers, technologies, regulations, or other dependencies change.
The word verifiable matters. A supplier presentation stating that the customer remains in control is not yet evidence of control. Neither is a contract clause that nobody has connected to the actual solution architecture.
Can the organization access its data independently? Who controls administrative identities, certificates, and encryption keys? Can the service be restored somewhere else? Can the organization continue operating if the supplier is unavailable? Who can update, suspend, or disable the service?
These are architecture questions, even when most of the answers are often found in contracts, operating procedures, security documentation, or procurement materials rather than architecture models.
Sovereignty also does not mean complete independence. Modern IT is built on specialization, external service providers, software ecosystems, and shared services. Trying to remove every dependency would be both expensive and unrealistic.
Otherwise, we would all be manufacturing our own processors and writing operating systems in the basement. That would certainly improve independence, along with a few other problems. The more realistic goal is controlled dependency.
What Does Digital Sovereignty Include?
There is no single feature that makes a solution sovereign. For architecture work, I find it more useful to look at a few practical dimensions. Their importance depends on the solution and its criticality.
Control and Decision Rights
Who actually controls the solution? This includes ownership and governance, but also administrative identities, encryption keys, certificates, domains, source code, configurations, and deployment mechanisms.
Can the provider make critical changes independently? Could ownership or control of the provider change? Can the customer still access and operate its critical assets without the provider?
Formal ownership is not enough if practical control remains elsewhere. Owning your data on paper while depending entirely on someone else to access it is not a very useful form of ownership.
Data and Technology Independence
Critical data must remain accessible, understandable, and transferable. This includes not only business records, but where relevant also metadata, configurations, access rules, logs, and audit histories.
Technology matters as well. Documented interfaces, standards, modular structures, and replaceable components improve independence. Proprietary services and configurations increase dependency.
This does not make provider-specific technology automatically bad. Lock-in can be a reasonable tradeoff. Accidental lock-in is less impressive.
Operational Sovereignty and Exitability
A solution can be portable on paper while the organization remains unable to operate or move it.
Does the organization have the documentation, skills, backups, recovery procedures, and alternative arrangements needed to continue without the current provider? Could another provider realistically take over?
Exitability asks a very concrete question: Could we actually change the provider or technology if we had to?
A contractual exit clause or an export button does not answer that. Interfaces, identity services, integrations, networks, and other shared dependencies may make the real exit much harder. Therefore, exitability cuts across familiar architecture qualities such as portability, interoperability, recoverability, maintainability, and resilience.
Jurisdiction and Supply Chain
The organization also needs to know which jurisdictions apply to the provider, its parent company, subcontractors, data, and operations. Which authorities may compel access to data or restrict a service?
Data-center location alone does not answer that. GDPR compliance does not make the jurisdiction question disappear either.
The direct provider is only one layer. For instance, an European supplier may depend on non-European infrastructure, software, or support. Provider nationality matters, but the whole dependency chain matters even more.
Security and Continuity of Control
Finally, sovereignty also concerns who controls security and continuity. Who can access logs, respond to incidents, apply critical patches, restore the environment, or revoke access?
Security and sovereignty overlap, but they are not the same thing. A secure service can still create a dependency that the customer cannot control.
The common thread across all these dimensions is therefore quite simple: who controls what, which dependencies matter, and how much ability the organization retains to act when circumstances change.
Great, Another Framework
The European Commission’s Cloud Sovereignty Framework provides a broad view on the topic, covering strategic, legal, data, operational, and other dimensions. It is a useful tool that shows sovereignty is more complex than just data center location or provider ownership. It offers a systematic way to analyze control and dependencies.
However, I would be careful not to put every desirable technology property under the title of sovereignty. Important topics like privacy, security, and sustainability have their own specific goals and methods. A solution can be secure but not sovereign, or environmentally friendly but difficult to replace.
When every positive quality is called sovereignty, the concept becomes too broad and starts to cover all of EA. It is better to use sovereignty frameworks as a source of questions and assessment criteria, not as a reason to rename every existing architecture concern.
What Should an Enterprise Architect Do?
Enterprise architects are unlikely to negotiate every supplier clause, configure encryption keys, or write migration scripts. Their role is rather to make important dependencies visible and ensure they are considered in decisions.
A useful starting point is the existing architecture. Which critical capabilities depend on which applications and platforms? Which providers are behind them? Where do several critical capabilities depend on the same company, identity service, cloud platform, or infrastructure component? What would happen if one of those dependencies disappeared or changed substantially?
Existing EA content can provide much of the needed structure. They can reveal concentrations and dependencies that are difficult to see from individual projects—assuming, of course, that the organization has invested in keeping it comprehensive and reasonably up to date.
There is no need to build a separate sovereignty repository containing thousands of new elements. A dependency view, a few additional attributes, and perhaps a heatmap may be much more useful.
For example, applications or platforms could be assessed based on criticality, provider concentration, applicable jurisdiction, data portability, technology portability or operational dependency. Exitability could then be visualized directly on an application map, for example with a simple heatmap.
Architecture principles can also turn the topic into something actionable. For example:
Critical capabilities should have a level of technological independence proportionate to their business impact.
Important provider-specific dependencies should be visible and consciously accepted.
Critical data and configurations should be accessible in a usable form.
Jurisdiction and supply-chain dependencies should be considered in important technology choices.
Exit costs, duration, and operational impact should be understood before committing to strategic platforms.
High-impact recovery or exit arrangements should be tested when appropriate.
The exact requirements naturally depend on the organization and solution. A small internal survey tool does not need the same level of sovereignty as a payment platform, healthcare system, or national infrastructure service. Maximum sovereignty everywhere would be enormously expensive and probably counterproductive.
Some dependencies are perfectly acceptable. Some need safeguards. A few may be important enough to avoid altogether. The architect’s job is to help tell the difference.
Sovereignty as an Architecture Quality
For enterprise architects, digital sovereignty can seem like a new topic. It looks like it comes from regulation, geopolitics, and procurement. In practice, a lot of it is already familiar.
Architecture has always been about structures and how things depend on each other. We already check qualities like resilience, interoperability, portability, security, ownership, lifecycle, risks, and criticality. Sovereignty gives us a new reason to look at these same structures. It also adds a few more questions about control, laws, and depending on outside help.
So, it is more useful to see sovereignty as a quality or a capability of the architecture. It is not just a box to check in a procurement paper.
A part of it is technical.
A part is about operations.
A part is about the organization.
A part is about contracts and laws.
None of these views is enough alone.
The goal is not to buy everything from Europe. The goal is also not to build a digital fortress that is cut off from the world. From my European view, it is a good idea to have fewer critical dependencies. It can also be good to use great global technologies, if the dependency is understood and acceptable.
The goal is to protect the organization’s power to act. And a good, practical test for that is exitability.
If it is possible in theory to change a critical provider, but nobody knows how long it will take or how much it will cost, there is a problem. If nobody knows what data will be left, or if work can continue, then the organization has less control than it probably thinks it has.
🔗 You May Also Like
Are you looking to dive deeper? Here are some related articles you might find useful:
👨💻 About the Author
Eetu Niemi is an enterprise architect, consultant, and author.
Follow him elsewhere: Homepage | LinkedIn | Substack (expert work) | Medium (writing) | Homepage (FI) | Facebook | Instagram
Books: Enterprise Architecture | The Senior Expert Career Playbook | The Senior Expert Pay Playbook | Technology Consultant Fast Track | Successful Technology Consulting | Kokonaisarkkitehtuuri (FI) | Pohjoisen tie (FI) | Little Cthulhu’s Breakfast Time
Web resources: Enterprise Architecture Info Package (FI)
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports strategy, change, and delivery.