An der DEVOPS Conference habe ich über ein Thema gesprochen, das seit über zwei Jahrzehnten im Mittelpunkt meiner Arbeit steht: Wie man die Architektur für Continuous Delivery gestaltet. Dieser Vortrag behandelt den kaputten Wertstrom, den ich in den meisten Unternehmen sehe, warum Produktdenken wichtiger ist als Projektdenken, die Wissenschaft hinter der Software-Delivery-Performance und wie Platform Engineering es Organisationen ermöglicht, DevOps durch digitale Fabriken zu skalieren.
Der kaputte Wertstrom#
Wenn ich Unternehmen besuche, sehe ich immer wieder dasselbe Muster. Das Business und die Kunden haben gute Ideen. Sie schreiben diese Ideen in Word-Dokumente und Jira-Tickets. Dann werfen sie sie über die Mauer der Verwirrung zum Entwicklungsteam. Das Entwicklungsteam sagt „klar, das können wir umsetzen" und wirft das Ergebnis zum QA-Team. QA sagt „passt nicht zu den Anforderungen, aber es ist grün" und wirft es zum Betrieb. Der Betrieb sagt „wie sollen wir das betreiben?" und schafft es irgendwie, es zum Laufen zu bringen. Dann schaut das Business auf das Ergebnis und sagt: „Was ist das? Das löst unser Problem nicht."
Dieses Bild wird angetrieben von Silo-Organisationen mit unterschiedlichen Zielen, einem vollständigen Mangel an Abstimmung und einem Mangel an Software-Engineering-Exzellenz. Die Erfahrung für alle Beteiligten ist schlecht.
Von Waterfall über Agile zu Produkten#
Um die Wurzel dieses Problems zu verstehen, müssen wir in die Geschichte schauen. Zuerst hatten wir Waterfall, wo wir grosse Softwarepakete planten, designten, entwickelten, testeten und deployten. Zeit, Umfang und Budget waren fix. Viele Projekte scheiterten.
Dann sagten kluge Leute „gehen wir agil vor" und liefern in kleineren Inkrementen. Zeit und Budget sind fix, der Umfang ist variabel. Das war eine sehr gute Verbesserung. Aber wir arbeiteten immer noch in Projekten.
Der entscheidende Wandel ist der Wechsel von Projekten zu Produkten. Ein Projekt hat einen Anfang und ein Ende, einen Satz Ressourcen und ein Lieferergebnis. Es fokussiert auf den Output: Maximierung der Anzahl von Features. Ein Produkt fokussiert auf das Ergebnis: das Problem des Kunden lösen. Den Kunden interessieren keine zehn Features. Er interessiert sich für das eine Feature, das sein Problem löst.
„DevOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken, die Kommunikation, Integration, Automatisierung und enge Zusammenarbeit aller Menschen ermöglicht, die nötig sind, um ein Produkt zu planen, entwickeln, testen, deployen, releasen und zu warten."
Die Wissenschaft: Accelerate und die DORA-Metriken#
Das Buch Accelerate hat wissenschaftlich untersucht, warum manche Unternehmen hervorragend darin sind, Produkte zu erstellen, während andere scheitern. Es wurden 24 Schlüsselfähigkeiten identifiziert, organisiert in technische Praktiken, Kultur und Mindset, die die Software-Delivery-Performance antreiben.
Die DORA-Metriken sind der wissenschaftlich bewiesene Weg, diese Performance zu messen:
- Lead Time for Changes: Vom Code-Commit bis zur Produktion. Elite schafft das in weniger als einer Stunde.
- Deployment Frequency: Wie oft man deployt. Elite deployt auf Abruf, mehrmals täglich. Das Schlüsselprinzip: Deployment (Code in Produktion mit Feature Toggle aus) ist nicht dasselbe wie Release (Toggle ein).
- Time to Restore Service: Wie schnell man sich von einem Fehler erholt. Elite schafft das in weniger als einer Stunde.
- Change Failure Rate: Prozentsatz der Deployments, die Fehler verursachen. Elite liegt bei 0 bis 15 %.
Die State-of-DevOps-Berichte zeigen den Unterschied zwischen Low-Performern und Elite-Performern: 208x häufigere Deployments, 106x schnellere Lead Time, 2604x schnellere Wiederherstellung und 7x niedrigere Change Failure Rate. Die Vorteile sind klar: schnellere Time to Market, mehr Wert für das Geld, höhere Qualität und höhere Kundenzufriedenheit.
Die Herausforderung der DevOps-Skalierung#
Wenn Unternehmen DevOps skalieren wollen, ist ein häufiger Fehler, ein „DevOps-Team" zu erstellen, das nur ein weiteres Silo ist. Der richtige Ansatz ist, Entwicklung und Betrieb in crossfunktionalen Produkt-Teams zusammenzubringen.
Aber dann erfindet jedes Team das Rad neu. Es gibt Inkonsistenz, Redundanz, mangelnde Betriebserfahrung und enorme Komplexität bei den Tools. Wenn man sich eine Continuous-Delivery-Pipeline anschaut, gibt es eine enorme Menge an Tooling, und alle diese Tools müssen zusammenarbeiten und gewartet werden.
Selbst Plattformen wie GitLab, GitHub und Azure DevOps decken nicht alles ab. Man muss trotzdem Komponenten ersetzen oder ergänzen. Die kognitive Last für die Teams ist hoch. Das Onboarding dauert Monate. Die Bereitstellung einer neuen Datenbank oder eines Kubernetes-Clusters dauert Monate. Es fehlt an Standardisierung, und das Ergebnis ist langsame Time to Market und niedrige Qualität.
Platform Engineering: Der Enabler#
Die Lösung ist Platform Engineering. Das Zielbild ist eine digitale Fabrik mit einem Fliessband der Automatisierung, wo Teams sich auf die eigentliche Arbeit konzentrieren können.
Die Organisationsarchitektur sieht so aus: Produkt-Teams fokussieren sich auf das Bauen, Betreiben und Warten ihrer Produkte. Das Plattform-Team stellt die Plattform bereit. Das Plattform-Team ist kein weiteres Silo. Es ist ein Produkt-Team, dessen Kunden die anderen Produkt-Teams sind.
Das Plattform-Team baut die CI/CD-Pipeline, die API-Entkopplungsschicht, die Kubernetes-Infrastruktur, die synthetischen Testdaten und alles andere, was die Produkt-Teams brauchen. Die Produkt-Teams nutzen diese Plattform, um DevOps zu praktizieren.
„Das Plattform-Team schafft Wert für die Teams. Die Produkt-Teams schaffen Wert für den Kunden. Platform Engineering ermöglicht es Produkt-Teams, DevOps zu betreiben."
So gestaltet man die Architektur für kontinuierliche Wertlieferung. So reduziert man die kognitive Last. Und so skaliert man DevOps.
Threat Modeling und Sicherheit#
In der Fragerunde fragte jemand, wie man Threat Modeling in CI/CD integriert. Meine Antwort: Man muss die Architektur auf Sicherheit ausrichten, genauso wie man sie auf Testbarkeit und Betreibbarkeit ausrichtet.
Threat Modeling funktioniert so: Man versammelt das Team und einen Sicherheitsexperten in einem Raum. Man zeichnet das Kontextdiagramm der Applikation. Man identifiziert die Angriffsvektoren und Bedrohungen. Man definiert Massnahmen, nimmt sie ins Backlog auf, implementiert sie und testet sie in der Pipeline. Man integriert Container Scanning, Software Composition Analysis, Dependency Scanning und SAST. In der Produktion überwacht man kontinuierlich auf Angriffe.
Kernaussagen#
- Reisse die Mauern der Verwirrung ein. Organisiere dich entlang des Wertstroms, nicht in Silos.
- Denke in Produkten, nicht in Projekten. Fokussiere dich auf das Ergebnis für den Kunden, nicht auf den Output für die Organisation.
- Nutze die DORA-Metriken. Sie sind der wissenschaftlich bewiesene Weg, Software-Delivery-Performance zu messen.
- Baue digitale Fabriken. Schaffe Fliessbänder der Automatisierung, die kontinuierliche Wertlieferung ermöglichen.
- Investiere in Platform Engineering. Das Plattform-Team ermöglicht es Produkt-Teams, DevOps zu betreiben, indem es die kognitive Last reduziert und standardisierte Self-Service-Fähigkeiten bereitstellt.
- Gestalte die Architektur auf Sicherheit. Nutze Threat Modeling und Shift-Left-Security-Praktiken, um deine Applikationen von Anfang an zu schützen.