DevOps - es gibt "room for improvement"

Um schneller bessere Software auszuliefern, setzen viele Unternehmen auf die DevOps-Methode. Sie hat die Art und Weise der Software-Entwicklung deutlich verbessert, indem zuvor getrennte Rollen aus den Bereichen Development und Operations zusammengeführt und bürokratische Strukturen beseitigt wurden. Dennoch liegen Wunsch und Wirklichkeit im DevOps-Zeitalter noch weit auseinander, wie eine aktuelle Studie des Softwareanbieters LeanIX zeigt.

Der LeanIX "State of Developer Experience Survey 2022" liegen die Aussagen von 172 Fachkräften aus Software-Entwicklungsteams zugrunde. 54 Prozent der Befragten kommen aus Europa, 27 Prozent aus den USA und der Rest aus anderen Ländern. Knapp die Hälfte arbeitet in Unternehmen der Technologie- und Finanzbranche - dort also, wo die Auslieferung von Software eine besonders wichtige Rolle spielt.

Mehrheit verfügt über CI/CD-Pipelines

Zu den gegenwärtig bevorzugten Arbeitsmethoden der DevOps-Teams stellt die Studie fest, dass 58 Prozent der Befragten über CI/CD-Pipelines verfügen, mit denen Entwickler-Teams Änderungen an ihrem Code automatisiert ausführen und testen lassen. Ebenso viele bezeichnen sich als flexibel genug, um veränderte Kundenbedürfnisse schnell umsetzen zu können. Mehr als 30 Prozent fühlen sich zumindest teilweise zu beidem in der Lage, hier ergibt sich also schon ein recht hoher DevOps-Reifegrad.

Allerdings bestätigen nur 42 Prozent der Befragten, dass für ihre Entwickler das Prinzip "Build/Ship/Own your Code" voll umfassend gelte (bei weiteren 40 Prozent gilt es teilweise) - ebenfalls ein typisches Merkmal einer DevOps-Strategie. Ein weiteres Reifekriterium ist die Organisation agiler Software-Entwicklungsteams anhand von Team-Topologien. Es bietet die Möglichkeit, Arbeitsprozesse anhand eines Koordinatensystems zu optimieren.

Dabei werden vier verschiedene Typen unterschieden: Stream-aligned-Teams bilden die Basis einer Organisation. Sie sind auf Wertströme ausgerichtet und wirken am gesamten Lieferspektrum mit. Die Rolle der anderen Team-Typen wird daher im Verhältnis zu ihnen definiert. Dabei handelt es sich um Spezialisten-Teams zur Unterstützung (Enabling Teams), Plattformteams und Teams für komplizierte Teilsysteme. In 40 Prozent der Unternehmen sind solche Team-Topologien etabliert, in weiteren 43 Prozent werden sie teilweise angewandt.

DevOps-Technologie-Stack oft nicht frei wählbar

Weniger ermutigend sind die Antworten auf die Frage, ob jedes Entwickler-Team seinen Technologie-Stack frei wählen kann. Nur 18 Prozent stimmen dieser Aussage voll zu, knapp 40 Prozent verneinen das komplett. Die LeanIX-Studie zeigt also, dass für DevOpsDevOps relevante Arbeitsmethoden von nahezu allen Teams in unterschiedlicher Ausprägung eingesetzt werden. Allerdings scheint die DevOps-Kultur noch längst nicht so stark implementiert zu sein, wie es aufgrund der hohen Bedeutung der Software-Entwicklung in den Unternehmen zu erwarten wäre. Selbst CI/CD-Pipelines werden nur in gut der Hälfte der Teams vollumfänglich genutzt. Alles zu DevOps auf CIO.de

Alles in allem macht die Studie bei 53 Prozent der DevOps-Teams einen geringen Reifegrad aus. Je größer das Unternehmen, desto weniger DevOps-relevante Arbeitsmethoden werden eingesetzt. Die Studienautoren begründen das damit, dass Konzerne mit über 10.000 Mitarbeitenden komplex seien und mit dem erforderlichen kulturellen Wandel schlechter zurechtkämen. Außerdem verfügten sie häufig über Legacy-Systeme, deren Rolle für die Zukunft erst noch genauer definiert werden müsse. Generell tendierten große Organisationen eher zu einer abwartenden und prüfenden Haltung gegenüber neuen Konzepten, während Kleinbetriebe bessere Möglichkeiten hätten, nach dem Prinzip "Trial and Error" zu verfahren.

Haupthindernis ist die Automatisierung

Was sind nun die Hindernisse, die einer DevOps-Implementierung in großen wie in kleinen Unternehmen im Wege stehen? Zu automatisieren und den manuellen Aufwand zu reduzieren, halten alle Befragten für die größte Herausforderung, wobei diese je nach Reifegrad unterschiedlich bewertet wird. Teams mit einem niedrigen DevOps-Reifegrad fühlen sich dadurch zu 41 Prozent in ihrer Arbeit stark behindert.

Weitere Probleme sind das Fehlen einer gemeinsamen Wissensbasis, da sich der Abbau von Silos als zäh erweist. Zudem haben die Teams Schwierigkeiten, sich durch häufige Kontextwechsel auf ihre Aufgaben zu fokussieren. Auch das Aufdecken von Bottlenecks und Waste bereitet viel Arbeit, wobei sich hier Teams mit einem geringen Reifegrad besonders schwer tun. Die Newbies haben zudem Probleme, Projekte trotz eines fehlenden Business-Kontextes zu priorisieren. Immerhin sind sich alle Befragten einig darin, dass die Allokation von Ressourcen am wenigsten herausfordernd ist.

Um eine DevOps-Kultur im Unternehmen zu verankern, müssen Software-Entwickler und Business eine gemeinsame Sprache sprechen. Davon sind die meisten Betriebe allerdings noch weit entfernt. Nur 42 Prozent stimmen dieser Aussage voll und ganz (neun Prozent) oder weitgehend (33 Prozent) zu. Nicht viel überzeugender fallen die Antworten auf die Frage "Sind dem Team die Business-Ziele bewusst?" aus: Mit 52 Prozent bestätigt die knappe Mehrheit das ganz oder größtenteils. Etwas besser steht es um die Annahmen, dass die Leistungen der Entwicklerteams vom Business geschätzt werden (59 Prozent Zustimmung), und dass die DevOps-Kultur vom Management unterstützt wird (56 Prozent).

DevOps-Kennzahlsysteme verbesserungswürdig

Wichtig für den DevOps-Reifegrad ist auch der Einblick der Entwicklerteams in den Kundennutzen ihrer Arbeit. Dazu gilt es, bestimmte Kennzahlen zu erfassen - und das wird meistens auch gemacht. Am häufigsten werden die offenen Support-Tickets verfolgt (71 Prozent) - eine Kennziffer, die leicht zugänglich ist, allerdings auch viel Frustrationspotenzial birgt. Zwei Drittel blicken außerdem regelmäßig auf die monatlich aktiven Nutzer, eine Zahl, die allerdings genauso wenig wie die offenen Support-Tickets einen direkten Bezug zur ausgelieferten Software und deren Wert für den Kunden herstellt.

Bessere Metriken für Kundenzufriedenheit wie etwa Feature Adoption (45 Prozent), Abwanderungsquote (42 Prozent), Return on Investment (42 Prozent) oder Net Promoter Score (39 Prozent) werden jeweils von weniger als der Hälfte der Software-Entwicklungsteams betrachtet. Mit anderen Worten: Auch wenn sich die meisten Teams heute auf unterschiedlichen Leveln mit DevOps-Strategien befassen, haben sie in der Regel wenig Einblick in den Erfolg und den Kundennutzen ihrer Arbeit. Also können sie entsprechende Informationen auch nicht mit dem Business teilen. Das wäre aber wichtig, um die Kollaboration zwischen IT und Business zu verbessern.

DORA-Kennzahlen werden nur teilweise genutzt

Kommen wir zum Thema Performance-Messung der Softwareentwicklung. Dafür haben sich die KPIs des internationalen DevOps Research and Assessment Team (DORA) bewährt. Die Kriterien sind:

• Lead Time For Changes, dabei wird die Zeitspanne vom Eingang einer Anfrage bis zum Deployment auf der Basis der Zeitstempel aller inkludierten Änderungen im Deployment-Prozess ermittelt;

• Deployment Frequency: Die Häufigkeit von Deployments in die Produktionsumgebung werden erfasst. Dazu müssen die Teams definieren, was sie zum Beispiel unter einem "täglichen Deployment" mit Bezug auf die Anzahl der Wochentage verstehen. Die Werte variieren je nach Anforderungen der Teams und Services;

• Failure Rate: Diese Metrik erfasst den Anteil aller Deployments, die Ausfälle verursachen;

• Mean Time To Recovery (MTTR): Der Messwert beschreibt die Dauer der Reparaturzeit nach Auftreten eines Ausfalls.

Zu Recht weist LeanIX darauf hin, dass diese Metriken immer im Kontext betrachtet werden müssen. Es nützt nichts, wenn ein Team besonders schnell und oft deployed, dabei aber eine exorbitant hohe Fehlerrate aufweist. Die Umfrage zeigt, dass nur ein knappes Viertel der Befragten alle DORA-Kriterien erfasst und ein weiteres Viertel kein einziges. Die Entwickler schauen sich vor allem die Deployment Frequency und die Failure Rate an. Je mehr DORA-Kriterien eingesetzt werden, desto höher ist der Reifegrad der Teams und desto besser klappt das Zusammenspiel zwischen Software-Entwicklung und Business, vermerken die Studienautoren.

Jira, GitLab - und immer noch Excel

Die meisten Teams schaffen es derzeit auch nicht, die DORA-Metriken sowie die Kundenzufriedenheits-Kennzahlen nachzuverfolgen, zumal die dafür notwendigen Informationen oft auf verschiedene Datenquellen verteilt sind. Mehr als drei Viertel der Befragten, die mindestens einen der Kennwerte messen, nutzen dafür diverse Tools. Agile-Planning-Lösungen wie Jira oder Cloud-Native-CI/CD-Tools wie GitLab kommen besonders oft zum Einsatz. An dritter Stelle folgt bereits Excel, dicht gefolgt von selbst entwickelten Tools.

So seltsam das anmutet, laut LeanIX gibt es doch Sinn: Solange die vielen Datenquellen nicht miteinander verknüpft sind, muss die Erfassung manuell erfolgen. Nur 20 Prozent der Befragten setzen eine Value-Stream-Management-(VSM)-Plattform ein, um Datenströme automatisiert miteinander zu verknüpfen und den Zusammenhang zu den Geschäftsergebnissen herzustellen. Auch das VSM Consortium stellt in seinem "The State of Value Stream Management Report 2021" fest, dass die Mehrheit der Unternehmen keine dieser speziell entwickelten Plattformen nutzt.

Lesen Sie auch:

• Wie DevOps die IT beschleunigen

• Was macht ein DevOps-Engineer?

• Der DevOps-Aufwand wird unterschätzt

• Wie DevOps die App-Performance treibt