Bei dieser Veranstaltung durfte ich gemeinsam mit Carsten Brandt von SAP über DevOps in der Theorie und Praxis sprechen. Während ich die theoretischen Grundlagen von DevOps vorstellte und zeigte, wie Unternehmen von Projekten zu Produkten gelangen, brachte Carsten die Praxisperspektive aus über 21 Jahren SAP ein. Seine ehrliche Botschaft: Die Theorie steht seit Jahren, aber die Umsetzung ist alles andere als einfach, besonders in komplexen Enterprise-Landschaften.
Von Projekten zu Produkten#
Ein zentrales Problem, das ich bei vielen Unternehmen sehe, sind die sogenannten “Walls of Confusion”. Das Business schreibt Anforderungen in Word-Dokumente oder Jira-Tickets und wirft sie über die Mauer zum Entwicklungsteam. Das Entwicklungsteam implementiert, was es versteht, und reicht es weiter an das Testing. Das Testing stellt fest, dass Spezifikation und Code nicht zusammenpassen, testet trotzdem etwas, und der Betrieb fragt sich am Ende, wie er das Ganze überhaupt betreiben soll.
Die Wurzel dieses Problems liegt oft im Projektdenken. Projekte haben einen definierten Startpunkt, ein definiertes Ende, ein Budget und ein Pflichtenheft. Der Fokus liegt auf dem Output: Maximierung der Anzahl Features, User Stories und Code. Aber unsere Kunden wollen eigentlich Produkte. Sie wollen, dass wir ihre Probleme lösen. Der Fokus muss auf dem Outcome liegen, nicht auf dem Output.
“DevOps ist eine Denkweise, eine Kultur und ein Set von technischen Praktiken, welches uns erlaubt, uns rund um den Wertstrom zu organisieren und kontinuierlich Wert zu liefern.”
DevOps hilft bei diesem Wandel, indem es alle Menschen, Prozesse und Technologien zusammenbringt. Der Begriff “DevOps” ist dabei nicht ideal, weil er nur Development und Operation nennt. Eigentlich bräuchten wir einen Begriff wie “DevSecBizArchCompQAOps”, aber im Kern geht es darum: alle Beteiligten zusammenbringen, um kontinuierlich Wert zu liefern.
Die Wissenschaft hinter DevOps#
Die wissenschaftlichen Daten sind eindeutig. Unternehmen, die DevOps praktizieren, haben 208-mal häufigere Deployments in die Produktion, sind 106-mal schneller im Liefern von Features, sind 2.604-mal schneller bei der Wiederherstellung nach Ausfällen und haben eine 7-mal niedrigere Change-Failure-Rate pro Deployment. Zwischen 2019 und 2021 hat sich diese Beschleunigung sogar noch massiv verstärkt.
Ich zeigte auch das Beispiel von Tesla und Elon Musk: Am 7. Oktober 2021 rollte er den Autopiloten Version 10.2 an tausend Autobesitzer mit einem perfekten Safety Score aus. Das zeigt Canary Releases, Monitoring und modulare Software in fahrenden Autos. Am 24. Oktober machte er einen Rollback der Software in fahrenden Autos. Viele Unternehmen schaffen das nicht einmal mit ihrer regulären Software, aber Tesla macht es mit Fahrzeugen auf der Strasse.
Continuous Delivery verstehen#
Ein wichtiger Teil meiner Präsentation war die Erklärung der Continuous Delivery Pipeline. Continuous Integration bedeutet: Der Entwickler committed Code ins Source Code Repository, der Code wird reintegriert, gebaut, analysiert und getestet. Feedback kommt innerhalb von Minuten, nicht Stunden. Bei Continuous Delivery wird das Artefakt automatisch in ein Staging-Environment installiert. Bei Continuous Deployment geht es vollautomatisch in die Produktion, mit automatischen Tests und Rollback bei Fehlern.
Ebenso wichtig ist das Thema Qualität. Im traditionellen Testen nach dem V-Modell können drei bis sechs Monate vergehen, bevor ein Feature getestet wird. Beim agilen Testen mit Behaviour Driven Development schreiben wir die Akzeptanzkriterien in der “Gegeben-Wenn-Dann”-Form und leiten daraus Tests ab. So haben wir immer zuerst den Test, bevor wir den Code schreiben. Das ist das “Shift Left”, das wir erreichen wollen.
Die Praxis-Perspektive: Warum Umsetzung so schwierig ist#
Carsten Brandt brachte die ernüchternde Praxissicht ein. Seine ehrliche Ansage: “Die Theorie steht seit Jahren. Das ist alles schlüssig. Es gibt Beispiele, die das vormachen. Also müssen wir nur noch ausführen. Aber genau dieses ‘just execute’ ist das Schwierige.”
Er verwies auf eine Gartner-Studie, die zeigt, dass 75% aller DevOps-Initiativen nicht die erwarteten Ergebnisse bringen. Ein Hauptgrund: falsches oder gar kein Erwartungsmanagement. Teams sagen “wir wollen schneller liefern”, aber Schnelligkeit allein ist kein Wert. Carsten illustrierte das mit dem Monty-Python-Sketch des 100-Meter-Laufs für Menschen ohne Orientierungssinn: Alle rennen in unterschiedliche Richtungen. Schnelligkeit nützt nichts ohne das richtige Ziel.
“Das Ziel ist eigentlich glücklichere Endkunden. Und in der Softwareentwicklung erreicht man das mit besserer Software. Schnelleres Ausliefern ist nur Mittel zum Zweck.”
Systemdenken und die Einzigartigkeit jeder Organisation#
Carstens wichtigste Botschaft: Man kann nicht einfach kopieren, was Netflix, Google oder Spotify machen. Jede Organisation ist ein einzigartiges System. Die Teile eines Systems beeinflussen sich gegenseitig, und das System hat Eigenschaften, die die einzelnen Teile nicht haben. Man kann ein Teil aus System A nicht einfach in System B verpflanzen und erwarten, dass es gleich funktioniert.
Er brachte das schöne Beispiel des menschlichen Körpers: Das Herz hat kein Leben, die Lunge hat kein Leben, aber zusammen bilden sie ein System, das lebt. Genau so verhält es sich mit Organisationen. Was man tun kann, ist von anderen lernen und adaptieren, aber nicht eins zu eins kopieren.
Auch das Lehman-Gesetz der Software-Evolution kam zur Sprache: Softwaresysteme müssen kontinuierlich angepasst werden, sonst werden sie immer weniger zufriedenstellend. Gleichzeitig wächst die Komplexität exponentiell mit der Lebensdauer. Dieses Dilemma erfordert einen klaren Fokus auf die Mutter aller Software-Engineering-Fragen: Was bringt dem Kunden Wert?
Kernaussagen#
- Von Projekten zu Produkten: Der Wechsel vom Output-Fokus zum Outcome-Fokus ist entscheidend für erfolgreiche Softwareentwicklung.
- Wertstrom verstehen: Value Stream Mapping macht den gesamten Wertstrom sichtbar und deckt Engpässe auf, die man dann gezielt beseitigen kann.
- Qualität vor Geschwindigkeit: Ohne Vertrauen in die Qualität kann man nicht schneller liefern. Testautomatisierung und Shift Left sind der Ausgangspunkt.
- Jede Organisation ist einzigartig: Es gibt keinen Blueprint, der von einer Firma zur nächsten kopiert werden kann. Lernen und adaptieren ist der Weg.
- Erwartungsmanagement ist entscheidend: Die meisten gescheiterten Transformationen scheitern an falschen oder fehlenden Erwartungen, nicht an der Technologie.
- Kundenwert als Nordstern: Die zentrale Frage muss immer sein, ob die Software ein echtes Problem des Kunden löst.