Azure Governance Starter – Teil 2: Strategy, Plan & Ready praktisch umsetzen

Von der Cloud-Vision zur operativen Plattformstruktur

Die Einführung von Governance im Cloud-Umfeld beginnt nicht mit Tools, sondern mit strategischen Entscheidungen. Diese Einsicht bildet den Kern der Strategy und Plan Phase im Microsoft Cloud Adoption Framework (CAF). Während viele Unternehmen den operativen Einstieg über ein technisches Proof of Concept oder eine schnelle Migration suchen, schafft ein strukturierter Strategie- und Planungsprozess die Grundlage für nachhaltige Skalierbarkeit, Sicherheit und betriebliche Exzellenz.

In Teil 1 dieser Blogreihe haben wir aufgezeigt, warum Governance kein Kontrollinstrument, sondern ein zentrales Organisationsprinzip für den Cloud-Betrieb ist. Nun wollen wir diesen Gedanken vertiefen und zeigen, wie sich Cloud-Governance konkret vorbereiten, strukturieren und planen lässt.

Einordnung der Strategy-, Plan- und Ready Phase

Bevor wir in die Umsetzungstipps einsteigen, lohnt sich ein Blick auf die ersten Schritte im CAF:

• Strategy: Definition von Zielen, Mission, Business Cases und Risiken.
• Plan: Ableitung eines operativen Plans, Organisations- und Architekturvorgaben.
• Ready: Technische Umsetzung der Plattformvorgaben.

Diese Phasen bauen aufeinander auf und was hier nicht sauber definiert wird, führt später zu Nacharbeiten oder ineffizienten Workarounds.

Die hellblauen Kästen stehen für den jeweiligen Startpunkt bzw. das übergreifende Ziel der jeweiligen Phase. Die darauffolgenden grauen Kästen beinhalten die zu behandelnden Themenschwerpunkte je Phase. Lila Kästen repräsentieren abschließend die resultierenden Artefakte jeder Phase. Die Artefakte dienen dabei als Grundlage für die darauffolgenden Schritte und Aufgabengebiete.

Diese Abbildung fokussiert sich vorerst bewusst nur auf die ersten Schritte, da wir in den nächsten Teilen der Blog-Reihe die darauf aufbauenden Phasen Adopt, Govern, Secure und Manage behandeln werden.

Strategy: Vorarbeit innerhalb Ihres Unternehmens

Identifikation der Motivation zum Einsatz von Cloud Lösungen

Der Einstieg in die Cloud-Journey beginnt idealerweise mit der internen Identifizierung, Klassifizierung und Bewertung der Beweggründe für die Einführung von Cloud-Lösungen.

Der Zweck dieser Phase ist es, klare Motivationen zu definieren, die sowohl technologische als auch geschäftliche Perspektiven vereinen. Diese Motivationen dienen als strategischer Ankerpunkt für alle nachfolgenden Entscheidungen und Maßnahmen im Rahmen der Cloud-Einführung.

Diese Beweggründe sind dabei entscheidend für die Ausrichtung an strategischen Geschäftszielen, die Maximierung des Return on Investment (ROI) und eine fundierte, faktenbasierte Entscheidungsfindung.

In den nachfolgenden Tabellen sind die von Microsoft aufgezählten Beweggründe für die Verwendung von Cloud-Lösungen wie beispielsweise Azure:

Bestimmung der Cloud Mission

Nach der Definition der Motivation beginnt idealerweise mit der Formulierung einer Cloud-Mission, die sowohl technologische als auch geschäftliche Perspektiven vereint. Diese Mission beschreibt den angestrebten Nutzen der Cloud für das Unternehmen, sei es Innovationsbeschleunigung, Skalierbarkeit, Kostenreduktion oder regulatorische Absicherung. Aus dieser Mission werden konkrete, messbare Ziele abgeleitet, die als Referenz für alle Folgephasen dienen. Hierzu zählen beispielsweise KPIs zur Time-to-Market, zur Optimierung der Betriebskosten oder zur Erfüllung branchenspezifischer Compliance-Vorgaben.

Microsoft bietet hierfür im Cloud Adoption Framework verschiedene kostenfreie Assessments im Fragebogen-Format an. Diese helfen, den Reifegrad und die Lücken in Bezug auf Strategie, Prozesse und Skills objektiv zu erfassen.

Identifikation von Business-Cases

Basierend auf der definierten Cloud-Mission sind nun spezifische Business-Cases zu erarbeiten, die den Einsatz von Cloud-Providern erfordern.

Ein vollständiger Business Case sollte dabei folgendes enthalten:

• Nutzenanalyse (Einsparungen, Effizienz, Innovationspotenzial, Time-to-Market)
• Kostenmodell (Cloud-Betriebskosten, Migration, Schulungen)
• Risikoanalyse (technische Altlasten, regulatorische Unsicherheiten, organisatorische Blocker)
• Alternativszenarien (z. B. hybride Umsetzung)

Bewertung bestehender Risiken und SLAs

In dieser Phase werden Risiken strukturiert erfasst und den passenden Steuerungsmaßnahmen zugeordnet:

• Technische Risiken: Legacy-Systeme, fehlende Schnittstellen, Abhängigkeiten zu On-Premises
• Betriebliche Risiken: Personalkapazität, fehlende Prozesse, Incident-Reaktionszeit
• Regulatorische Risiken: DSGVO, branchenspezifische Normen (z. B. ISO 27001, BAIT, HIPAA)
• Vertrags- und SLA-Risiken: Unklare Verfügbarkeits- oder Supportregelungen

Identifikation der bestehenden System- und Anwendungslandschaft

Parallel zur wirtschaftlichen Bewertung erfolgt die Skizzierung einer Zielarchitektur auf High-Level-Ebene. Diese Architektur beschreibt erwartete Workloads, gewünschte Deployment-Modelle (IaaS, PaaS, SaaS), geographische Datenverteilung, Identity-Strategien (Entra ID, Hybrid) sowie Integrationspunkte mit bestehenden Systemen. Ziel ist nicht eine detaillierte technische Architektur, sondern ein strategisches Zielbild, das alle betroffenen Bereiche versteht und mitträgt.

Noch bevor detaillierte technische Designs entstehen, sollte demnach ein strategisches Architektur-Blueprint vorliegen:

• Workloads (kritische Anwendungen, Datenplattformen, Integrationen)
• Deployment-Modelle (IaaS, PaaS, SaaS)
• Region- & Datenlokation (Compliance, Latenz, Kosten)
• Identity-Strategie (Entra ID, Hybrid-Integration, Conditional Access)
• Integrationspunkte (On-Prem, Partner, SaaS-Dienste)

Identifikation unternehmensinterner Stakeholder

Ein zentraler Bestandteil der Strategy-Phase ist zudem die Erstellung einer Stakeholder Map. Governance betrifft weit mehr als die IT und umfasst Sicherheitsverantwortliche, Compliance-Teams, Finanzbereiche, Betriebsräte, Fachbereiche und externe Partner. Die Erwartungen, Verantwortlichkeiten und Einflussbereiche dieser Gruppen müssen klar dokumentiert und in eine geeignete Kommunikationsstrategie überführt werden.

Typische Stakeholder sind dabei:

• C-Level / Geschäftsführung
• IT-Leitung & Architektur
• Sicherheit & Compliance
• Finanzen / Controlling (FinOps)
• Betriebsrat / HR
• Fachbereiche mit hohen Cloud-Anforderungen
• Externe Partner / Dienstleister

Methoden für die Erstellung einer Stakeholder Map:

• RACI-Matrix (Responsible, Accountable, Consulted, Informed)
• Power-Interest-Grid (zur Priorisierung der Stakeholder-Kommunikation)

Zusammensetzung eines Strategy-Teams oder Cloud Center of Excellence

Nicht zuletzt wird in der Strategy-Phase ein interdisziplinäres Strategieteam aufgebaut, dass oft als Vorläufer eines Cloud Centers of Excellence (CCoE) fungiert. Dieses Team trägt Verantwortung für die konzeptionelle Steuerung der Cloud-Einführung. Dabei wird ebenso die Akzeptanz für den Einsatz von Cloud-Providern bewertet und bei Optimierungsbedarf konkrete Change-Management-Prozesse etabliert.

Refklektierte Bewertung der Cloud-Readiness und Bereitschaft der Organisation

Neben der technischen Readiness muss auch die organisatorische Reife bewertet werden:

• Gibt es bereits Cloud-Betriebsmodelle?
• Sind Rollen & Verantwortlichkeiten geklärt?
• Existieren Change-Management-Prozesse?

Hierfür eignen sich Microsofts Organizational Readiness Assessments im CAF, die gezielt Schwachstellen in Prozessen, Skills und Strukturen identifizieren.

Im Folgenden sind dazu eine Vielzahl an geführten Leitfaden von Microsoft hinterlegt, die während der Cloud Journey unterstützen können:

• Azure Well-Architected Framework Reifegradmodell Assessment
• Bewertung der Cloud-Einführungsstrategie
• Bewertung der Entwicklungsgeschwindigkeit
• Cloud Journey Tracker
• Cloud Governance
• DevOps-Funktionsbewertung
• FinOps Review
• Überprüfen der Azure Landing Zone
• Unternehmenskritische Workloads bewerten
• Technisches Assessment zu Plattformengineering

Als Abschlussprodukt der Strategy-Phase empfiehlt sich ein kompaktes Cloud Strategy Paper, das die Mission, Ziele, Risiken, Zielarchitektur und Prinzipien dokumentiert. Dieses Papier dient als Referenzrahmen für alle Folgephasen insbesondere die nachfolgende Planungsphase.

Plan: Auswahl der passenden Cloud Provider

Die Plan-Phase im Cloud Adoption Framework hat die Aufgabe, strategische Überlegungen in belastbare, technisch umsetzbare und organisatorisch verankerte Pläne zu überführen. Dabei geht es nicht nur um technische Entscheidungen, sondern um die Definition eines skalierbaren Betriebsmodells, das Governance, Sicherheit und Wirtschaftlichkeit dauerhaft trägt.

Definition von Non-Negotiables und Must-Haves

Am Anfang steht die bewusste Festlegung von nicht verhandelbaren Rahmenbedingungen. Diese „Non-Negotiables“ wirken wie Leitplanken, die jede Architektur- und Prozessentscheidung einhegen. Dazu zählen verbindliche Compliance- und Sicherheitsvorgaben, wie etwa DSGVO-Konformität oder branchenspezifische Standards, Mindestanforderungen an den Betrieb wie klar definierte SLA-Ziele oder Disaster-Recovery-Strategien sowie Architekturprinzipien, die nicht verletzt werden dürfen. Auch Einschränkungen bei der Auswahl von Azure-Regionen aus Gründen der Datenresidenz oder Latenz gehören dazu.

In der Praxis werden diese Punkte zunächst qualitativ priorisiert, etwa mit der MoSCoW-Methode und anschließend technisch zum Beispiel durch Azure Policy-Definitionen abgesichert. Diese sind dann an Management Groups gebunden, sodass neue Subscriptions automatisch konform aufgesetzt werden.

Individuelle Kategorisierung des Lebenszyklus einzelner Systeme und Anwendungen

Ein vollständiger Überblick über die bestehende System- und Anwendungslandschaft ist Grundvoraussetzung für jede realistische Planung. In der Plan-Phase wird deshalb jedes System und jede Anwendung nach ihrem Lebenszyklusstatus eingeordnet. Diese Kategorisierung macht deutlich, welche Systeme kritisch für den laufenden Betrieb sind, welche mittelfristig modernisiert werden sollten und welche auslaufen.

Häufig nutzen Unternehmen hier Modelle wie TIME (Tolerate, Invest, Migrate, Eliminate) oder einfache Run-/Grow-/Transform-Einordnungen. Unterstützt wird dieser Schritt durch Tools wie Azure Migrate für die automatisierte Bestandsaufnahme und Abhängigkeitsanalyse sowie Azure Resource Graph, um Umgebungen quer über alle Subscriptions hinweg zu inventarisieren.

Bestimmung der individuellen Migrationsstrategie einzelner Systeme und Anwendungen

Aufbauend auf der Kategorisierung wird für jedes System eine Migrationsstrategie festgelegt. Das CAF empfiehlt hierfür das Spektrum von Rehost über Refactor und Rearchitect bis hin zu Rebuild und Replace. Diese Entscheidung hängt nicht nur vom technischen Reifegrad ab, sondern auch von Business-Prioritäten, Kosten-/Nutzen-Abwägungen und regulatorischen Risiken.

In vielen Fällen ist es sinnvoll, zunächst einfache Rehost- oder Replatform-Szenarien zu realisieren, um schnell erste Workloads in Azure zu bringen und Erfahrungen im Betrieb zu sammeln, während komplexere Modernisierungen bewusst in spätere Migrationswellen gelegt werden. Microsoft bietet für diese Auswahl praxisnahe Entscheidungsleitfäden und Assessments, mit denen die geeignete Strategie pro Anwendung datenbasiert abgeleitet werden kann.

Bestimmung der personellen Betriebsmodelle

Ein zentrales Ergebnis der Plan-Phase ist die Definition des Cloud Operating Models. Dieses beschreibt, wie Rollen und Verantwortlichkeiten zwischen Plattform-Teams, Produkt-Teams und gegebenenfalls externen Partnern verteilt werden. Unternehmen müssen entscheiden, ob sie ein zentralisiertes Modell, ein dezentrales Modell oder einen hybriden Shared-Operations-Ansatz wählen.

Letzterer hat sich in vielen Organisationen bewährt. Ein zentrales Cloud Center of Excellence (CCoE) betreibt und entwickelt Governance-, Identitäts-, Netzwerk- und Sicherheitsservices, während Workload-Teams innerhalb definierter Leitplanken eigenverantwortlich arbeiten. In agilen Umgebungen kann auch ein „You build it, you run it“-Ansatz sinnvoll sein, bei dem Entwicklungsteams den vollen Lebenszyklus ihrer Workloads tragen.

Visualisierung und Kommunikation der Verantwortlichkeiten

Damit Verantwortlichkeiten nicht nur auf dem Papier existieren, werden sie in der Plan-Phase klar visualisiert und kommuniziert. Ein RACI-Modell, das jede Aufgabe einer Rolle zuordnet, sorgt hier für Transparenz. Dieses wird mit dem Azure Shared Responsibility Model abgeglichen, um zu verdeutlichen, welche Verantwortung Microsoft als Cloud Provider übernimmt und welche beim Kunden verbleibt. Dabei ist wichtig, zwischen technischer Durchsetzung etwa über Azure Policy oder Management Groups und organisatorischer Verantwortung also der Genehmigung, Überwachung und Eskalation zu unterscheiden.

Solche Modelle gehören nicht nur in die Governance-Dokumentation, sondern auch in Onboarding-Materialien damit sie im Alltag gelebt werden.

Planung der Abbildung der Organisationsstruktur in den Cloud-Umgebungen

Die Struktur der Cloud-Umgebung muss das Unternehmen logisch abbilden. Dazu wird in der Plan-Phase eine Subscription- und Management-Group-Strategie entworfen. Best Practices sehen eine klare Hierarchie vor, die von der Root-Management-Group über Organisations- und Funktionsebenen bis hin zu Umgebungen wie Produktion oder Test reicht.

Jede Ebene erhält passende Policies, Namenskonventionen und RBAC-Zuweisungen. Azure Policy-Sets sorgen für konsistente Compliance, Tagging-Strategien ermöglichen eine saubere Kostenzuordnung und Automatisierung, und klare Namensstandards erhöhen die Wiederauffindbarkeit von Ressourcen. Regulatorische Anforderungen, etwa die Trennung von EU- und Nicht-EU-Daten, sollten hier bereits in der Struktur verankert werden.

Definition architektonischer Designprinzipien und Ziele

Neben der organisatorischen Struktur werden in der Plan-Phase verbindliche Designprinzipien festgelegt, die als technische Leitplanken für die spätere Ready-Phase dienen. Dazu gehören Entscheidungen zum Netzwerkdesign beispielsweise Hub-and-Spoke oder Virtual WAN, zur Identitätsverwaltung mit Entra ID, zur Regionsauswahl unter Berücksichtigung von Latenz und Compliance, zu Skalierungs- und Resilienzstrategien sowie zu Wiederverwendbarkeit und Automatisierung. Ziel ist es, dass alle Teams auf denselben Prinzipien aufbauen und neue Workloads „compliant by default“ entstehen.

Erstellung einer Cloud-Roadmap inkl. Migrationswellen, Abhängigkeiten, Verantwortlichkeiten und Budgetzyklen

Die Cloud-Roadmap ist das operative Herzstück der Plan-Phase. Sie legt fest, in welchen Wellen Workloads migriert werden, welche Abhängigkeiten dabei berücksichtigt werden müssen, welche Teams zu welchen Zeitpunkten verantwortlich sind und wie Budgets und Lizenzen über den Zeitverlauf eingeplant werden.

Jede Welle erhält Meilensteine und Abnahmekriterien und nach Abschluss erfolgt anschließend eine Retrospektive, um die Roadmap an neue Erkenntnisse anzupassen. So bleibt der Plan aktuell, auch wenn sich Prioritäten ändern.

Ready: Technische und providerspezifische Vorarbeit

Die Ready-Phase im Microsoft Cloud Adoption Framework (CAF) übersetzt strategische Entscheidungen in eine produktionsreife Cloud-Plattform. Ziel ist die Umsetzung aller notwendigen technischen, organisatorischen und sicherheitsrelevanten Maßnahmen, um eine stabile Basis für Migrationen und Innovationen zu schaffen.

In Azure entspricht dies vor allem dem Aufbau von Landing Zones, die von Beginn an Governance, Sicherheit und Betriebskontinuität gewährleisten.

Auswahl der providerspezifischen Lösungen, Dienste und Werkzeuge

In diesem Schritt werden die in der Plan-Phase definierten Architekturprinzipien in konkrete Azure-Services übersetzt. Dabei gilt es, aus der Vielzahl an Angeboten die passenden Bausteine für Identität, Netzwerk, Sicherheit, Betrieb und Automatisierung auszuwählen.

Folgende Beispiele können dabei genannt werden:

• Identität: Microsoft Entra ID als zentrale Identity-Authority, ggf. mit hybrider AD-Anbindung
• Netzwerk: Hub-and-Spoke-Topologie oder Virtual WAN, zentrale Azure Firewall, Private Endpoints für PaaS-Dienste
• Sicherheit: Microsoft Defender for Cloud, Azure Policy, Key Vault für Secrets
• Provisionierung: Infrastructure-as-Code mit Bicep oder Terraform
• Kosten- & Betriebssteuerung: Azure Cost Management + FinOps-Tagging, Azure Monitor

Entscheidend ist, dass diese Services nicht isoliert betrachtet, sondern in ein konsistentes Plattform-Design eingebettet werden, das spätere Skalierung und Wiederverwendung erlaubt.

Umsetzung der Organisationsstruktur in den Cloud-Umgebungen

Die technische Abbildung der Organisationsstruktur erfolgt über eine Management Group-Hierarchie und eine durchdachte Subscription-Strategie.

Eine bewährte Struktur sieht dabei folgendermaßen aus:

• Root Management Group – globale Governance, Policies und RBAC-Rollen
• Plattform-Ebene – zentrale Dienste, Security- und Netzwerkinfrastruktur
• Business Units / Funktionen – nach Geschäftsbereichen oder Produktlinien
• Umgebungen – Trennung in Produktion, Test, Entwicklung

Auf dieser Basis werden Azure Policies für globale Standards angewendet, Namenskonventionen durchgesetzt und Budgetverantwortlichkeiten zugewiesen. Wichtig ist dabei alle Strukturen werden als Code implementiert, um Konsistenz und Wiederherstellbarkeit zu gewährleisten.

Festlegung der zu geltenden Richtlinien für Identity- und Access Management

Das Identity- und Access-Management folgt in der Ready-Phase konsequent dem Zero-Trust-Prinzip:

• Minimalprinzip bei Rechtevergabe (Least Privilege)
• Bedingte Zugriffe (Conditional Access) für MFA, Geräte-Compliance und Standortrestriktionen
• Temporäre Vergabe von privilegierten Rollen via Privileged Identity Management (PIM)
• Nutzung von Managed Identities für Anwendungen und Automationen
• Geheimnisse und Zertifikate ausschließlich in Azure Key Vault, automatische Rotation aktivieren

Die Umsetzung dieser Richtlinien wird über Azure Policy, Access Reviews und automatisierte Audit-Prozesse über Privileged Identity Management regelmäßig überprüft.

Umsetzung der der Netzwerk-Topologie

Das in der Plan-Phase entworfene Netzwerkdesign wird nun technisch implementiert. In der Praxis bedeutet das:

• Aufbau eines Hub-and-Spoke-Modells oder Virtual WAN mit zentraler Sicherheits- und Routinginstanz
• Integration von On-Premises über ExpressRoute oder VPN
• Nutzung privater Endpunkte für PaaS-Dienste, um Public Exposure zu minimieren
• Strikte NSG- und ASG-Konfiguration nach Whitelisting-Prinzip
• Umsetzung einer Private-DNS-Strategie für interne Namensauflösung

Umsetzung von technischen Sicherheitsmaßnahmen

Die technische Sicherheitsarchitektur wird in dieser Phase vollständig realisiert. Dazu zählen:

• Durchsetzung von Compliance-Vorgaben über Azure Policy und Policy-Initiativen
• Aktivierung von Defender for Cloud für Security Posture Management und Threat Protection
• Standardmäßige Verschlüsselung von Daten im Ruhezustand und während der Übertragung
• Integration von zentralem Key Vault für alle Secrets und Schlüssel
• Optional ebenso Multi-Cloud-Sicherheitsüberwachung mit Tools wie Prisma Cloud

Umsetzung eines zentralen Monitoringprozesses

Ein funktionierendes Monitoring ist Voraussetzung für Stabilität und schnelle Fehlerbehebung. In Azure wird dies typischerweise über folgende Bausteine erreicht:

• Azure Monitor für Metriken und Performance
• Log Analytics als zentrales Logging-Backend
• Application Insights für Applikations- und User-Telemetry
• Alert-Routing via Action Groups an verantwortliche Teams
• Automatisierte Reaktionen über Azure Automation oder Logic Apps

Definition von Strategien für Business Continuity und Disaster Recovery

Die BC/DR-Strategie stellt sicher, dass kritische Systeme auch im Katastrophenfall weiterlaufen oder schnell wiederhergestellt werden können. Die geltenden Best Practices sind dabei:

• Geo-redundante Speicherung (GRS, ZRS)
• Nutzung von Azure Site Recovery für VM- und App-Failover
• Regelmäßige, dokumentierte Wiederherstellungstests
• Backups mit definierter Aufbewahrungsfrist und Compliance-Konformität

Die Ready-Phase endet final mit einer formalen Validierung der Plattform. Microsoft bietet hierfür Assessments wie den Cloud Journey Tracker an, die Governance-Richtlinien, Sicherheitskonfigurationen, BC/DR-Fähigkeiten und Monitoring-Setups prüfen. Erst wenn alle Prüfkriterien erfüllt sind, gilt die Umgebung als produktionsreif und ist bereit für die Phasen Adopt, Govern, Secure und Manage.

Fazit

Die Phasen Strategy, Plan und Ready bilden den methodischen Unterbau jeder erfolgreichen Cloud-Governance-Initiative. Sie sind weit mehr als formale Vorarbeit und legen die architektonischen, organisatorischen und sicherheitstechnischen Leitplanken fest, an denen sich sämtliche Folgeaktivitäten orientieren. Wer hier sorgfältig arbeitet, reduziert das Risiko teurer Fehlentscheidungen, schafft ein gemeinsames Verständnis zwischen Business und IT und stellt sicher, dass die Cloud-Einführung langfristig skalierbar, sicher und effizient bleibt.

Besonders deutlich wird, dass erfolgreiche Cloud-Einführung nicht bedeutet, möglichst schnell Workloads zu migrieren, sondern bewusst die Grundlagen zu schaffen, auf denen später Automatisierung, Compliance und Innovationsgeschwindigkeit aufbauen. Die in diesen Phases erarbeiteten Artefakte von der Mission und den Business-Cases über die Management-Group-Struktur bis zu den technischen Plattformstandards sind der „Single Point of Truth“ für alle nachfolgenden Entscheidungen.

Die Ready-Phase fungiert dabei als Brücke zwischen Konzept und Realität. Hier werden die strategischen Entscheidungen aus Strategy und Plan in eine produktionsreife Plattform überführt mit klar definierten Identitätsrichtlinien, implementierter Netzwerk-Topologie, technischen Sicherheitsmechanismen, zentralisiertem Monitoring sowie durchdachten Business-Continuity- und Disaster-Recovery-Strategien. Erst wenn diese Elemente umgesetzt und validiert sind, gilt die Umgebung als Cloud-ready.

Im nächsten Teil dieser Reihe steigen wir in die Phasen ein, die den eigentlichen operativen Betrieb und die kontinuierliche Optimierung betreffen. Dabei betrachten wir die auf Ready aufbauenden Abschnitte des Microsoft Cloud Adoption Frameworks:

• Adopt: Migration bestehender Workloads und Modernisierung von Anwendungen, inklusive praxisnaher Migrationsmuster (Rehost, Refactor, Rearchitect, Rebuild, Replace).
• Govern: Etablierung eines belastbaren Governance-Frameworks mit Policy-Design, Kostenkontrolle (FinOps), regulatorischer Compliance und Security-by-Design.
• Secure: Umsetzung einer durchgängigen Sicherheitsarchitektur, Zero-Trust-Ansätze, Bedrohungserkennung, Incident Response und Security Operations.
• Manage: Etablierung von Betriebsprozessen, Monitoring, proaktiver Wartung, SLAs sowie kontinuierlicher Optimierung im Sinne des Well-Architected Framework.

Wir werden anhand konkreter Beispiele und Referenzarchitekturen aufzeigen, wie die in Ready vorbereiteten Strukturen den Grundstein für diese Phasen legen. Außerdem fließen Microsoft-Tools und Assessments ein, die bei der kontinuierlichen Reifegradsteigerung unterstützen.

Mit diesem ganzheitlichen Blick wirst du in der Lage sein, eine Cloud-Plattform nicht nur einzuführen, sondern sie über ihren gesamten Lebenszyklus hinweg strategisch zu steuern, sicher zu betreiben und gezielt weiterzuentwickeln.