Im September 2024 durfte ich eine Keynote an der Roche DevOps Conference in Polen halten. Das Thema: Wie man für Continuous Delivery die richtige Architektur schafft. Dieses Thema liegt mir besonders am Herzen, denn nach über zwei Jahrzehnten in der Software-Delivery sehe ich immer wieder dieselben Muster, die leistungsstarke Organisationen von jenen unterscheiden, die kämpfen.
Der gebrochene Value Stream#
Wenn ich Unternehmen besuche, begegne ich oft dem gleichen Bild. Das Business hat grosse Ideen und schreibt sie in Jira-Tickets und Word-Dokumente. Dann werden sie über eine Mauer der Verwirrung zum Entwicklungsteam geworfen. Die Entwickler implementieren etwas und werfen es zum Testing weiter. Die Tester schauen auf die Spezifikation, vergleichen sie mit dem Gebauten (was nie ganz übereinstimmt), testen etwas und werfen es zum Betrieb weiter. Der Betrieb fragt: “Wie sollen wir das betreiben?” Und irgendwie, mit vielen Nachtschichten, bringen sie es zum Laufen. Dann sieht das Business oder der Kunde das Ergebnis und sagt: “Was ist das? Damit können wir nichts anfangen.”
Dieses Muster wird durch Silo-Organisationen mit unterschiedlichen Zielen, fehlender Abstimmung und Legacy-Systemen angetrieben. Der Value Stream ist durch diese Mauern der Verwirrung komplett gebrochen. DevOps ist die Antwort: ein Mindset, eine Kultur und ein Set von technischen Praktiken, das es Teams ermöglicht, sich über den gesamten Value Stream zu organisieren und von Projekt-Denken zu Produkt-Denken zu wechseln.
Das Richtige richtig bauen#
Ein Prinzip, das ich immer betone: Bei DevOps geht es nicht nur darum, Dinge schneller zu bauen. Es geht darum, das Richtige richtig zu bauen. Das Richtige zu bauen bedeutet Effektivität. Es richtig zu bauen bedeutet Effizienz. Man braucht beides.
Die Wissenschaft bestätigt das. Das Buch Accelerate von Nicole Forsgren, Jez Humble und Gene Kim identifiziert 24 Schlüsselfähigkeiten, die die Software-Delivery-Performance antreiben, organisiert in fünf Kategorien: Continuous Delivery, Architektur, Produkt und Prozess, Kultur sowie Lean Management. Was diese Forschung so wertvoll macht, ist die Landkarte, die zeigt, wie diese Fähigkeiten sich gegenseitig beeinflussen. Wenn man die Ergebnisse auf der rechten Seite erreichen will, muss man in die Fähigkeiten auf der linken Seite investieren. Für Entscheidungsträger ist das ein unschätzbarer Leitfaden.
Software-Delivery-Performance messen mit DORA#
Die DORA-Metriken sind die einzigen wissenschaftlich bewiesenen KPIs zur Messung der Software-Delivery-Performance:
- Lead Time for Changes: Wie lange dauert es vom Code-Commit bis zur Produktion. Elite-Performer schaffen das in weniger als einer Stunde.
- Deployment Frequency: Wie oft wird in die Produktion deployed. Elite-Teams deployen on demand, mehrmals täglich.
- Time to Restore Service: Wie schnell erholt man sich von einem Ausfall. Elite-Teams schaffen das innerhalb einer Stunde.
- Change Failure Rate: Welcher Prozentsatz der Deployments verursacht einen Ausfall. Elite-Teams liegen zwischen 0 und 15%.
Das Wichtige dabei: Man muss nicht Elite sein. Man sollte über den eigenen Kontext nachdenken, definieren, was für die eigenen Produkte wichtig ist, und entsprechend messen.
Value Stream Mapping: Das ganze System sehen#
Bevor man irgendetwas optimiert, muss man den gesamten Value Stream verstehen. Value Stream Mapping ist eine einfache, aber wirkungsvolle Technik. Man bringt alle Personen, die an einem Produkt arbeiten, in einen Raum, gibt ihnen Post-its und bittet sie, jeden Schritt von der Idee bis zur Produktion aufzulisten. Dann identifiziert man, wer für jeden Schritt verantwortlich ist, und misst drei Dinge:
- Process Time (PT): Die tatsächliche wertschöpfende Arbeitszeit
- Lead Time (LT): Die gesamte verstrichene Zeit inklusive aller Wartezeiten
- Percentage Complete and Accurate (%C&A): Die Qualität des Outputs jedes Schritts
Wenn man das tut, werden Engpässe sofort sichtbar. Zum Beispiel könnte ein Test-Schritt 8 Stunden tatsächliche Arbeit zeigen, aber 336 Stunden Lead Time, was massive Wartezeiten bedeutet. Mit dem sichtbaren Gesamtsystem können Teams den gesamten Stream verbessern, statt einen Teil auf Kosten eines anderen zu optimieren.
Shift Left: Qualität und Sicherheit#
Qualität einbauen bedeutet Shift Left. Statt des traditionellen V-Modells mit verzögerten Feedback-Zyklen von drei bis sechs Monaten will man Behavior Driven Development (BDD) mit testbaren Akzeptanzkriterien von Anfang an und Test Driven Development (TDD), bei dem Tests vor dem Code geschrieben werden. Das dreht die Testpyramide um: viele schnelle, günstige Unit-Tests an der Basis, weniger Integrationstests in der Mitte und nur eine kleine Anzahl langsamer, teurer End-to-End-Tests an der Spitze.
“50% des Geldes, das ein Musk-Unternehmen in ein neues Produkt investiert, geht in automatisiertes Testen.” Denkt einmal an euer eigenes Produkt. Kommt ihr auch nur annähernd an 10%?
Dasselbe Shift-Left-Prinzip gilt für die Sicherheit. Die Continuous-Delivery-Pipeline sollte statische Code-Analyse, Software Composition Analysis, Container-Scanning, Secret Detection und Dynamic Application Security Testing beinhalten. Und selbst wenn sich nichts am Code ändert, müssen geplante Pipelines regelmässig auf neu entdeckte Schwachstellen prüfen.
Architektur für Observability#
Wenn Systeme sich von Zwei-Schicht-Anwendungen zu verteilten Microservice-Architekturen entwickeln, wird Monitoring zu vollständiger Observability. Man braucht Tracing, Metriken und Logs, alles von Anfang an in die Anwendung eingebaut. Das bedeutet: für Observability architekturieren, nicht nachträglich draufschrauben.
Infrastructure as Code, Staging-Umgebungen, die der Produktion entsprechen, Feature Toggles für Canary Releases und teamübergreifende Zusammenarbeit beim Monitoring sind alle essentielle Bestandteile.
Platform Engineering: Der Enabler#
All das erzeugt eine erhebliche kognitive Belastung für Teams. Deshalb bewegt sich die Industrie in Richtung Platform Engineering. Gartner prognostiziert, dass bis 2027 75% der Organisationen eine interne Plattform aufgebaut haben werden.
Das Modell ist klar: Ein Platform-Team baut und pflegt eine interne Developer-Plattform als Produkt. Die Kunden dieses Produkts sind die Produkt-Teams. Die Plattform stellt die Werkzeuge und Fähigkeiten bereit, die Produkt-Teams brauchen, um DevOps zu praktizieren. Das Platform-Team befähigt; die Produkt-Teams bauen, betreiben und warten ihre Produkte.
Zum Beispiel stellt das Platform-Team Observability-Fähigkeiten bereit. Die Produkt-Teams nutzen diese Fähigkeiten, um ihre eigenen Applikationen zu überwachen. Das Platform-Team überwacht nicht die Applikationen für sie. Diese klare Aufgabenteilung erzeugt Wert auf jeder Ebene.
Kernaussagen#
- Das Richtige richtig bauen. Nicht nur auf Geschwindigkeit fokussieren. Sicherstellen, dass man baut, was Kunden wirklich brauchen, und das in guter Qualität.
- Den Value Stream visualisieren. Den gesamten Fluss von der Idee bis zur Produktion verstehen, bevor man einzelne Teile optimiert.
- DORA-Metriken klug einsetzen. Sie sind bewiesene KPIs, aber man sollte sie auf den eigenen Kontext anwenden statt blind den Elite-Status anzustreben.
- Qualität und Sicherheit nach links verschieben. In Testautomatisierung, BDD, TDD und Pipeline-Sicherheit von Anfang an investieren.
- Für Observability architekturieren. Telemetrie in die Applikationen einbauen, nicht erst nachträglich hinzufügen.
- In Platform Engineering investieren. Teams befähigen, DevOps zu praktizieren, indem man ihnen eine Self-Service-Plattform bereitstellt, die die kognitive Belastung reduziert.
Wir betreten eindeutig das Zeitalter der industrialisierten Softwareentwicklung. Platform Engineering ist der zentrale Enabler, und die richtige Architektur für Continuous Delivery ist der Weg dorthin.