Cloud Operating Model: So bauen DACH-Unternehmen ihre Cloud-Organisation nachhaltig auf

Einleitung und Marktkontext

Cloud-Adoption in der DACH-Region hat eine kritische Schwelle ueberschritten. Laut Branchenanalysen betreiben die meisten Grossunternehmen bereits produktive Workloads auf AWS. Doch die organisatorische Reife hinkt der technischen Adoption hinterher. Teams provisionieren Infrastruktur, aber Governance, Kostenverantwortung und Sicherheitsstandards sind dezentral und inkonsistent.

Das Ergebnis: Shadow-IT-Strukturen, explodierende Cloud-Kosten, Sicherheitsluecken und fehlende Verantwortlichkeiten. Die Ursache ist fast nie technisch — sondern organisatorisch. Es fehlt ein Cloud Operating Model, das definiert, wer was wie in der Cloud betreibt.

AWS adressiert dieses Problem in der Prescriptive Guidance "Building your Cloud Operating Model" mit einem klaren Framework. Dieses Guidance-Dokument bildet zusammen mit dem AWS Well-Architected Framework Operational Excellence Pillar und Team Topologies die Grundlage fuer den in diesem Artikel beschriebenen Ansatz.

Begriffsklaerung: Die fuenf Organisationsmuster

Cloud Center of Excellence (CCoE)

Ein multidisziplinaeres Team aus Cloud-Architekten, Security-Spezialisten, FinOps-Experten und Compliance-Verantwortlichen. Das CCoE setzt Governance-Standards, definiert Best Practices, fuehrt Schulungen durch und beratet Fachteams bei Architekturentscheidungen. Es ist kein Gatekeeper, sondern ein Enabler — es beschleunigt die Cloud-Adoption, indem es Leitplanken statt Verbote etabliert.

Cloud Business Office (CBO)

Der zentrale Hub innerhalb des CCoE fuer Strategie, Governance und Budget. Das CBO verantwortet die Cloud-Strategie auf Business-Ebene: Kostenplanung, Chargeback-Modelle, Vendor-Management und Executive Reporting. Es uebersetzt technische Cloud-Metriken in Geschaeftskennzahlen und stellt sicher, dass Cloud-Investitionen messbar zum Unternehmenserfolg beitragen.

COPE — Cloud Operations and Platform Enablement

Ein Betriebsmodell nach dem Prinzip "you build it, you run it". COPE verlagert die operationale Verantwortung in die Produktteams, unterstuetzt durch eine zentrale Plattform. Statt einer zentralen Ops-Abteilung, die Tickets abarbeitet, befaehigt COPE Stream-Aligned Teams, ihre Workloads eigenverantwortlich zu betreiben — mit standardisierten Tools, Observability-Stacks und Deployment-Pipelines.

Platform Team

Ein dediziertes Team, das eine duenne Schicht gemeinsam genutzter Kernfaehigkeiten als Self-Service bereitstellt: Account-Vending, Netzwerk-Baselines, CI/CD-Pipelines, Observability, Security-Guardrails. Das Platform Team baut keine Geschaeftslogik — es baut die Plattform, auf der Geschaeftslogik schneller und sicherer entstehen kann. Ziel: Cognitive Load der Produktteams reduzieren.

Stream-Aligned Team

Nach Team Topologies das primaere Lieferteam, das an einem kontinuierlichen Strom von Geschaeftswert arbeitet — einem Produkt, einem Service oder einer Kundenreise. Stream-Aligned Teams haben End-to-End-Verantwortung: Entwicklung, Deployment, Betrieb und Monitoring ihres Workloads. Sie konsumieren die Services des Platform Teams ueber Self-Service-Interfaces.

Ergaenzend definiert Team Topologies zwei weitere Team-Typen: Enabling Teams, die Stream-Aligned Teams temporaer coachen (z. B. bei der Einfuehrung von Observability), und Complicated Subsystem Teams, die spezialisierte Komponenten mit hoher technischer Komplexitaet verantworten (z. B. ML-Inference-Plattformen).

Cloud-Reifegrad-Modell: Organisationsmuster pro Phase

Nicht jedes Organisationsmuster passt zu jedem Reifegrad. Die folgende Tabelle ordnet die Muster den typischen Phasen der Cloud-Adoption zu:

Der haeufigste Fehler: Unternehmen in Phase 2 versuchen, ein vollstaendiges Platform-Team nach Phase-4-Muster aufzubauen. Das scheitert, weil die organisatorische Basis — Governance, Ownership-Modelle, Budget-Transparenz — noch nicht existiert.

AWS-Implementierungsperspektive

AWS bietet konkrete Services und Guidance fuer den Aufbau eines Cloud Operating Model:

• AWS Organizations und Control Tower: Technische Grundlage fuer Multi-Account-Governance. Control Tower automatisiert die Einrichtung einer Landing Zone mit Guardrails, Logging und Account-Struktur — die Basis fuer jedes CCoE.
• AWS Service Catalog: Ermoeglicht dem Platform Team, genehmigte Infrastruktur-Blueprints als Self-Service bereitzustellen. Produktteams provisionieren Ressourcen innerhalb definierter Guardrails, ohne auf ein zentrales Ops-Team warten zu muessen.
• AWS Prescriptive Guidance — Cloud Operating Model: Das Guidance-Dokument beschreibt Organisationsstrukturen, Rollen und Verantwortlichkeiten fuer jede Phase der Cloud-Adoption. Es ist die offizielle AWS-Referenz fuer den Aufbau eines CCoE.
• Well-Architected Operational Excellence Pillar: Definiert Best Practices fuer Organisation, Vorbereitung und Betrieb von Workloads — einschliesslich Runbooks, Observability und Event-Management (AWS Well-Architected — Operational Excellence).
• AWS Cloud Adoption Framework (CAF): Strukturiert die Cloud-Adoption in sechs Perspektiven — Business, People, Governance, Platform, Security, Operations. Die People- und Governance-Perspektiven adressieren direkt den organisatorischen Wandel.

Enterprise-Adoptionsmuster

In der Praxis beobachten wir drei wiederkehrende Adoptionsmuster bei DACH-Unternehmen:

Muster 1: Top-Down CCoE

Die IT-Leitung gruendet ein CCoE mit dediziertem Budget und C-Level-Sponsorship. Vorteil: schnelle Governance-Etablierung, klare Mandate. Risiko: wird als Elfenbeinturm wahrgenommen, wenn die Einbindung der Fachteams fehlt. Typisch fuer regulierte Branchen (Finanz, Energie).

Muster 2: Bottom-Up Platform Engineering

Ein technisch starkes Team beginnt, gemeinsam genutzte Plattform-Services zu bauen — oft aus eigenem Antrieb. Vorteil: hohe Akzeptanz bei Entwicklern, praxisnahe Loesungen. Risiko: fehlende Governance, kein Budget-Mandat, Abhängigkeit von Einzelpersonen. Typisch fuer Tech-nahe Mittelstaendler.

Muster 3: Hybrid — CCoE mit Platform-Team-Kern

Kombination: Ein CCoE mit Governance-Mandat, dessen operativer Kern ein Platform Team ist. Das CCoE definiert Standards und Policies, das Platform Team setzt sie als Self-Service-Plattform um. Dieses Muster hat sich in der Praxis als das robusteste erwiesen — es verbindet Top-Down-Governance mit Bottom-Up-Adoption.

Storm Reply Perspektive: Road.MAP als strukturierender Rahmen

Der Aufbau eines Cloud Operating Model ist keine einmalige Transformation, sondern ein evolutionaerer Prozess. Die Storm Roadmap liefert den strukturierenden Rahmen dafuer.

Storm Reply als AWS Premier Consulting Partner im DACH-Raum begleitet Unternehmen seit 2008 auf diesem Weg. Die Road.MAP ordnet organisatorische Muster den Phasen des Cloud-Reifegrads zu und definiert konkrete Meilensteine:

• Assessment: Standortbestimmung — in welcher Phase befindet sich das Unternehmen? Welche organisatorischen Muster existieren bereits (formell oder informell)?
• Target Operating Model: Definition des Zielbilds — welche Team-Strukturen, Governance-Modelle und Interaktionsmuster passen zum Unternehmen?
• Phasenplan: Priorisierte Umsetzung in 90-Tage-Inkrementen. Quick Wins (Tagging-Strategie, Cost-Allocation) vor langfristigen Strukturaenderungen (CCoE-Aufbau, Platform-Team-Reifung).
• Coaching und Enablement: Storm Reply agiert als Enabling Team im Sinne von Team Topologies — temporaeres Coaching der internen Teams, bis sie eigenstaendig operieren koennen.

Der Ansatz basiert auf dem AWS Cloud Adoption Framework und der Prescriptive Guidance, ist aber auf die Realitaeten von DACH-Unternehmen zugeschnitten: Betriebsrat-Einbindung, Datenschutzanforderungen, foederale IT-Strukturen und die typische Mischung aus Legacy und Cloud.

Praxisanwendungsfaelle (DACH)

Automotive: Mature Cloud Operating Model bei Audi

Der Audi Cloud Service ist ein Beispiel fuer ein reifes Cloud Operating Model in der Praxis. Mit automatisiertem Account-Provisioning, ueber 285 Projekten und einer skalierbaren Governance-Struktur zeigt das Projekt, wie ein Platform-Team-Ansatz im Grosskonzern funktioniert. Storm Reply hat die technische Plattform aufgebaut und das organisatorische Modell mitgestaltet — von der Account-Vending-Automation bis zur Self-Service-Infrastruktur.

Energie: Organisatorischer Wandel bei der Cloud-Transformation

Die Cloud-Transformation von SOPTIM im Energiesektor zeigt, dass Migration ohne organisatorischen Wandel nicht nachhaltig ist. Neben der technischen Migration mussten Team-Strukturen, Verantwortlichkeiten und Betriebsprozesse angepasst werden — ein klassischer Fall fuer den Uebergang von Phase 2 zu Phase 3 im Reifegradmodell.

Energie: Governance-Framework fuer Edison

Die Migration von Edison zu AWS erforderte ein Governance-Framework, das Sicherheit, Compliance und operative Effizienz in Einklang bringt. EKS, Lambda und API Gateway bilden die technische Basis — aber ohne ein CCoE-aehnliches Governance-Modell waere der Betrieb im regulierten Energieumfeld nicht moeglich gewesen.

Industrie: Platform Team fuer IoT bei Schenck Process

Die CONiQ Cloud von Schenck Process ist ein Beispiel fuer ein Platform Team, das IoT-Anwendungen befaehigt. Das Team stellt die Plattform bereit, auf der Geschaeftsteams industrielle IoT-Loesungen entwickeln — ein klassisches Stream-Aligned/Platform-Team-Interaktionsmuster nach Team Topologies.

Regulatorische Aspekte

Der Aufbau eines Cloud Operating Model in DACH ist ohne regulatorische Beruecksichtigung nicht moeglich:

• DSGVO: Das CCoE muss Datenschutz-Guardrails definieren — Data Residency, Verschluesselung, Zugriffssteuerung. Platform Teams setzen diese als technische Policies in AWS Organizations um (SCPs, Tag Policies).
• NIS2: Die EU-Richtlinie fordert explizit ein Risikomanagement-Framework fuer kritische Infrastruktur. Ein CCoE mit Security-Fokus ist die organisatorische Antwort darauf.
• BSI C5: Fuer Unternehmen mit BSI-C5-Anforderungen muss das Cloud Operating Model nachweisbare Kontrollmechanismen beinhalten — dokumentierte Prozesse, Audit-Trails, Segregation of Duties.
• Betriebsrat: In Deutschland ist der Betriebsrat bei organisatorischen Veraenderungen einzubeziehen. Die Einfuehrung neuer Rollen (Platform Engineer, SRE) und Verantwortlichkeiten (On-Call, Incident Response) beruehrt Mitbestimmungsrechte.
• DORA: Fuer Finanzunternehmen fordert DORA ein dokumentiertes ICT-Risikomanagement-Framework. Das Cloud Operating Model muss DORA-Anforderungen an Third-Party-Risk-Management und Operational Resilience explizit abbilden.

Vorteile und Herausforderungen

Vorteile eines strukturierten Cloud Operating Model

• Klare Verantwortlichkeiten: Jeder Workload hat einen Owner. Governance ist kein Zufall, sondern Struktur
• Schnellere Time-to-Market: Self-Service-Plattformen reduzieren die Wartezeit auf Infrastruktur von Wochen auf Minuten
• Kostentransparenz: FinOps und Chargeback-Modelle machen Cloud-Kosten fuer Fachbereiche sichtbar
• Sicherheit by Design: Guardrails statt nachtraegliche Audits — Sicherheit ist in die Plattform eingebaut
• Skalierbarkeit: Neue Teams und Workloads koennen ohne proportionalen Anstieg des zentralen Ops-Aufwands hinzugefuegt werden
• Compliance-Readiness: Dokumentierte Prozesse und automatisierte Kontrollen erleichtern Audits und Zertifizierungen

Herausforderungen und typische Fallstricke

• Kulturwandel: "You build it, you run it" erfordert einen fundamentalen Wandel in der Verantwortungskultur. Nicht alle Teams sind bereit dafuer
• CCoE als Bottleneck: Ein CCoE, das zum Gatekeeper wird statt zum Enabler, bremst die Cloud-Adoption. Leitplanken muessen Geschwindigkeit ermoeglichen, nicht verhindern
• Platform-Team-Ueberlastung: Wenn das Platform Team versucht, alles selbst zu bauen, statt auf AWS Managed Services aufzusetzen, wird es zum Engpass
• Fehlende Executive Sponsorship: Ohne C-Level-Unterstuetzung hat das CCoE kein Mandat fuer organisationsuebergreifende Veraenderungen
• Ueberambitioniertes Target Operating Model: Der Sprung von Phase 1 direkt zu Phase 5 scheitert. Inkrementelle Reifung ist robuster als Big-Bang-Transformation

Ausblick: Platform Engineering als strategische Disziplin

Die Entwicklung geht klar in Richtung Platform Engineering als eigenstaendige Disziplin. Gartner prognostiziert, dass bis 2026 80 % der Software-Engineering-Organisationen Platform Teams aufbauen werden. Fuer DACH-Unternehmen bedeutet das: Der Aufbau eines Cloud Operating Model ist keine optionale Massnahme, sondern eine strategische Notwendigkeit.

Drei Trends werden das Cloud Operating Model in den naechsten Jahren praegen:

1. Internal Developer Platforms (IDP): Platform Teams entwickeln sich von Infrastruktur-Providern zu Produktteams, die eine interne Entwicklerplattform als Produkt betreiben — mit Developer Experience als zentralem KPI.
2. AI-augmented Operations: GenAI wird Incident Response, Runbook-Automatisierung und Capacity Planning unterstuetzen. Das veraendert die Rolle des SRE vom reaktiven Troubleshooter zum proaktiven System-Designer.
3. FinOps-Integration: Cloud-Kosten werden Teil des Engineering-Feedback-Loops. Jedes Stream-Aligned Team sieht seine Kosten in Echtzeit und traegt Kostenverantwortung.

Storm Reply begleitet DACH-Unternehmen auf diesem Weg — mit der Road.MAP als strukturierendem Rahmen, der organisatorischen Wandel messbar und planbar macht.

Haeufige Fragen (FAQ)

Was ist ein Cloud Operating Model?

Ein Cloud Operating Model definiert, wie ein Unternehmen seine Cloud-Umgebung organisatorisch betreibt: Rollen, Verantwortlichkeiten, Governance-Strukturen und Zusammenarbeitsmodelle zwischen Teams.

Was ist der Unterschied zwischen CCoE und Platform Team?

Ein CCoE ist ein multidisziplinaeres Governance-Team, das Standards setzt und Best Practices definiert. Ein Platform Team baut und betreibt die technische Self-Service-Plattform. Das CCoE definiert das Was, das Platform Team baut das Wie.

Wann braucht ein Unternehmen ein CCoE?

Sobald mehrere Teams unabhaengig Cloud-Ressourcen nutzen und Governance, Sicherheit und Kostenmanagement zentral koordiniert werden muessen — typischerweise ab Phase 2 (Foundation) des Cloud-Reifegrads.

Was bedeutet COPE im Cloud-Kontext?

COPE steht fuer Cloud Operations and Platform Enablement. Es beschreibt ein Betriebsmodell nach dem Prinzip "you build it, you run it", bei dem Produktteams ihre Workloads eigenverantwortlich betreiben.

Wie hilft die Storm Roadmap beim Aufbau eines Cloud Operating Model?

Die Road.MAP ordnet organisatorische Muster den Phasen des Cloud-Reifegrads zu, definiert Meilensteine und liefert einen priorisierten Umsetzungsplan in 90-Tage-Inkrementen.