„Cloud-First“ dominierte jahrelang IT-Strategien – oft verbunden mit einer riskanten Abhängigkeit von globalen Hyperscalern. Durch EU-Regulierungen und geopolitische Umbrüche wird das Thema der Digitalen Souveränität immer aktueller, bei der Benutzung von Cloud-Diensten.
Die Basis: Architektur statt Aktionismus
Unter Digitaler Souveränität wird die uneingeschränkte Entscheidungshoheit über die eigenen Daten, Applikationen und Systeme verstanden. In der Vergangenheit wurde dieses Thema oft übergangen oder als nicht prioritär Eingestuft. Das greift heute zu kurz; um die Hoheit über die eigenen Daten, Applikationen und Systeme nachhaltig zu sichern, muss das Thema bereits in der Enterprise Architektur verankert werden. Wer cloud-native baut, ohne von Tag eins an auf Portabilität zu achten, baut sich am Ende nur einen goldenen Käfig.
Ein sehr wirksames Werkzeug der Enterprise Architektur um dies zu vermeiden sind die Architekturprinzipien. Sie fungieren als universelle Leitplanken in der gesamten Organisation. Sie stellen sicher, dass vom Architektur-Board bis hin zum Entwicklerteam ein einheitliches Verständnis davon herrscht, nach welchen Regeln externe IT-Ressourcen genutzt werden.
Wie ein solches Prinzip aussehen kann, das den Einsatz von Cloud-Dienstleistern und Could-Services sicher steuert und gleichzeitig Innovation ermöglicht, zeigt folgendes Beispiel:
Architekturprinzip (Name):
Datensouveränität und Herstellerunabhängigkeit
Grundsatz (Statement):
Die Speicherung und Verarbeitung von Unternehmensdaten in einer Cloud-Umgebungen muss so gestaltet sein, dass die vollständige Portabilität jederzeit gewährleistet bleibt. Die Nutzung von Cloud-Diensten ist zwingend an die Verwendung offener Standards und Herstellerunabhänigen Schnittstellen gebunden, um eine strukturelle Abhängigkeit von proprietären Ökosystemen auszuschließen.
Begründung (Rationale):
Daten bilden das strategische Fundament unserer Organisation. Die Handlungsfähigkeit und die Souveränität hängen direkt davon ab, Datenbestände ohne signifikante Opportunitätskosten, Zeitverzug oder technisches Re-Engineering zwischen Providern transferieren oder in eigene Kapazitäten zurückführen zu können. Die Vermeidung von Vendor Lock-in sichert langfristig unseren Handlungsspielraum und minimiert das Klumpenrisiko im IT-Portfolio.
Auswirkungen (Implications):
- Standardisierungspflicht: Bei der Lösungsarchitektur haben industrieübergreifende Standards strikten Vorrang vor proprietären, nativen Services der Cloud-Anbieter.
- Obligatorisches Exit-Szenario: Jedes Design-Dokument muss im Rahmen der Governance-Prüfung ein validiertes Exit-Szenario enthalten. Dieses muss transparent aufzeigen, wie eine verlustfreie Datenextraktion technisch funktioniert und welche Kosten damit verbunden wären.
- Abstraktion vor Integration: Wo proprietäre Dienste absolut unvermeidbar sind, müssen zwingend Abstraktionsschichten implementiert werden. Architektur-Muster wie die Hexagonale Architektur helfen hier, die Kopplung zwischen der Applikationslogik und der spezifischen Infrastruktur des Cloud-Providers zu minimieren.
- Vertragliche Absicherung: Die Beschaffung muss sicherstellen, dass Klauseln zur Datenherausgabe in maschinenlesbaren, offenen Formaten integraler Bestandteil aller Service Level Agreements sind.
- Investitionspriorisierung: Höhere Initialkosten für plattformunabhängige Architekturen werden explizit in Kauf genommen. Sie sind eine bewusste Investition in eine langfristige technologische Flexibilität und der Sicherstellung der Digitalen Souveränität unserer Organisation.
Fazit: Die Balance macht’s
Bei der Formulierung von Architekturprinzipien ist Augenmass gefragt. Sie müssen in der Praxis durchsetzbar bleiben. Wenn ein Prinzip zu restriktiv formuliert ist, kann das dazu führen, dass faktisch gar keine Cloud-Dienste mehr eingesetzt werden können. Die Folge wäre unweigerlich das Entstehen einer „Schatten-IT“, weil die Fachbereiche schnelle Lösungen fordern und diese an der offiziellen IT vorbei unter Umgehung beschaffen. Gerade bei Cloud-Diensten ist diese Gefahr gross, da der Einstieg sehr niederschwellig ist, mehr als eine Kreditkarte und ein Notebook werden initial meist nicht benötigt. Darum besteht die wahre Kunst bei der Formulierung von Architekturprinzipien zur Daten-Souveränität darin eine balancierte Abwägung zwischen einer kompromisslosen Daten-Souveränität und Risikominimierung einerseits und andererseits dem sicherstellen einer technologischen Offenheit, damit Innovationspotential nicht im Keim erstickt wird.
Hinweis: Dieser Blogbeitrag wurde mit Hilfe von generativer KI erstellt.
