Zum Hauptinhalt springen

cloud Cloud Adoption Framework für die öffentliche Verwaltungfeedback

Adoptionsrahmen

Dieses Framework beschreibt den strukturierten Weg von der Strategie bis zum produktiven Betrieb in der Verwaltungscloud. Es basiert auf dem Azure Cloud Adoption Framework und dem GovStack-Ansatz, angepasst auf die regulatorischen und organisatorischen Rahmenbedingungen deutscher Behörden.

Erstellt am: 15. März 2026 | Autor: BMDS-Architekturteam

lightbulb Motivationfeedback​

Der Weg in die Cloud ist für Behörden keine rein technische Migration. Er erfordert eine abgestimmte Strategie, organisatorische Veränderungen und ein belastbares Governance-Modell. Das Cloud Adoption Framework (CAF) bietet einen phasenorientierten Rahmen, der sicherstellt, dass technische und organisatorische Aspekte gleichermaßen adressiert werden.

Während das Well-Architected Framework die Qualität einzelner Workloads bewertet, adressiert das CAF die übergeordneten Fragen: Welche Workloads migrieren wir wann? Wie gestalten wir die Governance? Welche Kompetenzen brauchen wir?

timeline Phasen der Cloud-Adoptionfeedback​

🧭 Phase 1: Strategiefeedback​

Die strategische Ausrichtung definiert, warum und in welchem Umfang Cloud-Dienste genutzt werden sollen.

  • Cloud-Strategie des Bundes: Einordnung in die Verwaltungscloud-Strategie und die Vorgaben des IT-Planungsrats
  • Souveränitätsanforderungen: Festlegung der Anforderungen an Datensouveränität und technologische Unabhängigkeit
  • Stakeholder-Analyse: Einbindung von Fachbereichen, IT-Sicherheit und Datenschutzbeauftragten

📐 Phase 2: Planungfeedback​

Die Planungsphase inventarisiert den IT-Bestand und priorisiert Arbeitslasten für die Migration.

  • Portfolio-Analyse: Bewertung aller Anwendungen nach den „6Rs" (Retain, Retire, Rehost, Replatform, Refactor, Rebuild)
  • Priorisierung: Fachverfahren mit niedriger Komplexität und hohem Cloud-Nutzen zuerst
  • Architekturentscheidungen: Auswahl der Zielarchitektur, Cloud-Native, Microservices oder Hybrid, je nach Workload
  • Kostenplanung: Wirtschaftlichkeitsbetrachtung und Haushaltsmittelanmeldung

🏗️ Phase 3: Landing Zonefeedback​

Eine Landing Zone ist die vorkonfigurierte Zielumgebung, in der Cloud-Workloads sicher betrieben werden.

🚀 Phase 4: Migrationfeedback​

Die eigentliche Migration überführt Workloads in die vorbereitete Landing Zone.

  • Migrationswellen: Gestaffelter Rollout, beginnend mit unkritischen Systemen
  • Datenübertragung: Sichere Migration von Registerdaten über Registerdaten-Transfer (DSP/OOTS)
  • Testing: Automatisierte Integrations- und Sicherheitstests vor jedem Go-Live
  • Rollback-Strategie: Definierte Rückfallszenarien und Backup & Recovery

⚙️ Phase 5: Governancefeedback​

Governance sichert den langfristigen, regelkonformen Betrieb.

  • Policy-as-Code: Automatisierte Durchsetzung von Sicherheitsrichtlinien über Zero Trust Policy Engine
  • Compliance-Monitoring: Kontinuierliche Prüfung gegen BSI C5 und DSGVO
  • FinOps: Transparente Kostensteuerung und -optimierung
  • Auditierung: Nachvollziehbare Änderungshistorie und Berechtigungsmanagement über PAM

📈 Phase 6: Optimierungfeedback​

Nach dem initialen Betrieb werden Workloads kontinuierlich verbessert.

  • Architektur-Reviews: Regelmäßige Bewertung gegen das Well-Architected Framework
  • Modernisierung: Schrittweiser Umbau von Rehost-Workloads zu Cloud-Native oder Microservices
  • Automatisierung: Ausweitung von GitOps und Infrastruktur-as-Code
  • Wissenstransfer: Aufbau interner Cloud-Kompetenzen und Community of Practice

hub Relevanz für den D-Stackfeedback​

Das CAF ist kein separates Projekt, sondern die Klammer um die D-Stack-Funktionsbausteine. Jede Phase nutzt spezifische Bausteine:

CAF-PhaseRelevante D-Stack-Bausteine
Landing ZoneSCS & Verwaltungscloud, Zero Trust
MigrationRegisterdaten-Transfer, Backup & Recovery
GovernanceBSI C5 Tooling, PAM, SIEM/SOC
OptimierungAPI-Management, Cloud-Native

compare_arrows Abgrenzungfeedback​

Das CAF beschreibt den organisatorischen Adoptionsprozess. Für die technische Qualitätsbewertung einzelner Workloads siehe das Well-Architected Framework. Für die konkreten Infrastruktur- und Plattformkomponenten siehe die D-Stack-Funktionsbausteine.