Introducing SODA as a practical model for digital sovereignty
Visibility Is Not Yet a Decision
In the first article in this series, we argued that digital sovereignty should not be reduced to a choice between two extremes. Full digital autonomy is unrealistic for most organizations, while simply accepting the status quo leaves important dependencies unexamined. A more useful middle ground is to understand those dependencies, place them in context, and make deliberate trade-offs.
The second article distinguished three dimensions of sovereignty: data, operational, and technical. That distinction matters because a discussion about data residency is not the same as a discussion about who can recover a service, and neither is the same as a discussion about long-term vendor lock-in. The relative importance of each dimension differs by workload.
The third article explained why those discussions still tend to stall. Dependencies are fragmented across architecture, contracts, identity, operations, support, licensing, data flows, suppliers, and individual expertise. Until they are made visible and validated, sovereignty decisions rest on assumptions rather than evidence.
But visibility alone is not a decision. A dependency map may show what an organization relies on, yet it does not determine whether that dependency is acceptable. Leaders still need to decide how much control is required, whether the service can be operated under pressure, how difficult replacement would be, and which legal authorities can ultimately affect it.
That is the purpose of SODA: a structured way to translate that visibility into requirements, assessments, trade-offs, and accountable decisions.
SODA does not tell organizations to eliminate dependencies. It helps them decide which dependencies are acceptable, which require safeguards, and which must be reduced.
Digital Sovereignty as a Non-Functional Requirement
Digital sovereignty is best treated as a non-functional requirement. Non-functional requirements describe the conditions under which a system must operate rather than the business function it performs. Security, availability, performance, maintainability, and compliance are familiar examples. Sovereignty belongs in the same category because it sets requirements around control, operation, resilience, dependency, and jurisdiction.
This framing changes the conversation. Instead of asking whether an application is sovereign, leadership and delivery teams can ask what level of sovereignty the workload requires. A public marketing website does not need the same controls as a patient record system, a payment platform, or a government identity service. A highly innovative digital product may consciously accept more platform dependency in exchange for speed and differentiation. A critical public service may require stronger legal control, operational continuity, and credible alternatives.
Sovereignty is therefore not a binary property. It behaves like other quality attributes: it can be strengthened, tested, and balanced against cost, speed, convenience, resilience, and access to innovation. More is not automatically better, because every additional control can introduce expense and complexity.
Sovereignty is not something every system must maximize. It is something every critical system should specify.
Introducing the SODA Model
SODA assesses a workload through four complementary lenses: Sovereign Control, Operational Independence, Dependency, and Authority and Jurisdiction. Together they create a practical profile of the control an organization needs to retain and the dependencies it is willing to accept.
S — Sovereign Control
Sovereign Control asks who ultimately controls the system and the decisions around it. It covers control over infrastructure and configuration, identities and administrative privileges, encryption keys, the data lifecycle, and the ability to grant or revoke access. It also asks whether a third party can suspend, restrict, or materially change the service without the organization being able to intervene.
Typical questions include:
Can the organization revoke all external access?
Who controls administrative privileges and encryption keys?
Can a third party suspend or restrict the service?
Does the organization control how its data is retained, moved, and deleted?
Strong control does not necessarily mean owning every component. A service operated by an external provider may still offer meaningful sovereign control when roles, access boundaries, keys, logs, decision rights, and contractual protections are clear and enforceable.
O — Operational Independence
Operational Independence asks whether the organization can continue to run, recover, and change the service. It concerns the practical ability to act when a provider, support team, or key individual is unavailable. Skills, documentation, tooling, privileged access, backup and recovery, incident investigation, update control, and tested continuity arrangements all matter.
Typical questions include:
Can we restore the service without the primary vendor?
Do we have the skills, access, tooling, and documentation to operate it?
Can critical operations continue if external support becomes unavailable?
Have recovery and continuity arrangements been tested in practice?
This lens prevents organizations from confusing ownership with capability. An on-premises system can have weak operational independence when it relies on one supplier or a few scarce specialists. A cloud workload can have stronger operational independence when access, automation, recovery, knowledge, and escalation paths have been designed and tested deliberately.
D — Dependency
Dependency asks how replaceable a component, supplier, platform, or capability really is. It brings vendor lock-in, proprietary services, ecosystem concentration, scarce knowledge, and migration effort into the same discussion. The relevant question is not whether dependency exists, but whether its consequences are understood and acceptable.
Typical questions include:
Is there a credible alternative supplier or technology?
Which proprietary APIs, formats, or services make replacement difficult?
How long would replacement realistically take, and how much effort would it require?
Could the business continue if the supplier stopped serving us?
Avoiding every proprietary capability is rarely a sound strategy. Platform-specific services can deliver significant speed, reliability, and innovation. The decision becomes responsible when the benefit is explicit, the exit implications are understood, and ownership of the remaining risk is clear.
A — Authority and Jurisdiction
Authority and Jurisdiction asks under whose legal and institutional authority the service operates. It includes the legal entities providing and supporting the service, applicable law, data and processing locations, subcontractors, extraterritorial legislation, access to metadata and management environments, and the ability to demonstrate contractual and technical safeguards.
Typical questions include:
Which legal entity provides the service?
Which jurisdictions can compel the provider to disclose or restrict access?
Where are data, metadata, logs, and backups stored and processed?
Which technical and contractual protections can be demonstrated?
This is why data located in Europe is not automatically under exclusively European authority. Physical location is relevant, but it does not by itself answer who can access the service, which company controls the supporting systems, or which law can compel that company to act.
How SODA Relates to the Three Sovereignty Dimensions
SODA does not replace the three dimensions introduced earlier in this series. The three dimensions describe where sovereignty risk manifests. SODA provides four lenses for translating that risk into assessable requirements and decisions.
The model deliberately makes Dependency explicit. Two workloads may look technically similar yet have very different risk profiles because one has credible alternatives and transferable skills while the other depends on a unique provider, proprietary services, and knowledge held by a small external team.
From Questions to Scores, Without False Precision
A five-point scale can help teams compare the required and current position for each SODA lens. The scale is not a scientific measurement, a compliance certificate, or a maturity ranking. Its value lies in forcing assumptions into the open and requiring people from business, technology, operations, security, legal, risk, and procurement to explain the evidence behind their judgement.
Every score should be accompanied by evidence, known uncertainties, realistic scenarios, business consequences, and a named risk owner. A low score is not automatically a problem. A score of two may be perfectly acceptable for a low-impact service. A score of four may still be insufficient for a system whose disruption would threaten public safety or critical operations.
The objective is not to achieve a perfect SODA score. The objective is to achieve a profile that matches the workload.
Define the Required Profile Before Assessing the Current One
Organizations often begin by rating the current platform. That risks turning the existing architecture into the reference point. A better sequence is to define the workload's required profile first, based on business criticality, data sensitivity, regulatory obligations, downtime impact, strategic relevance, and risk appetite. Only then should the current situation be assessed.
The gap between the required and current score makes the decision actionable. Consider a critical customer service with the following illustrative profile:
This profile does not lead to a blanket verdict that the workload is or is not sovereign. It shows where the design meets its requirements and where targeted action is needed. It also prevents organizations from maximizing every score regardless of cost or business value.
Apply SODA One Workload at a Time
A universal sovereignty policy is likely to produce either excessive cost or false comfort. SODA should therefore be applied to a concrete workload, business process, or critical service. A practical assessment follows seven steps:
1. Select the workload. Choose a clearly bounded application, service, or business process.
2. Establish the context. Determine business criticality, data sensitivity, regulation, downtime impact, stakeholders, and risk tolerance.
3. Map the dependencies. Include hosting, data, identity, network, logging, support, keys, licenses, integrations, subcontractors, and specialist knowledge.
4. Define the required SODA profile. Specify the level of control, independence, replaceability, and jurisdictional assurance the workload needs.
5. Assess the current profile. Score the actual situation using evidence rather than architectural labels, provider claims, or contract headlines.
6. Test realistic scenarios. Explore service discontinuation, acquisition, restricted support, regulatory evidence requests, sanctions, or a required exit within a defined period.
7. Decide and assign ownership. Accept, monitor, mitigate, or eliminate or replace the dependency, with an owner and review date.
The result should be a decision statement rather than a generic label. For example: the workload meets its authority and control requirements, but operational recovery remains too dependent on the primary supplier. That gap must be mitigated within three months, with the service owner accountable for testing the new recovery arrangement.
Sovereignty Is a Trade-off, Not a Free Upgrade
The SODA lenses make tensions explicit. Greater Sovereign Control can require additional governance and more expensive service models. Stronger Operational Independence demands skills, tooling, documentation, exercises, and sometimes duplicated capabilities. Reducing Dependency can limit the use of proprietary services that deliver genuine innovation and productivity. Stronger jurisdictional safeguards may narrow the supplier landscape or complicate international operations.
These costs do not invalidate sovereignty requirements. They make prioritization necessary. An organization can deliberately accept a lower score when the impact is limited, the business benefit is substantial, alternatives exist, and the residual risk has an accountable owner. Conversely, a dependency may require action even when replacement is expensive if its potential impact exceeds the organization's tolerance.
A dependency becomes a governance problem when it is invisible, misunderstood, or ownerless, not simply because it exists.
Turn Every Material Dependency into a Decision
A SODA assessment should lead each material dependency to one of four treatments:
Accept. The dependency fits the required profile, and its value justifies the residual risk.
Monitor. It is acceptable today, but changes in ownership, law, cost, technology, or geopolitics could alter that conclusion.
Mitigate. Additional measures are needed, such as customer-controlled keys, stronger access boundaries, contractual safeguards, open data formats, internal skills, alternative recovery capability, or a tested exit plan.
Eliminate or replace. The dependency is incompatible with the required profile and cannot be reduced sufficiently through safeguards.
This is the point where dependency visibility becomes governance. The organization is no longer discussing whether a supplier, cloud model, or technology is sovereign in the abstract. It is deciding which specific dependencies can be tolerated, what evidence is required, which controls must be added, and who owns the outcome.
Make SODA Part of Existing Governance
SODA should not become a separate compliance exercise. Its value increases when required profiles and decisions are integrated into existing architecture reviews, cloud and SaaS selection, vendor due diligence, procurement, contract renewal, risk assessment, business continuity planning, and application portfolio management.
Like other non-functional requirements, a SODA profile is not permanent. It should be revisited when a supplier changes ownership, legislation evolves, the architecture changes materially, business criticality increases, a contract is renewed, or an incident disproves an important assumption. The profile creates a common reference point for determining whether those changes remain within the organization's accepted boundaries.
Conscious Dependency Is the Goal
This series began by rejecting the false choice between full autonomy and passive acceptance. The three dimensions of sovereignty then gave organizations a clearer language for different kinds of risk. Dependency mapping replaced assumptions with evidence. SODA completes the journey by translating that evidence into workload-specific requirements, gaps, measures, and ownership.
Digital sovereignty does not require organizations to withdraw from global technology ecosystems. It requires them to participate with their eyes open. The goal is not independence at any cost, but conscious dependency: knowing what the organization relies on, understanding the consequences, deciding what level of control is required, and accepting or changing the remaining risk deliberately.
SODA provides a practical structure for doing that: one workload, one decision, and one accountable owner at a time.
Sovereignty is not the absence of dependency. It is the ability to make deliberate decisions about dependency.
Bert Ertman
A frequent speaker on Java, Cloud, and software architecture all over the world. Book author, and serial conference organizer.
