DevOps-Performance mit einem Benchmark verbessern

DevOps-Performance messen und optimieren

Glaubt man den einschlägigen Statistiken, ist DevOps die weltweit am häufigsten praktizierte Methode für das Management von Applikationsservices. Im Idealfall ist es vielleicht sogar die beste Methode für eine Organisation – aber One-Size-fits-all-Ansätze gehen in der Regel ebenfalls mit Nachteilen einher. Die effizientesten Entwickler- und Betriebsteams haben jedoch immer einen schweren Stand, wenn das Management fehlende Transparenz beklagt und unsicher bezüglich der Performance ist. Mit einem passgenauen DevOps-Assessment lässt sich zeigen, ob sich der Change zu DevOps auszahlt – und an welchen Stellen es Reibungsverluste im Zusammenspiel gibt.

DevOps-Benchmark im Application-Management

Ziel unseres strukturierten DevOps-Benchmarks ist, Application-Management-Organisationen hinsichtlich ihrer Effizienz, Qualität, Geschwindigkeit und (Prozess)Governance zu bewerten. Während in einem klassischen Operations- oder Entwicklungs-Benchmark quantitative und qualitative Punkte anhand verschiedener Aufwandstreiber im Rahmen des Marktvergleichs analysiert werden, kommt bei DevOps die Gretchenfrage hinzu: Passt das Konzept eigentlich zu meiner (IT-)Organisation? Andersherum: Passt unser Unternehmen überhaupt zu DevOps? In stark hierarchischen Organisationen ist gegebenenfalls ein anderes Modell besser, oder es gibt keinen signifikanten Bedarf an permanenten Neuerungen, schnellen Rollouts und stetigen Deployments.

Beispiel für ein DevOps-Assessment

Für eine europäische DevOps-Organisation haben wir die Performance von DevOps analysiert und mit dem Marktniveau verglichen. Alle Teams verwenden das Scaled Agile Framework SAFe und arbeiteten auf einer eigenen, automatisierten Plattform. Die Effizienz der verschiedenen Gruppen in der Entwicklung – das zeigte sich schnell – war zweifellos sehr hoch. Ein Problem bildete jedoch die Verbindung zwischen Dev und Ops, da der Betrieb hinter der priorisierten Entwicklung zurücktrat. Hinzu kam unter anderem, dass verschiedene Tools für das IT-Service-Management (ITSM) eingesetzt wurden, was eine übergreifende Steuerung verhinderte.
Erhoben wurden die Daten für das Assessment in gemeinsamen Workshops mit den DevOps-Teams. Neben den klassischen Fragen zu Infrastruktur und Betrieb standen hier vor allem die Entwicklung und das Zusammenspiel beider Bereiche im Fokus. Relevante Punkte waren beispielsweise die Qualität des Codes, die Kritikalität der Anwendung und ihr Alter, welche vor allem im Gesamtkontext wertvolle Hinweise über den Status des Applikations-Managements geben. Anschließend wurden Data-Validation-Workshops mit den Teams abgehalten, um deren wertvolles Feedback aufzunehmen.

DevOps-Vergleiche und Kennzahlen

Bei den intern vorhandenen und gemessenen KPIs zeigte sich: DevOps als gemeinsames Organisationsprinzip ist kein Garant für die Verwendung einheitlicher Kennzahlen. Gemessen wurden in diesem DevOps-Umfeld neben den DORA-Metriken beispielsweise Flow Velocity, Item Size oder Lead Time to Customer. Das KPI-System war zentral aufgesetzt worden, allerdings zeigten einige Werte gravierende Abweichungen. So lagen in einigen Teams Aufgaben lange Zeit im Backlog, welches als „Ideenspeicher“ genutzt wurde, was durchaus so gewollt war. So ließ sich jedoch die – zentral – vorgegebene Lead Time nicht halten.

DevOps-Overhead messen oder schätzen?

Auch wurden Zeiten unterschiedlich gebucht: Mal lag der Overhead-Anteil in den Teams bei 40 Prozent, weil dort Aufwände für Run und Change hineingeflossen sind. Andere Gruppen hatten keinen Overhead angegeben oder nur grob geschätzt. In diesen Fällen ist eine Vergleichbarkeit ebenso wenig möglich wie die gezielte Optimierung. Organisationen sollten daher darauf achten, inwieweit ihre Teams einheitlich arbeiten und messen. Andernfalls sind belastbare Entscheidungen auf Grundlage dieser Datenbasis nicht möglich.

DevOps braucht eine klare Governance

Durch das DevOps-Assessment hat die IT-Leitung erkannt, dass die DevOps-Organisation aus eigenständigen Teams einen einheitlichen Rahmen für die Steuerung braucht. Die Ergebnisse des Assessments dienen nicht der Kontrolle der Beteiligten oder dem Untergraben der Selbstorganisation, sondern dem Zweck, den Teams das Leben zu erleichtern: weniger administrative Arbeit, weniger Doppelarbeit, einheitliche Tools – und mehr Zeit für Innovation. So kann die Organisation weiterhin auf eine hohe Effizienz in der Entwicklung setzen und diese auch im Kern der Idee wiederfinden: in der transparenten und steuerbaren Verbindung von Entwicklung und Betrieb. Damit im DevOps die Arbeit nicht nur effizient, sondern auch effektiv in Sinne der Unternehmensziele und Prioritäten erfolgt.