Data Sovereignty ist jetzt eine Architekturfrage

Wie ich aufgehört habe, Souveränität für ein juristisches Problem zu halten

Ich erinnere mich an Gespräche, in denen 'Data Sovereignty' ungefähr so behandelt wurde wie eine Steuererklärung: unangenehm, notwendig, aber letztlich Sache der Rechtsabteilung.

Das war bequem. Und falsch. ERP Today hat das kürzlich auf den Punkt gebracht: Datensouveränität ist heute keine Frage des Serverstandorts mehr. Sie umfasst, wer die Workloads betreibt, welche Technologieabhängigkeiten entstehen, und welche rechtlichen Konsequenzen sich daraus ergeben. Das ist keine Compliance-Checkbox. Das ist eine Architekturentscheidung.

Was Souveränität heute wirklich bedeutet

Der klassische Reflex lautet: Daten in Deutschland speichern, fertig. Das greift zu kurz. Laut ERP Today umfasst Datensouveränität inzwischen fünf Dimensionen: die Kontrolle über die Daten selbst, über die Workloads, über den Betreiber der Infrastruktur, über Technologieabhängigkeiten und über die rechtlichen Auswirkungen des Gesamtarrangements.

Das klingt nach einer Liste für einen Workshop-Nachmittag. Ist es aber nicht. Denn diese fünf Dimensionen widersprechen sich in der Praxis regelmäßig. Wer die günstigste Hyperscaler-Option wählt, erkauft sich operative Effizienz auf Kosten der Betreiberunabhängigkeit. Wer auf einen europäischen Anbieter setzt, löst das Betreiberproblem — und bekommt dafür möglicherweise Technologieabhängigkeiten, die genauso schwer wiegen. Es gibt kein Setup, das alle fünf Dimensionen gleichzeitig optimiert. Das ist die unbequeme Wahrheit.

• •

  Datenkontrolle: Wer kann auf die Daten zugreifen, auch ohne explizite Freigabe?

• •

  Workload-Kontrolle: Können Prozesse jederzeit auf andere Infrastruktur verlagert werden?

• •

  Betreiberunabhängigkeit: Welche Rechte hat der Anbieter im Streitfall?

• •

  Technologieabhängigkeit: Wie tief ist die Plattformbindung durch proprietäre APIs oder Formate?

• •

  Rechtliche Auswirkungen: Welche Jurisdiktion gilt, wenn es ernst wird?

Warum das SAP-Umfeld besonders betroffen ist

Für viele DACH-Unternehmen ist SAP die zentrale Datenplattform — und damit der Ort, an dem Souveränitätsfragen am schärfsten werden. Die Migration in die SAP Business Technology Platform oder in S/4HANA Cloud ist keine rein technische Entscheidung. Sie ist eine Entscheidung darüber, welche der fünf Souveränitätsdimensionen man bereit ist, teilweise abzugeben.

Das ist nicht automatisch falsch. Aber es muss eine bewusste Entscheidung sein, keine implizite. Wer in die Public Cloud migriert, ohne vorher zu klären, welche Daten dort landen und unter welchen Bedingungen, der trifft die Entscheidung trotzdem — nur ohne es zu merken. Und das ist der Punkt, an dem Architekten ins Spiel kommen müssen, bevor der Vertrag unterschrieben ist, nicht danach.

Hinzu kommt: SAP-Systeme sind selten allein. Sie sind eingebettet in ein Ökosystem aus Middleware, Drittsystemen und Schnittstellen. Jede dieser Verbindungen ist ein potenzieller Souveränitätsleck. Wer das Gesamtbild nicht kennt, kann die Einzelteile nicht bewerten.

Was das für Governance-Entscheidungen bedeutet

Governance-Frameworks in DACH-Unternehmen sind oft historisch gewachsen. Sie regeln, wer Datenzugriff bekommt, wie Daten klassifiziert werden, und was im Audit-Fall dokumentiert sein muss. Was sie selten regeln: die Architekturdimension von Souveränität. Also die Frage, welche Technologieentscheidungen überhaupt erst in den Governance-Prozess müssen — und welche still und leise an der Governance vorbeilaufen.

Das ist eine strukturelle Lücke. Sie lässt sich schließen, aber nicht mit einem neuen Policy-Dokument. Sie lässt sich schließen, indem Architektur-Reviews explizit Souveränitätskriterien enthalten. Konkret: Jede neue Plattformentscheidung, jede Schnittstelle zu einem Drittanbieter, jede Cloud-Erweiterung sollte gegen die fünf Dimensionen geprüft werden — nicht als Bürokratie, sondern als Risikobewertung.

Wer das systematisch macht, merkt schnell, dass viele Entscheidungen bisher implizit getroffen wurden. Das ist keine Kritik an den Menschen, die sie getroffen haben. Es fehlte der Rahmen. Den jetzt nachzuziehen ist keine Schwäche — es ist überfällig.

Drei Einstiegspunkte für Architekten und IT-Leiter

Wer jetzt anfangen will, ohne ein Großprojekt aufzumachen, kann mit drei konkreten Schritten starten. Sie sind nicht spektakulär. Aber sie schaffen Klarheit, bevor die nächste Plattformentscheidung auf dem Tisch liegt.

• •

  Bestandsaufnahme der Betreiberstruktur: Welche Systeme laufen bei welchem Anbieter, unter welcher Jurisdiktion, mit welchen vertraglichen Zugriffsrechten?

• •

  Souveränitätsdimensionen in bestehende Architecture-Review-Checklisten aufnehmen: Nicht als eigenes Projekt, sondern als Erweiterung des Prozesses, der ohnehin läuft.

• •

  Kritische Abhängigkeiten identifizieren: Welche Systeme wären bei einem Anbieterwechsel am schwersten zu migrieren — und warum?

Was ich mitnehme — und was noch offen ist

Für mich ist der wichtigste Shift dieser: Datensouveränität ist aufgehört, ein juristisches Thema zu sein, und ist ein Architekturthema geworden. Das bedeutet, dass Architekten und IT-Leiter eine Verantwortung übernehmen, die früher woanders lag. Das ist nicht immer angenehm — aber es ist richtig.

Was ich noch nicht gut beantwortet sehe: Wie bewertet man Technologieabhängigkeiten quantitativ? Migrationskosten lassen sich schätzen, aber die Kosten einer eingeschränkten Verhandlungsposition gegenüber einem Hyperscaler sind schwerer zu beziffern. Daran arbeite ich gedanklich noch. Wer dazu schon konkrete Ansätze hat, bin ich neugierig.

Quellen

ERP Today

• •

  Why Data Sovereignty Is Becoming an Enterprise Architecture Question – ERP Today (https://erp.today/data-sovereignty-enterprise-architecture/)