Wie (un)abhängig sind Sie mit Ihrer Cloud-Strategie?

Digitale Souveränität, Cloud-Souveränität, wie auch immer Sie es nennen wollen, ist innerhalb sehr kurzer Zeit zu einer strategischen Bedingung für nahezu jede Organisation geworden. Nicht, weil die Cloud weniger Nutzen weniger wird, sondern weil die Abhängigkeiten zunehmen, wenn man nicht bewusst plant.

Warum Souveränität für viele jetzt ein dringendes Thema ist

In Gesprächen mit Kunden hören wir häufig drei Gründe.

Erstens: Geopolitik und die Tatsache, dass Gesetzgebung und Datenzugriff nicht an Landesgrenzen Halt machen. Zweitens: immer konkretere Vorschriften und Kontrollen in Bezug auf Datenstandorte, Risiken in der Lieferkette, Nachvollziehbarkeit und Ausstiegsmöglichkeiten. Und drittens: der Markt selbst.

Hyperscaler entwickeln sich stetig weiter, und das sehen wir sehr positiv. Ihr Innovationstempo bringt großen Mehrwert. Ihre Preismodelle, Lizenzänderungen und immer intelligentere Managed Services sorgen aber gleichzeitig dafür, dass man leicht unbemerkt immer mehr in eine Abhängigkeit rutschen kann. Das soll jetzt nicht heißen, dass Sie die Finger von Hyperscalern lassen sollen, sondern bewusst planen und auswählen.

Und Kunden sagen heute noch etwas anderes.

Etwas, dass wir vor fünf Jahren eher selten gehört haben. „Ja, wir wollen die Vorteile der Public Cloud, doch wir wollen auch die Kontrolle behalten." Über Daten, über Risiken und über Alternativen. Oder noch konkreter: „Wie kommen wir da wieder raus, wenn wir es müssen?“

Was ist digitale Souveränität in der Cloud (und was nicht)?

Der Begriff der digitalen Souveränität wird meist stark vereinfacht dargestellt: „Alles in Europa“ oder „Alles zurück zu On-Premises“. Das ist so nicht ganz richtig. Warum? Weil Souveränität keine reine Standort­entscheidung, sondern ein Gestaltungs­prinzip ist.

Es geht vielmehr darum, Ihre Cloud-Strategie so zu gestalten, dass Sie auch zukünftig dazu in der Lage sind, Entscheidungen in Bezug auf Daten, Sicherheit, Kosten und Lieferanten treffen zu können, ohne dass Ihr IT-Betrieb zum Erliegen kommt oder das Geschäftsmodell einbricht. Das erfordert Entscheidungen in den Bereichen Governance, Architektur, Verträge, Datenklassifizierung und Betrieb. Es ist also eine strategische Angelegenheit, deren Umsetzung jedoch auf technischer Ebene erfolgt.

Warum Cloud-Strategien in der Praxis häufig ins Leere laufen

Viele Unternehmen haben einmal mit „Cloud first“ und „schnell migrieren“ begonnen. Das ist logisch, denn das Business fordert Schnelligkeit. Jedoch läuft es später nicht immer wie erhofft, meist aus folgenden Gründen:

1. Keine klaren Vorgaben im Vorfeld
Ohne klare Kriterien für die Workloads (was ist wo unter welchen Bedingungen zulässig?) geht jedes Team seinen eigenen Weg. Das funktioniert so lange, bis Compliance, Sicherheit oder Kosten zum Problem werden.

2. Zu schneller Umstieg auf native Managed Services ohne „Exit-by-Design“
Managed Services sind attraktiv: geringer Verwaltungsaufwand, schnellere Inbetriebnahme. Wenn man sich bei Kernprozessen allerdings zu stark auf anbieterspezifische Datenbanken, Identitätsmanagement, Eventing und Tools stützt, kann eine spätere Umstellung einen kompletten Neuaufbau bedeuten.

3. Multicloud-Einsatz ohne Betriebsmodell
Multicloud kann die Souveränität stärken – ohne Governance, FinOps, Sicherheitsstandards und entsprechendem Fachwissen kann es jedoch schnell zu Fragmentierung, doppelten Tools und unvorhersehbaren Ausgaben kommen.

Ein Vendor Lock-in entsteht selten durch eine einzige bewusste, große Entscheidung. Meistens ist es die Summe aus Hunderten kleiner Entscheidungen, die zu dem jeweiligen Zeitpunkt alle logisch erschienen.

Wie entwickelt man eine Cloud-Strategie, die einem Entscheidungsfreiheit lässt?

Cloud-Souveränität beginnt nicht mit Technologie, sondern mit Segmentierung. Klingt vielleicht langweilig, aber das ist nun mal die Grundlage. 

1. Daten und Workloads klassifizieren
Werden Sie konkret: Welche Daten und Workloads sind kritisch, sensibel oder stark reguliert? Welche erfordern eine geringe Latenz oder besondere Ausfallsicherheit? Welche lassen sich problemlos in der Public Cloud betreiben? Und welche sollten besser zum Teil in einer Hybrid-Umgebung untergebracht werden? Dies wird zu Ihrer Richtschnur für Strategie und Architektur.

2. Praktikable Leitplanken festlegen 
Dazu gehören: Sicherheitsrichtlinien, Verschlüsselung und Key Management, Protokollierung und Monitoring, Identity, Netzwerkprinzipien und Kostenkontrolle. Aber nicht in Form eines 10.000-seitigen Dokuments, sondern als wiederverwendbare Landing Zones und Muster, die den Teams helfen, innerhalb klarer Grenzen schneller voranzukommen. 

3. Portabilität dort, wo sie nötig ist
Nicht alles muss portabel sein. Doch für Ihre kritischsten Workloads ist es ratsam, Abhängigkeiten zu minimieren. Denken Sie z. B. an:

• Infrastruktur-as-Code mit reproduzierbaren Deployments

• Standardisierung von CI/CD

• Entkopplung von Identity und Observability

• Bewusste Entscheidungen in Bezug auf die Datenarchitektur, wie Formate, Pipelines und Ownership
  
  

4. Den Exit zum Bestandteil von Design und Vertrag machen
Eine Ausstiegsstrategie gehört nicht unter ferner liefen. Sie ist eine Design- und Governance-Komponente. Legen Sie daher folgendes fest:

• was „Exit“ bedeutet (Umzug, Plattformwechsel oder funktionaler Ersatz)

• wie Daten migriert werden können

• welche Abhängigkeiten Sie akzeptieren

• welche vertraglichen Vereinbarungen Sie in Bezug auf Datenaufbewahrung, Support, Kosten und Fristen benötigen

Woran erkennt man, ob die eigene Strategie noch genügend Spielraum lässt?

Ein praktischer Test: Können Sie die unten stehenden Fragen mit „Ja“ beantworten?

• Sind wir in der Lage, kritische Workloads innerhalb eines angemessenen Zeit- und Kostenrahmens zu migrieren oder auf eine andere Plattform zu verlagern?
• Haben wir einen Überblick über technische und vertragliche Abhängigkeiten?
• Sind IAM, Protokollierung und Sicherheitskontrollen über alle Umgebungen hinweg konsistent?
• Können wir nachvollziehen, wo sich unsere Daten befinden, wer Zugriff darauf hat und welche Kontrollen gelten?
• Verfügen wir über ein getestetes Ausstiegsszenario für unsere wichtigsten Systeme?

Wenn Ihre Antwort auf mehrere Fragen „Nein“ lautet, ist das nicht sofort ein Problem. Aber es ist ein Zeichen dafür, dass Sie vielleicht nicht ganz so unabhängig sind, wie gedacht, und sich eine Roadmap überlegen sollten, um Ihre Souveränität zu stärken.

Ein realistischer erster Schritt

Sie wollen Nägel mit Köpfen machen? Mein Rat: Fangen Sie klein, aber konsequent mit einem Choice-Freedom-Blueprint an:

• Daten- und Workload-Klassifizierung
• Sicherheits-, Compliance- und FinOps-Leitplanken
• eine Referenzarchitektur für Hybrid- und Multi-Cloud-Umgebungen, wo erforderlich,
• Ausstiegsbedingungen als Standard bei Design und Beschaffung.

So profitieren Sie weiterhin von den Vorteilen der Cloud, während Sie das Risiko einer unbeabsichtigten Abhängigkeit aktiv begrenzen.

Digitale Souveränität bedeutet nicht weniger Cloud. Es geht um bessere Cloud-Entscheidungen. Und darum, sich Optionen für alles offen zu halten, was die Zukunft bringt.