Digital Sovereignty

How Digital Sovereignty Arises

Digital Sovereignty is not a property of a single product.
It arises from the options for action that remain available within a digital system.
An organization can, for example, use an external service and still act largely autonomously.
Conversely, it can operate all servers itself and still be heavily dependent on individual technologies or people.

The decisive question is therefore not:

“Do we operate everything ourselves?”

But:

“Which decisions can we make ourselves, and what realistic options do we have if conditions change?”

Dependency Is Initially Normal

Practically no digital system is completely independent.

A self-operated server, for example, depends on:

• hardware
• operating system
• software packages
• libraries
• network access
• DNS
• certificates
• standards
• documentation
• available expertise

Open Source software does not eliminate these dependencies either.
The goal of Digital Sovereignty therefore cannot be to avoid all dependencies.

More interesting is:

Which dependencies exist?
        ↓
How critical are they?
        ↓
How well do we understand them?
        ↓
What alternatives do we have?
        ↓
What happens if a dependency changes?

Dependencies thus become a property of the system that can be examined and designed.

Not Every Dependency Is Equally Problematic

One application uses a small external library.
Another application stores all business-critical data in a proprietary cloud service without a complete export option.
Both are technical dependencies.
Their effects, however, differ considerably.

For the evaluation, the following can be relevant, for example:

• importance of the dependent function
• replaceability
• available alternatives
• data portability
• documented interfaces
• required expertise
• migration effort
• cost of switching
• duration of switching
• consequences of an outage
• legal or contractual conditions

Digital Sovereignty is therefore not a simple count of dependencies.

Control Over Data

Data is often an essential part of digital agency.
It is not always sufficient that a provider has an export function.
What is also relevant is what can actually be exported.

An export could, for example, contain:

customer data
documents

but not:

relationships between records
configurations
permissions
version history
metadata
automation rules

Formally, a data export then exists.
A complete migration of the system can nevertheless be difficult.
Data portability must therefore be considered in relation to the actual meaning and structure of the data.

Open Data Formats

Open and documented data formats can make switching easier.
A file in a known format can often also be processed by other software.
A proprietary format, by contrast, may only be fully usable with a particular application.

But here too:

Open does not automatically mean easily interchangeable.

Two systems can support the same open format and still use different subsets, extensions, or interpretations.
An open format improves possible options for action.
It does not replace checking whether a specific migration actually works.

Interfaces Create Options for Action

Documented interfaces can decouple systems from one another.
If an application communicates with an external service through a clearly defined interface, it may be possible to replace that service with another one later.
However, it must be known which properties are actually required.

From:

Application → Service A

it does not automatically become:

Application → Service B

just because both have an API.

Relevant factors include:

• data models
• semantics
• supported functions
• error behavior
• authentication
• performance characteristics
• operating conditions

A well-understood interface can limit dependencies.
It does not eliminate them.

Open Source and Digital Sovereignty

Open Source software can significantly support Digital Sovereignty.

Available source code can, for example, make it possible to:

• examine how the software works
• operate the software yourself
• analyze errors independently of the vendor
• make modifications
• involve other service providers
• continue developing software if necessary

These possibilities reduce certain forms of vendor dependency.
However, they do not guarantee complete independence.
A large Open Source system can, for example, be so complex that an organization effectively has only a single service provider that understands it sufficiently.
The source code is then open.
The actual ability to act can nevertheless be limited.

Self-Hosting Is an Option, Not an End in Itself

Operating a system yourself can provide additional control.
Data and configurations are under your own control.
Updates may be scheduled independently.
Operational decisions depend less directly on a SaaS provider.

In return, other dependencies arise:

own infrastructure
administration
updates
monitoring
backups
security measures
expertise

Self-Hosting therefore often exchanges one form of dependency for other forms.
Whether this exchange makes sense depends on the particular system.

Exit Capability

A particularly practical way of looking at Digital Sovereignty is the question:

“Can we get out of this again?”

A system has high exit capability if a switch is realistically prepared or at least possible.

This can include, for example:

• complete data exports
• documented formats
• documented interfaces
• known dependencies
• alternative components
• available operational documentation
• reproducible configurations
• controlled migration procedures

An exit strategy does not mean that a change of provider is planned.
It means that a switch does not first have to be investigated when it has suddenly become necessary.

Theoretical and Practical Independence

An important distinction exists between theoretical and practical replaceability.
Suppose software is completely Open Source.
In theory, it can be developed further independently.

However, this requires:

20 developers
specialized expertise
several years of familiarization
substantial infrastructure

For a small organization, this possibility may be practically meaningless.
Conversely, a proprietary service can have very well-documented interfaces, complete exports, and several compatible alternatives.
Its practical replaceability can then be higher.
Digital Sovereignty should therefore consider real options for action and not exclusively formal properties.

Knowledge Is Part of Sovereignty

A system can technically be completely under an organization’s own control and still depend on a single person.

If only this person knows:

how the system is structured
why certain decisions were made
how backups are restored
which dependencies exist
how a system could be replaced

a significant dependency arises.
Documentation, traceable architecture, and distributed knowledge can therefore also be components of Digital Sovereignty.
Technical control without sufficient understanding creates only limited ability to act.

Sovereignty Also Has a Cost

Greater independence is not free.
Operating systems yourself can require working time.
Alternative systems must be evaluated.
Open interfaces must be maintained.
Migrations must be prepared.
Knowledge must be documented and preserved.
The maximum possible degree of independence is therefore not sensible for every system.
For a non-critical service, strong vendor dependency can be acceptable.
For a system on which essential business processes depend, the same dependency can be problematic.

The question is therefore not:

“How do we become maximally independent?”

But:

“How much ability to act do we need for this system?”

Digital Sovereignty and Resilience

Digital Sovereignty and Resilience overlap, but describe different properties.

Resilience asks, for example:

“Can the system cope with a disruption?”

Digital Sovereignty additionally asks:

“What options for action do we have if a dependency changes permanently?”

An external service can, for example, be technically highly available.
However, if its provider increases prices tenfold or discontinues a required function, pure technical Fault Tolerance is of limited help.
An available alternative or realistic migration option, by contrast, expands the organization’s own options for action.

Sovereignty Is Not a Permanent State

Digital Sovereignty can also change.
A service that is initially replaceable can become increasingly integrated into other systems.
Data volumes can grow.
Internal expertise can be lost.
An alternative can be discontinued.
A formerly open format can become difficult to replace in practice because of proprietary extensions.

Thus:

easily replaceable component

can, unnoticed over several years, become:

central dependency that is difficult to replace

Digital Sovereignty must therefore also be considered in the actual system state and not only during the original product selection.

Why Digital Sovereignty Has Practical Effects

• Dependencies become visible: Not only providers, but also data, interfaces, knowledge, and operating conditions are considered.
• Exit options can be prepared: A switch does not have to be investigated only under time pressure.
• Data portability is evaluated in practical terms: An available export is not automatically a usable migration.
• Open Source is understood as a tool: Open source code can create options for action, but is not an end in itself.
• Self-Hosting is weighed: Greater control is balanced against additional internal responsibility.
• Knowledge is recognized as a dependency: Technical control alone is not enough.
• Critical and non-critical dependencies can be distinguished: Not every dependency requires the same treatment.
• Dependencies can be reevaluated: A dependency that was originally acceptable can become problematic over time.

Typical Example

A company uses an external service for a central business function.
The service works reliably and is economically attractive.

An analysis shows:

Data export:
fully available

Data format:
documented

API:
documented

Alternative providers:
several available

Migration:
successfully tested in a test environment

estimated migration time:
three days

The company remains dependent on an external provider.
But it has real options for action if conditions change.
Another company operates the same function on its own server.
The software is Open Source.
However, only a former employee knows the configuration, backups have never been restored, and the data format used has never been examined.
Formally, the second company has more technical control.
In practice, however, its ability to act can still be lower.

Distinction

• Digital Sovereignty describes the ability to make autonomous decisions about digital systems and their dependencies and to remain capable of acting when conditions change.
• Digital Autarky would mean substantially greater independence from external resources or actors. It is not required for Digital Sovereignty.
• Open Source refers to software whose license permits, among other things, use, inspection of the source code, modification, and redistribution under the respective license conditions. Open Source can support Digital Sovereignty, but is not identical to it.
• Self-Hosting refers to operating a service or system yourself. It can increase control, but creates its own technical and organizational dependencies.
• Resilience describes the ability of a system to maintain, restore, or adaptively continue essential functions under disruptions and changes.
• Legacy Modernization can improve Digital Sovereignty if dependencies that are difficult to control are reduced or made more manageable.

Further Reading

Related Concepts

→ Systems Analysis
→ System Architecture
→ System Integration
→ Interface
→ Legacy System
→ Legacy Modernization
→ Resilience
→ Self-Hosting
→ Open Data Format