Wie moderne Unternehmen Cloud-fähig, resilient und menschlich bleiben – und welchen Herausforderungen sie dabei begegnen.
Der digitale Wandel ist längst Realität. Technologien skalieren, Automatisierung nimmt zu, Cloud und Plattformmodelle werden zum Standard. Doch die eigentliche Frage lautet: Wie organisieren und führen wir in einer Welt, in der Technologie, Geschwindigkeit und Veränderung der Normalzustand sind? Was muss sich im Kontext Organisation und Führung ändern, um diesen Change zu unterstützen? Wie kommt eine Organisation dahin? Was braucht sie wirklich – und welche Stolperfallen liegen auf dem Weg?
Cloud-Fähigkeit, Resilienz und moderne Teamstrukturen sind kein Selbstzweck. Sie sind Voraussetzungen dafür, dass Unternehmen schnell reagieren, sicher arbeiten und kontinuierlich lernen können. Und sie gelingen nur, wenn Führung Verantwortung klar verteilt, Orientierung bietet und eine Kultur schafft, die Fehler zulässt, Zusammenarbeit stärkt und echte Verbesserung ermöglicht.
Operating Models neu denken – wie Organisationen Cloud-fähig werden
Was ist ein „Cloud Operating Model“?
Gartner versteht unter einem Cloud Operating Model das organisatorische Fundament, das Teams befähigt, Cloud-Technologien sicher, skalierbar und wertschöpfend einzusetzen.
Es definiert:
• Verantwortlichkeiten
• Entscheidungsmodelle
• Arbeitsweisen
• Governance & Security
• Betriebsmodelle für Software und Daten
Kurz: Es ist das Betriebssystem der Organisation.
Wie kommt man als Organisation dahin? Was braucht man?
- Ein gemeinsames Zielbild
Ohne klar definierte Ambition („Warum Cloud?“) entsteht Chaos statt Transformation.
Entscheidend ist:
• Alignment zwischen Business, IT & Führung
• ein realistischer Reifegrad-Check
• eine Roadmap, die technisch und kulturell ist
- Skills & Befähigung
Cloud-Fähigkeit entsteht nicht durch Tools, sondern durch Menschen.
Notwendig sind:
• Cloud-, Sicherheits- und Architekturkompetenzen
• DevOps-, CI/CD- und Automatisierungsfähigkeiten
• Leadership-Kompetenzen für Arbeiten in hoher Komplexität
- Team Topologies als Strukturrahmen
Team Topologies ist ein Organisationsmodell, das beschreibt, wie Teams zusammenarbeiten sollten, damit digitale Produkte schnell, sicher und skalierbar geliefert werden können. Die drei wichtigsten Teamtypen erfüllen dabei jeweils eine eigene Funktion:
Plattformteams – Komplexität reduzieren
Plattformteams bauen interne Plattformen (z. B. Developer Platforms, Data Platforms), die den anderen Teams wiederkehrende, komplexe Aufgaben abnehmen. Plattformteams geben allen anderen Teams „Superkräfte“, indem sie den schwierigen technischen Unterbau liefern.
Was heißt das konkret?
• Sie stellen zentrale Bausteine bereit: CI/CD-Pipelines, Security-Standards, Logging, Monitoring, Infrastruktur
• Produktteams müssen diese Dinge nicht mehr selbst bauen
• Dadurch können sie sich auf ihre eigentliche Aufgabe konzentrieren: Wert für Kunden schaffen
Nutzen:
• weniger technische Komplexität für Produktteams
• schnellere Lieferzeiten
• weniger Fehler durch Standards & Automatisierung
Enabling Teams – Teams befähigen, nicht kontrollieren
Enabling Teams bestehen aus Expert:innen (Security, Architektur, DevOps, Cloud, FinOps), die andere Teams unterstützen, neue Fähigkeiten zu entwickeln. Enabling Teams bringen Know-how genau dorthin, wo es gebraucht wird – ohne Teams abhängig zu machen.
Wichtig ist die Haltung: Sie sind Coaches, nicht Auditoren.
Was machen Enabling Teams?
• sie helfen Teams, Wissen aufzubauen
• sie moderieren schwierige technische Entscheidungen
• sie identifizieren Hindernisse und beseitigen sie
• sie begleiten Übergangsphasen (z. B. Migrationen in die Cloud)
Was machen sie NICHT?
• Entscheidungen abnehmen
• Genehmigungsinstanzen sein
• andere Teams kontrollieren
Nutzen:
• schnellerer Kompetenzaufbau
• weniger Abhängigkeiten
• bessere Qualität und Sicherheit
Shared Services – Governance & Self-Service ermöglichen
Shared Services sind zentrale Einheiten, die Standard-Services bereitstellen, die alle Teams benötigen – z. B. Identity & Access Management, Netzwerk, Compliance, Security-Policies. Shared Services schaffen Orientierung und Sicherheit – ohne die Geschwindigkeit der Teams zu bremsen.
Der entscheidende Punkt: Moderne Shared Services arbeiten nicht als Flaschenhals, sondern als Self-Service-Anbieter.
Was bedeutet das?
• klare, dokumentierte Standards
• automatisierte Policies
• Self-Service-Funktionen statt Ticket-Warteschlangen
• Governance durch klare Leitplanken, nicht durch Bürokratie
Nutzen:
• Sicherheit & Compliance bleiben stabil
• Teams können eigenständig arbeiten
• weniger Wartezeiten und weniger „Handoff-Schmerz“
- Resilienz als Grundhaltung
Digitale Organisationen müssen damit rechnen, dass Technik ausfällt, Märkte sich ändern und Teams sich neu formieren. Resilienz bedeutet deshalb nicht Reagieren – sondern vorbereitet sein.
Organisationen brauchen drei Formen von Resilienz:
- Technische Resilienz
Systeme sollen Probleme selbst erkennen und möglichst automatisch beheben.
Beispiele: Observability, automatische Self-Healing-Mechanismen. - Prozessuale Resilienz
Wenn etwas schiefläuft, muss klar sein, wer was wann tut.
Beispiel: funktionierende Incident-Response-Prozesse. - Menschliche Resilienz
Teams brauchen eine Kultur, in der Fehler offen angesprochen werden können und Menschen sich sicher fühlen.
Beispiele: Fehlerkultur, psychologische Sicherheit.
Stolperfallen & Probleme auf dem Weg zur Cloud-Fähigkeit
Auf dem Weg zur Cloud-Fähigkeit geraten viele Organisationen in typische Fallen. Eine der häufigsten ist die Einführung neuer Technologien ohne den notwendigen Kulturwandel – moderne Tools werden zwar eingeführt, aber alte Arbeitsweisen bleiben unverändert.
Beispiel: Ein Unternehmen führt eine DevOps-Toolchain ein, aber Deployments müssen weiterhin manuell freigegeben werden.
Ebenso verbreitet ist die „Wir bauen das mal nebenher“-Mentalität, bei der Teams Cloud-Transformation zusätzlich zum Tagesgeschäft erledigen sollen.
Beispiel: Das Produktteam soll eine Cloud-Migration stemmen, während es gleichzeitig Releases liefern muss – beides leidet.
Ein weiteres Risiko liegt in unklaren Verantwortlichkeiten zwischen Plattform- und Produktteams, was zu Konflikten, Doppelarbeit oder Lücken führt.
Beispiel: Niemand fühlt sich für das Monitoring verantwortlich, bis ein Ausfall passiert.
Auch Governance wird oft als Blockade statt Enabler gestaltet – mit komplexen Prozessen, die eher verlangsamen als schützen sollen.
Beispiel: Für jedes neue Cloud-Resource-Tagging braucht es eine manuelle Genehmigung, wodurch Projekte Tage verlieren.
Hinzu kommt häufig eine fehlende Priorisierung und Unterinvestition: Die Cloud-Transformation wird gewollt, aber nicht ausreichend budgetiert oder mit Zeit hinterlegt. Beispiel: Plattformteams sollen eine Self-Service-Plattform liefern, bekommen aber nur eine halbe Stelle dafür.
Ein weiteres Problem ist, dass Sicherheitsfragen zu spät berücksichtigt werden, was später zu teuren Nacharbeiten führt.
Beispiel: Eine Applikation wird komplett migriert, erst danach prüft Security die Architektur – und verlangt große Änderungen.
Und schließlich scheitern viele an zu schneller Skalierung ohne architektonische Disziplin.
Beispiel: Zehn neue Microservices entstehen in drei Monaten, aber ohne ein gemeinsames API-Design – später versinkt die Organisation im Integrationschaos.
Welche Nachteile gibt es?
Auch Cloud und moderne Operating Models bringen Schattenseiten mit sich. Mit jeder neuen Cloud-Funktion wächst die Komplexität, weil mehr Services, Abhängigkeiten und Konfigurationen entstehen. Gleichzeitig steigt die Abhängigkeit von spezialisierten Skills, da Architektur, Security und Automatisierung tiefes Fachwissen erfordern.
Ohne konsequentes FinOps-Management besteht zudem ein Kostenrisiko, weil Cloud-Ressourcen schnell unkontrolliert wachsen können. Für Mitarbeitende bedeutet die Transformation häufig Veränderungsdruck, da Rollen, Tools und Prozesse sich laufend verändern.
Und schließlich besteht immer die Gefahr des Over-Engineerings, wenn Teams Technologien einführen, die zwar modern klingen, aber keinen echten Mehrwert liefern.
