Digitale Souveränität

Wie digitale Souveränität entsteht

Digitale Souveränität ist keine Eigenschaft eines einzelnen Produkts.
Sie entsteht aus den Handlungsmöglichkeiten, die innerhalb eines digitalen Systems erhalten bleiben.
Eine Organisation kann beispielsweise einen externen Dienst nutzen und trotzdem weitgehend selbstbestimmt handeln.
Umgekehrt kann sie sämtliche Server selbst betreiben und trotzdem stark von einzelnen Technologien oder Personen abhängig sein.

Die entscheidende Frage lautet deshalb nicht:

„Betreiben wir alles selbst?“

Sondern:

„Welche Entscheidungen können wir selbst treffen, und welche realistischen Möglichkeiten besitzen wir, wenn sich Bedingungen ändern?“

Abhängigkeit ist zunächst normal

Praktisch kein digitales System ist vollständig unabhängig.

Ein selbst betriebener Server hängt beispielsweise ab von:

• Hardware
• Betriebssystem
• Softwarepaketen
• Bibliotheken
• Netzwerkzugängen
• DNS
• Zertifikaten
• Standards
• Dokumentation
• verfügbarem Fachwissen

Auch Open-Source-Software beseitigt diese Abhängigkeiten nicht.
Das Ziel digitaler Souveränität kann deshalb nicht darin bestehen, sämtliche Abhängigkeiten zu vermeiden.

Interessanter ist:

Welche Abhängigkeiten bestehen?
        ↓
Wie kritisch sind sie?
        ↓
Wie gut verstehen wir sie?
        ↓
Welche Alternativen besitzen wir?
        ↓
Was geschieht, wenn sich eine Abhängigkeit verändert?

Abhängigkeiten werden damit zu einer Eigenschaft des Systems, die untersucht und gestaltet werden kann.

Nicht jede Abhängigkeit ist gleich problematisch

Eine Anwendung verwendet beispielsweise eine kleine externe Bibliothek.
Eine andere Anwendung speichert sämtliche geschäftskritischen Daten in einem proprietären Cloud-Dienst ohne vollständige Exportmöglichkeit.
Beides sind technische Abhängigkeiten.
Ihre Auswirkungen unterscheiden sich jedoch erheblich.

Für die Bewertung können beispielsweise relevant sein:

• Bedeutung der abhängigen Funktion
• Austauschbarkeit
• verfügbare Alternativen
• Datenportabilität
• dokumentierte Schnittstellen
• notwendiges Fachwissen
• Migrationsaufwand
• Kosten eines Wechsels
• Dauer eines Wechsels
• Folgen eines Ausfalls
• rechtliche oder vertragliche Bedingungen

Digitale Souveränität ist deshalb keine einfache Zählung von Abhängigkeiten.

Kontrolle über Daten

Daten sind häufig ein wesentlicher Bestandteil digitaler Handlungsfähigkeit.
Dabei reicht es nicht immer aus, dass ein Anbieter eine Exportfunktion besitzt.
Relevant ist auch, was tatsächlich exportiert werden kann.

Ein Export könnte beispielsweise enthalten:

Kundendaten
Dokumente

aber nicht:

Beziehungen zwischen Datensätzen
Konfigurationen
Berechtigungen
Versionshistorie
Metadaten
Automatisierungsregeln

Formal existiert dann ein Datenexport.
Eine vollständige Migration des Systems kann trotzdem schwierig sein.
Datenportabilität muss deshalb im Zusammenhang mit der tatsächlichen Bedeutung und Struktur der Daten betrachtet werden.

Offene Datenformate

Offene und dokumentierte Datenformate können einen Wechsel erleichtern.
Eine Datei in einem bekannten Format kann häufig auch von anderer Software verarbeitet werden.
Ein proprietäres Format ist dagegen möglicherweise nur mit einer bestimmten Anwendung vollständig nutzbar.

Aber auch hier gilt:

Offen bedeutet nicht automatisch problemlos austauschbar.

Zwei Systeme können dasselbe offene Format unterstützen und trotzdem unterschiedliche Teilmengen, Erweiterungen oder Interpretationen verwenden.
Ein offenes Format verbessert mögliche Handlungsoptionen.
Es ersetzt nicht die Prüfung, ob eine konkrete Migration tatsächlich funktioniert.

Schnittstellen schaffen Handlungsmöglichkeiten

Dokumentierte Schnittstellen können Systeme voneinander entkoppeln.
Wenn eine Anwendung über eine klar definierte Schnittstelle mit einem externen Dienst kommuniziert, kann es möglich sein, diesen Dienst später durch einen anderen zu ersetzen.
Dafür muss allerdings bekannt sein, welche Eigenschaften tatsächlich benötigt werden.

Aus:

Anwendung → Dienst A

kann nicht automatisch:

Anwendung → Dienst B

werden, nur weil beide eine API besitzen.

Entscheidend sind unter anderem:

• Datenmodelle
• Semantik
• unterstützte Funktionen
• Fehlerverhalten
• Authentifizierung
• Leistungsmerkmale
• Betriebsbedingungen

Eine gut verstandene Schnittstelle kann Abhängigkeiten begrenzen.
Sie beseitigt sie nicht.

Open Source und digitale Souveränität

Open-Source-Software kann digitale Souveränität erheblich unterstützen.

Der verfügbare Quellcode kann beispielsweise ermöglichen:

• Funktionsweise zu untersuchen
• Software selbst zu betreiben
• Fehler unabhängig vom Hersteller zu analysieren
• Anpassungen vorzunehmen
• andere Dienstleister einzubeziehen
• eine Software bei Bedarf weiterzuentwickeln

Diese Möglichkeiten reduzieren bestimmte Formen der Herstellerabhängigkeit.
Sie garantieren jedoch keine vollständige Unabhängigkeit.
Ein großes Open-Source-System kann beispielsweise so komplex sein, dass eine Organisation praktisch nur einen einzelnen Dienstleister besitzt, der es ausreichend versteht.
Der Quellcode ist dann offen.
Die tatsächliche Handlungsfähigkeit kann trotzdem begrenzt sein.

Self-Hosting ist eine Möglichkeit, kein Selbstzweck

Ein System selbst zu betreiben kann zusätzliche Kontrolle schaffen.
Daten und Konfigurationen befinden sich unter eigener Kontrolle.
Updates können möglicherweise selbst geplant werden.
Betriebsentscheidungen hängen weniger unmittelbar von einem SaaS-Anbieter ab.

Dafür entstehen andere Abhängigkeiten:

eigene Infrastruktur
Administration
Updates
Monitoring
Backups
Sicherheitsmaßnahmen
Fachwissen

Self-Hosting tauscht deshalb häufig eine Form von Abhängigkeit gegen andere Formen.
Ob dieser Tausch sinnvoll ist, hängt vom jeweiligen System ab.

Exit-Fähigkeit

Ein besonders praktischer Blick auf digitale Souveränität ist die Frage:

„Können wir hier wieder heraus?“

Ein System besitzt eine hohe Exit-Fähigkeit, wenn ein Wechsel realistisch vorbereitet oder zumindest möglich ist.

Dazu können beispielsweise gehören:

• vollständige Datenexporte
• dokumentierte Formate
• dokumentierte Schnittstellen
• bekannte Abhängigkeiten
• alternative Komponenten
• verfügbare Betriebsdokumentation
• reproduzierbare Konfigurationen
• kontrollierte Migrationsverfahren

Eine Exit-Strategie bedeutet nicht, dass ein Anbieterwechsel geplant ist.
Sie bedeutet, dass ein Wechsel nicht erst dann untersucht werden muss, wenn er plötzlich notwendig geworden ist.

Theoretische und praktische Unabhängigkeit

Eine wichtige Unterscheidung besteht zwischen theoretischer und praktischer Austauschbarkeit.
Angenommen, eine Software ist vollständig Open Source.
Theoretisch kann sie unabhängig weiterentwickelt werden.

Dafür werden jedoch benötigt:

20 Entwickler
spezialisiertes Fachwissen
mehrere Jahre Einarbeitung
erhebliche Infrastruktur

Für eine kleine Organisation ist diese Möglichkeit möglicherweise praktisch bedeutungslos.
Umgekehrt kann ein proprietärer Dienst sehr gut dokumentierte Schnittstellen, vollständige Exporte und mehrere kompatible Alternativen besitzen.
Seine praktische Austauschbarkeit kann dann höher sein.
Digitale Souveränität sollte deshalb reale Handlungsmöglichkeiten betrachten und nicht ausschließlich formale Eigenschaften.

Wissen ist Teil der Souveränität

Ein System kann technisch vollständig unter eigener Kontrolle stehen und trotzdem von einer einzigen Person abhängen.

Wenn nur diese Person weiß:

wie das System aufgebaut ist
warum bestimmte Entscheidungen getroffen wurden
wie Backups wiederhergestellt werden
welche Abhängigkeiten existieren
wie ein System ersetzt werden könnte

entsteht eine erhebliche Abhängigkeit.
Dokumentation, nachvollziehbare Architektur und verteiltes Wissen können deshalb ebenfalls Bestandteile digitaler Souveränität sein.
Technische Kontrolle ohne ausreichendes Verständnis schafft nur begrenzte Handlungsfähigkeit.

Souveränität kostet ebenfalls etwas

Mehr Unabhängigkeit ist nicht kostenlos.
Eigener Betrieb kann Arbeitszeit benötigen.
Alternative Systeme müssen geprüft werden.
Offene Schnittstellen müssen gepflegt werden.
Migrationen müssen vorbereitet werden.
Wissen muss dokumentiert und erhalten werden.
Deshalb ist nicht für jedes System der maximal mögliche Grad an Unabhängigkeit sinnvoll.
Bei einem unkritischen Dienst kann eine starke Anbieterabhängigkeit akzeptabel sein.
Bei einem System, von dem wesentliche Geschäftsprozesse abhängen, kann dieselbe Abhängigkeit problematisch sein.

Die Frage lautet deshalb nicht:

„Wie werden wir maximal unabhängig?“

Sondern:

„Wie viel Handlungsfähigkeit benötigen wir für dieses System?“

Digitale Souveränität und Resilienz

Digitale Souveränität und Resilienz überschneiden sich, beschreiben aber unterschiedliche Eigenschaften.

Resilienz fragt beispielsweise:

„Kann das System mit einer Störung umgehen?“

Digitale Souveränität fragt zusätzlich:

„Welche Handlungsmöglichkeiten besitzen wir, wenn sich eine Abhängigkeit dauerhaft verändert?“

Ein externer Dienst kann beispielsweise technisch hochverfügbar sein.
Wenn dessen Anbieter jedoch die Preise verzehnfacht oder eine benötigte Funktion einstellt, hilft reine technische Fehlertoleranz nur begrenzt.
Eine vorhandene Alternative oder realistische Migrationsmöglichkeit erweitert dagegen die eigenen Handlungsmöglichkeiten.

Souveränität ist kein Zustand für immer

Auch digitale Souveränität kann sich verändern.
Ein zunächst austauschbarer Dienst kann immer stärker in andere Systeme integriert werden.
Datenmengen können wachsen.
Eigene Kenntnisse können verloren gehen.
Eine Alternative kann eingestellt werden.
Ein ehemals offenes Format kann durch proprietäre Erweiterungen praktisch schwer austauschbar werden.

Damit kann aus:

leicht austauschbare Komponente

über mehrere Jahre unbemerkt:

zentrale schwer ersetzbare Abhängigkeit

werden.

Digitale Souveränität muss deshalb ebenfalls im tatsächlichen Systemzustand betrachtet werden und nicht nur bei der ursprünglichen Produktauswahl.

Warum digitale Souveränität praktische Auswirkungen hat

• Abhängigkeiten werden sichtbar: Nicht nur Anbieter, sondern auch Daten, Schnittstellen, Wissen und Betriebsbedingungen werden betrachtet.
• Exit-Möglichkeiten können vorbereitet werden: Ein Wechsel muss nicht erst unter Zeitdruck untersucht werden.
• Datenportabilität wird praktisch bewertet: Ein vorhandener Export ist nicht automatisch eine brauchbare Migration.
• Open Source wird als Werkzeug verstanden: Offener Quellcode kann Handlungsmöglichkeiten schaffen, ist aber kein Selbstzweck.
• Self-Hosting wird abgewogen: Mehr Kontrolle wird gegen zusätzliche eigene Verantwortung gestellt.
• Wissen wird als Abhängigkeit erkannt: Technische Kontrolle allein reicht nicht.
• Kritische und unkritische Abhängigkeiten können unterschieden werden: Nicht jede Abhängigkeit benötigt dieselbe Behandlung.
• Abhängigkeiten können erneut bewertet werden: Eine ursprünglich akzeptable Abhängigkeit kann mit der Zeit problematisch werden.

Typisches Beispiel

Ein Unternehmen verwendet einen externen Dienst für eine zentrale Geschäftsfunktion.
Der Dienst funktioniert zuverlässig und ist wirtschaftlich attraktiv.

Eine Analyse zeigt:

Datenexport:
vollständig vorhanden

Datenformat:
dokumentiert

API:
dokumentiert

Alternative Anbieter:
mehrere vorhanden

Migration:
in Testumgebung erfolgreich erprobt

geschätzte Umstellungszeit:
drei Tage

Das Unternehmen ist weiterhin von einem externen Anbieter abhängig.
Es besitzt aber reale Handlungsmöglichkeiten, falls sich die Bedingungen verändern.
Ein anderes Unternehmen betreibt dieselbe Funktion auf einem eigenen Server.
Die Software ist Open Source.
Allerdings kennt nur ein ehemaliger Mitarbeiter die Konfiguration, Backups wurden nie zurückgespielt und das verwendete Datenformat wurde nie untersucht.
Formal besitzt das zweite Unternehmen mehr technische Kontrolle.
Praktisch kann seine Handlungsfähigkeit trotzdem geringer sein.

Abgrenzung

• Digitale Souveränität beschreibt die Fähigkeit, über digitale Systeme und ihre Abhängigkeiten selbstbestimmt entscheiden und bei Veränderungen handlungsfähig bleiben zu können.
• Digitale Autarkie würde wesentlich weitergehende Unabhängigkeit von externen Ressourcen oder Akteuren bedeuten. Sie ist für digitale Souveränität nicht erforderlich.
• Open Source bezeichnet Software, deren Lizenz unter anderem die Nutzung, Einsicht in den Quellcode, Veränderung und Weitergabe unter den jeweiligen Lizenzbedingungen erlaubt. Open Source kann digitale Souveränität unterstützen, ist aber nicht mit ihr identisch.
• Self-Hosting bezeichnet den eigenen Betrieb eines Dienstes oder Systems. Es kann Kontrolle erhöhen, erzeugt aber eigene technische und organisatorische Abhängigkeiten.
• Resilienz beschreibt die Fähigkeit eines Systems, wesentliche Funktionen unter Störungen und Veränderungen zu erhalten, wiederherzustellen oder angepasst fortzuführen.
• Legacy-Modernisierung kann digitale Souveränität verbessern, wenn dabei schwer kontrollierbare Abhängigkeiten reduziert oder besser beherrschbar gemacht werden.

Weiterführend

Verwandte Begriffe

→ Systemanalyse
→ Systemarchitektur
→ Systemintegration
→ Schnittstelle
→ Legacy-System
→ Legacy-Modernisierung
→ Resilienz
→ Self-Hosting
→ Offenes Datenformat