Das Dilemma
Stellen Sie sich vor: Ihr Entwicklerteam braucht eine neue Datenbank. Sofort. Ein kritisches Feature wartet darauf, ausgeliefert zu werden. Time-to-Market ist entscheidend.
Was passiert? Ein Ticket wird erstellt. Es wandert durch verschiedene Abteilungen. Security prüft. Compliance prüft. Infrastruktur plant. Drei Wochen später – wenn Sie Glück haben – ist die Datenbank bereit.
In der Zwischenzeit? Ihre Konkurrenz hat das Feature bereits ausgeliefert.
Das ist nicht nur frustrierend. Das kostet Geld. Echtes Geld.
Die zwei Welten
Kennen Sie das Bild? Zwei Katzen, die sich angespannt gegenüberstehen. Beide kampfbereit, beide misstrauisch. Genau so sieht es oft in IT-Organisationen aus:
Die Developer-Katze: Will produktiv sein. Schnell deployen. Innovationen vorantreiben. Sie sieht nur Hindernisse und Wartezeiten. Macht den Katzenbuckel, ist in Abwehrhaltung.
Die Governance-Katze: Will Standards durchsetzen. Sicherheit gewährleisten. Compliance sicherstellen. Sie sieht nur Risiken und unkontrollierte Deployments. Sitzt erhaben, aber wachsam.
Beide haben recht. Beide verlieren.
Der Business Impact – Die versteckten Kosten
Die Kosten dieses Konflikts sind real und messbar:
Verzögerte Time-to-Market
Jede Woche Wartezeit auf Infrastruktur ist eine Woche, in der Ihre Konkurrenz vorbeizieht. In digitalen Märkten kann das den Unterschied zwischen Marktführerschaft und Bedeutungslosigkeit bedeuten.
Überlastete Teams
Ihr Governance-Team ertrinkt in manuellen Anfragen. Jedes Ticket wird zum Bottleneck. Die besten Leute verbringen ihre Zeit mit Routineaufgaben statt mit strategischen Initiativen.
Shadow IT
Wenn der offizielle Weg zu langsam ist, graben Developer Tunnel. Sie erstellen eigene Cloud-Accounts. Nutzen ungeprüfte Services. Das Ergebnis? Compliance-Risiken, Sicherheitslücken und unkontrollierte Kosten.
Frust auf beiden Seiten
Developer fühlen sich blockiert. Governance fühlt sich überrannt. Die Zusammenarbeit leidet. Gute Leute verlassen das Unternehmen.
KRITIS: Wenn Governance nicht verhandelbar ist
Für Unternehmen in kritischen Infrastrukturen verschärft sich die Situation dramatisch. Die NIS2-Richtlinie, das IT-Sicherheitsgesetz 2.0, der BSI-Grundschutz – das sind keine Empfehlungen. Das sind Pflichten mit erheblichen Konsequenzen bei Nichteinhaltung.
Dazu kommen branchenspezifische Vorgaben: BAIT und DORA für Banken, VAIT für Versicherungen. Jede Branche hat ihre eigenen regulatorischen Hürden.
Die zentrale Frage ist nicht mehr „Ob“ wir Governance brauchen, sondern „Wie“ wir sie umsetzen, ohne die Organisation zu lähmen.
Geht das überhaupt? Agilität UND Compliance?
Ja. Aber dafür braucht es einen Paradigmenwechsel.
Die Lösung: Das Cloud Operating Model
Die Antwort liegt nicht in mehr Prozessen oder strengeren Kontrollen. Sie liegt in einem fundamentalen Umdenken, wie wir IT-Organisationen strukturieren.
Der organisatorische Rahmen
Ein Cloud Operating Model definiert klare Verantwortlichkeiten zwischen Typen von Teams,
Platform Teams (zentral):
- Bauen und betreiben die Infrastruktur-Plattform
- Definieren sichere, compliant Standards
- Entwickeln Self-Service-APIs für andere Teams
- Enforced Governance-Regeln technisch
Workload Teams (dezentral):
- Entwickeln und betreiben Applikationen
- Nutzen die Platform-Services eigenständig
- Arbeiten innerhalb der vorgegebenen Standards
- Können sich auf ihr Kerngeschäft konzentrieren
Hinweis: Das Team Topologies Framework von Matthew Skelton und Manuel Pais definiert weitere Team-Typen wie Enabling Teams (Unterstützung beim Lernen neuer Fähigkeiten) und Complicated-Subsystem Teams (für hochspezialisierte technische Bereiche). Für die Umsetzung eines Cloud Operating Models sind jedoch Platform und Workload Teams die Kernbausteine.
Die vier Kernprinzipien
- Klare Verantwortungstrennung: Keine Grauzonen mehr. Jeder weiß, wo seine Verantwortung beginnt und endet. Platform Teams definieren das „Wie“, Workload Teams fokussieren sich auf das „Was“.
- Standardisierte Schnittstellen Teams kommunizieren nicht über Tickets, sondern über APIs. Platform Teams bauen Infrastruktur-Services, die andere Teams wie normale Software-Services nutzen können.
- Self-Service mit Guardrails Das ist der Kern: Freiheit innerhalb definierter Grenzen. Developer können selbstständig agieren – aber nur innerhalb sicherer, vorgefertigter Patterns. Wie auf einer Autobahn: Sie können so schnell fahren wie Sie wollen, aber die Leitplanken sorgen dafür, dass Sie auf der Straße bleiben.
- Automation über Prozesse Governance wird nicht durch Menschen durchgesetzt, sondern durch Code. Technische Kontrolle statt manueller Genehmigungen. Das System prüft, validiert und enforced – automatisch und konsistent.
Der entscheidende Unterschied
Traditionell: Governance als Gatekeeper. Jeder Request wird manuell geprüft. Menschen sind der Flaschenhals.
Modern: Governance als Enabler. Regeln sind in Code gegossen. Systeme prüfen automatisch. Menschen fokussieren sich auf Strategie, nicht auf Routineaufgaben.
Die technische Umsetzung: Platform Engineering
Aber wie setzt man so ein Operating Model technisch um?
Hier kommt Platform Engineering ins Spiel – eine der wichtigsten Entwicklungen der letzten Jahre in der Enterprise-IT. Und Tools wie Crossplane, die diesen Ansatz ermöglichen.
Was ist Platform Engineering?
Platform Engineering bedeutet, Infrastruktur wie ein Produkt zu behandeln. Platform Teams bauen interne Produkte für andere Entwicklerteams. Diese Produkte sind:
- Self-Service: Developer können sie eigenständig nutzen
- Standardisiert: basieren auf Best Practices und Compliance-Anforderungen
- Wiederverwendbar: einmal gebaut, mehrfach genutzt
- Dokumentiert: mit klaren APIs und Anleitungen
Ein praktisches Beispiel
Lassen Sie mich das konkret machen:
Vorher (ticketbasiert):
- Developer erstellt Ticket: „Brauche eine Applikation-Umgebung mit Datenbank, Monitoring und externem Zugriff.“
- Ticket geht an Infrastruktur-Team
- Infrastruktur erstellt manuell: Kubernetes Deployment, Service, Datenbank, NetworkPolicies, Monitoring-Konfiguration, Gateway-Routing
- Security prüft Konfiguration
- Compliance gibt frei
Nachher (plattformbasiert):
- Developer nutzt Self-Service Portal oder einfaches YAML-File
- Definiert, was er braucht: „Application, 3 Replicas, Internet-Zugang, Monitoring“
- Platform erstellt automatisch alle notwendigen Ressourcen
- Security-Checks sind eingebaut
- Compliance ist automatisch erfüllt
Was bedeutet das konkret für Ihre Organisation?
- schnellere Bereitstellung: von Wochen auf Minuten
- Reduktion manueller Arbeit: Ihr Team fokussiert sich auf Wertschöpfung.
- Null Shadow IT: Der offizielle Weg ist der einfachste Weg.
- Compliance: automatisch, nicht optional
- Audit-ready: vollständige Nachvollziehbarkeit durch GitOps
Der Governance-Gewinn
Aber Platform Engineering ist nicht nur gut für Developer. Es ist besonders gut für Governance.
Kontrolle durch Code, nicht durch Menschen:
- Standards werden einmal definiert und dann automatisch durchgesetzt
- Keine manuellen Reviews mehr für Standard-Anfragen
- Keine menschlichen Fehler
- Keine Ausnahmen ohne explizite Änderung am Code
Vollständige Nachvollziehbarkeit:
- Alle Änderungen in Git versioniert
- Audit-Trail automatisch
- Compliance-Reporting auf Knopfdruck
- Forensik bei Problemen
Skalierbarkeit:
- Ein Pattern wird tausende Male genutzt
- Governance-Team wächst nicht linear mit der Organisation
- Zentrale Updates propagieren automatisch
Die Transformation: Von Bottleneck zu Enabler – die Partnerschaft
Die wirkliche Magie passiert in der Zusammenarbeit:
Developer-Perspektive:
- „Ich kann sofort produktiv sein.“
- „Die Platform gibt mir, was ich brauche.“
- „Compliance ist nicht mein Problem – es funktioniert einfach.“
- Resultat: Produktivität, Innovation, Zufriedenheit
Governance-Perspektive:
- „Standards werden automatisch durchgesetzt.“
- „Wir definieren Patterns, das System prüft.“
- „Wir können strategisch denken, statt Tickets abzuarbeiten.“
- Resultat: Kontrolle, Effizienz, Wertschöpfung
Beide gewinnen
Das ist der Kern: Es ist kein Zero-Sum-Game mehr. Developer bekommen Speed. Governance behält Kontrolle. Die Organisation gewinnt Agilität UND Sicherheit.
Der Weg dorthin
Die gute Nachricht: Sie müssen nicht alles auf einmal transformieren. Der Weg zu einer modernen Platform-Organisation ist iterativ.
Lessons Learned: Was wir gelernt haben
- Operating Model zuerst, Technologie zweiter: Die besten Tools helfen nichts, wenn die Organisation nicht bereit ist. Klären Sie erst Verantwortlichkeiten, dann wählen Sie die Technologie.
- Klein starten, groß denken: Versuchen Sie nicht, alles auf einmal zu transformieren. Ein erfolgreicher Pilot überzeugt mehr als das beste Konzeptpapier.
- Developer Experience ist entscheidend: Wenn Ihr Self-Service komplizierter ist als Shadow IT, werden Developer Shadow IT nutzen. Der offizielle Weg muss der einfachste Weg sein.
- Governance-Team mitnehmen: Platform Engineering ist keine Bedrohung für Governance, es ist ein Upgrade. Aber das muss kommuniziert werden.
- Messbare Erfolge zeigen: „Time to Database“ von 3 Wochen auf 2 Minuten. „Manual Work“ von 8 Stunden auf 0. Solche Zahlen überzeugen.
Fazit: Die Zeit ist jetzt
Die digitale Transformation wartet nicht. Ihre Konkurrenz transformiert sich bereits. Die Frage ist nicht „Ob“, sondern „Wann“ und „Wie“.
Das Dilemma zwischen Self-Service und Governance lässt sich lösen. Moderne Platform-Ansätze zeigen: Beides ist möglich. Agilität UND Compliance. Speed UND Sicherheit.
Der erste Schritt ist der wichtigste: Erkennen, dass es einen besseren Weg gibt.
Weiterführende Ressourcen
- Gregor Hohpe: „Platform Strategy – Innovation Through Harmonization“
- Gregor Hohpe: “Cloud Strategy – a Decision Based Approach to Successful Cloud Migration”
- Team Topologies: Organizing Business and Technology Teams for Fast Flow
- CNCF Platform Engineering Maturity Model
