Ich wurde eingeladen, die Keynote am Baloise OpenX Day zu halten, einer internen Konferenz, an der die Baloise ihre Technologie-Community zusammenbringt. Die Session kombinierte Impulsvorträge mit interaktiven Diskussionen und gab mir die Gelegenheit, DevOps-Grundlagen zu teilen und dann direkt von den Teams über ihre echten Herausforderungen zu hören. Die Gespräche mit den Baloise-Ingenieuren waren unglaublich wertvoll, besonders zu Themen wie Continuous Deployment in regulierten Branchen und die Rolle von Platform Engineering.
Der unterbrochene Wertstrom#
Ich begann mit einem Bild, das ich bei vielen Unternehmen sehe: dem unterbrochenen Wertstrom. Das Business wirft Anforderungen über eine Mauer zur Entwicklung, die Entwicklung wirft Code zum Testing, das Testing gibt etwas an den Betrieb weiter, und der Kunde bekommt etwas, das er nicht bestellt hat. Diese “Walls of Confusion” entstehen durch Siloorganisationen und einen grundlegenden Mangel an Abstimmung.
Das tieferliegende Problem ist das Projektdenken. Projekte fokussieren sich auf die Maximierung des Outputs: die Anzahl der gelieferten Features innerhalb eines fixen Budgets und Zeitrahmens. Produkte hingegen fokussieren sich auf Outcomes: den Kunden verstehen, seine Probleme lösen, sein Verhalten verändern. DevOps ermöglicht dieses Produktdenken, indem es alle Menschen, Prozesse und Technologien entlang des Wertstroms ausrichtet.
“DevOps ist eine Denkweise, eine Kultur und ein Set von technischen Praktiken, die Kommunikation, Integration, Automatisierung und enge Zusammenarbeit aller Menschen im Wertstrom ermöglichen.”
Den Wertstrom verstehen und messen#
Eine der wirkungsvollsten DevOps-Techniken, die ich vorstellte, ist das Value Stream Mapping. Man bringt alle Personen, die am Wertstrom arbeiten, in einen Raum: Business, Architekten, Entwickler, Tester, Security, Qualitätssicherung, Betrieb. Gemeinsam kartiert man jeden Schritt von der Idee bis zur Produktion, identifiziert die Verantwortlichen und misst dann drei Dinge: Lead Time (Gesamtzeit inklusive Wartezeit), Process Time (tatsächliche wertschöpfende Arbeit) und Percentage Complete and Accurate (wie oft der nächste Schritt das Ergebnis direkt verwenden kann).
Die Ergebnisse sind oft augenöffnend. In meinem Beispiel hatte der Testschritt eine Lead Time von 336 Stunden, aber nur 8 Stunden tatsächliche Process Time. Das bedeutet, die meiste Zeit wird mit Warten verbracht. Der Rolling Percentage Complete and Accurate lag bei nur 5%, was bedeutet, dass nur 5% der Arbeit ohne Nacharbeit durch den gesamten Prozess fliesst. Wenn Teams diese Zahlen sehen, verstehen sie sofort, wo die Engpässe liegen.
Continuous Delivery: Die Begriffe richtig verstehen#
Ein Thema, bei dem ich immer Zeit investiere, ist die Klärung der CI/CD-Terminologie, weil ich sehe, dass viele Teams diese Begriffe falsch verwenden. Continuous Integration bedeutet: Jeder Code-Commit löst einen automatisierten Build mit Code-Analyse, Security-Analyse, Unit-Tests und Integrationstests aus, und Feedback kommt innerhalb von Minuten. Das Ergebnis ist ein deploybare Artefakt.
Continuous Delivery nimmt dieses Artefakt und installiert es automatisch in einem Staging-Environment für weitere Tests. Continuous Deployment geht einen Schritt weiter: Das Artefakt wandert automatisch durch das Staging in die Produktion, mit automatisierten Tests auf jeder Stufe und automatischem Rollback bei Fehlern.
Die wichtige Erkenntnis: Man braucht nicht unbedingt Continuous Deployment. Continuous Delivery ist für viele Teams absolut ausreichend. Aber man muss klar wissen, auf welchem Level man sich befindet und was das Business tatsächlich benötigt.
DevOps in regulierten Branchen#
Der spannendste Teil der Session war die Diskussion über DevOps in der regulierten Finanzbranche. Eine wiederkehrende Sorge war: “Wir brauchen eine manuelle Freigabe vor dem Produktions-Deployment. Ist Continuous Deployment überhaupt möglich für uns?” Meine Antwort war klar: Ja, ist es.
Das häufige Argument in Finanzinstituten ist, dass die Segregation of Duty eine andere Person zur Deployment-Freigabe erfordert. Aber wenn man die Regulierung tatsächlich liest, steht dort, dass ein Entwickler nicht direkt in die Produktion deployen können soll. Es steht nicht, dass ein Mensch jedes Deployment manuell prüfen muss. Eine automatisierte Pipeline mit richtigen Security-Checks, statischer Code-Analyse, automatisierten Tests und Audit-Trails erfüllt die regulatorische Absicht weit besser als ein Mensch, der Jira-Tickets überprüft.
“Die Wissenschaft sagt: Wenn man ein manuelles Release Management Gate hat, wird die Software Delivery Performance darunter leiden. Das Beste ist, ehrlich gesagt, es abzuschaffen.”
Ich empfahl ein aufschlussreiches Experiment: Man führt absichtlich ein kleines Stück fehlerhaften Code durch den Release-Prozess der Organisation. In den meisten Fällen werden die manuellen Review-Gates es nicht fangen, was zeigt, dass Automatisierung weit überlegenen Schutz bietet.
Platform Engineering für Skalierung#
Die späteren Diskussionen berührten Platform Engineering als Schlüssel zur Skalierung von DevOps. Wenn jedes Produktteam sein eigenes CI/CD-Tooling aufbaut und pflegt, wird die kognitive Last überwältigend. Neue Teammitglieder brauchen Monate, um produktiv zu werden. Die Bestellung eines neuen Kubernetes-Clusters oder einer Datenbank dauert Wochen.
Platform Engineering löst das durch ein dediziertes Team, das eine gemeinsame Plattform bereitstellt. API-Gateways, CI/CD-Pipelines, Kubernetes-Cluster, Repositories, Security-Scanning, synthetische Testdaten: Alles, was Teams brauchen, steht als Self-Service-Produkt zur Verfügung. Das Plattformteam ist kein weiteres Silo. Es liefert ein Produkt, das Produktteams befähigt, sich auf Feature-Entwicklung und Kundenwert zu konzentrieren.
Dieses Konzept verwandelt eine Organisation in eine “digitale Fabrik”. Nicht im Sinne von repetitiver Fliessband-Arbeit, sondern als modernes, automatisiertes Fundament, bei dem alle langweiligen Infrastrukturaufgaben erledigt werden und Entwickler sich auf das konzentrieren können, was wirklich zählt.
Die drei Wege von DevOps#
Während der gesamten Session kam ich immer wieder auf die drei Wege von DevOps zurück. Erstens: den Arbeitsfluss durch den Wertstrom von links nach rechts optimieren. Zweitens: schnelle Feedback-Schleifen von rechts nach links schaffen, damit Probleme schnell erkannt und behoben werden. Drittens: eine Kultur des kontinuierlichen Lernens und Experimentierens fördern. Diese drei Prinzipien gelten unabhängig von Unternehmensgrösse, Branche oder regulatorischem Umfeld.
Die Baloise-Teams machten bereits Fortschritte: Sie hatten sich von monatlichen Releases auf mehrere Releases pro Woche verbessert. Einige Teams hatten Plattformteams, die ihr Continuous Delivery Tooling betrieben. Der DevOps-Geist wuchs, auch wenn noch nicht auf jeder Ebene des Unternehmens. Wie ich ihnen sagte: Es ist eine Reise der kontinuierlichen Verbesserung, und jeder Schritt vorwärts zählt.
Kernaussagen#
- Value Stream Mapping ist eines der wirkungsvollsten Werkzeuge, um Verschwendung und Engpässe im Software-Delivery-Prozess sichtbar zu machen.
- Continuous Delivery vs. Continuous Deployment: Wissen, welches Level zu den eigenen Bedürfnissen passt, und die Begriffe nicht verwechseln.
- Regulierte Branchen können DevOps einführen: Automatisierung erfüllt regulatorische Anforderungen besser als manuelle Gates, wenn man die tatsächlichen Regulierungen sorgfältig liest.
- Platform Engineering ermöglicht Skalierung, indem es die kognitive Last der Produktteams reduziert und Self-Service-Infrastruktur bereitstellt.
- Das Konzept der digitalen Fabrik bedeutet, alle Infrastrukturarbeit zu automatisieren, damit Teams sich auf den Kundenwert konzentrieren können.
- Immer fragen: Wie schnell muss das Business liefern? Geschwindigkeit ist nur wertvoll, wenn sie darauf ausgerichtet ist, echte Kundenprobleme zu lösen.