Eine detaillierte Analyse von 19 DevOps-Assessments

Ein ungeprüftes Leben ist nicht lebenswert. Eine DevOps-Bewertung verschafft einem Unternehmen einen klaren Überblick darüber, wo es bei der Einführung von DevOps aktuell steht, welche Maßnahmen es ergreifen muss und in welcher Reihenfolge, um seine Ziele zu erreichen.

Diese Analyse basiert auf den DevOps-Bewertungen, die zwischen 2016 und 2018 bei 19 finnischen Unternehmen aus folgenden Branchen durchgeführt wurden: Medien, Bauwesen, Schwerindustrie, Software, Telekommunikation, Elektrizität, Medizintechnik sowie Gesundheits- und Rentenwesen.

Die DevOps-Bewertungen wurden im Rahmen von Eficodes Service DevOps Development Plan durchgeführt.

Zunächst: Was ist eine DevOps-Bewertung?

Eine DevOps-Bewertung führt zu einem DevOps Development Plan mit priorisierten Maßnahmen für das jeweilige Unternehmen. Sie ist eine umfassende Bewertung der DevOps-Fähigkeiten eines Unternehmens. Dabei werden die eingesetzten Technologien analysiert, die Entwicklungsteams und Führungskräfte interviewt sowie Prozesse untersucht. Das Ergebnis ist eine maßgeschneiderte Roadmap für die analysierten Teams und übergeordnete Empfehlungen für das Management des Unternehmens.

Zu den bewerteten DevOps-Säulen gehören unter anderem:

Organisation

• Bei DevOps geht es darum, Silos aufzubrechen. Im Idealfall ermöglicht die Organisationsstruktur allen Bereichen der Entwicklungsorganisation eine gute Zusammenarbeit, weil Teams funktionsübergreifend sind und autonom arbeiten können.

Automatisierung

• Automatisierung reduziert manuelle Eingriffe, indem alles als Code definiert wird. So können Skripte und Tools repetitive Teile der Softwareentwicklung übernehmen, während sich Menschen auf die Wertschöpfung konzentrieren. Automatisierte Prozesse können außerdem Kundenfeedback, Entwicklungskennzahlen, Daten aus der Qualitätssicherung, Daten zum geschäftlichen Mehrwert und mehr in aussagekräftige Dashboards überführen.

Prozesse

• Die Methoden der Softwareentwicklung sind optimiert und Verschwendung wird minimiert. Entwicklung und Deployment laufen reibungslos. Sowohl die Aktualisierung auf neue Versionen als auch das Zurückrollen auf eine ältere Version sind einfach.

Kultur

• Experimente fördern neue Arbeitsweisen, und die Hürde, neue Ideen vorzuschlagen, ist niedrig. Die Kommunikation mit dem Management ist offen und stressfrei, und jeder Fehler wird als Lernchance gesehen.

Jede dieser Kategorien umfasst eine Vielzahl von Praktiken, beispielsweise unveränderliche Serverumgebungen, automatisierte Qualitätssicherung, End-to-End-Verantwortung für das Produkt und das Überwinden der Verständigungsbarrieren zwischen verschiedenen Teams.

Einige davon werden in der IT-Branche seit Jahrzehnten eingesetzt, andere gab es bis vor wenigen Jahren noch nicht. Am besten ist es, wenn eine Praktik tief im Arbeitsalltag verankert ist.

Wie weit waren DevOps-Praktiken in den 19 finnischen Unternehmen verbreitet?

Meine Untersuchung zeigte, dass selbst Praktiken, die für manche selbstverständlich sind, wie Versionskontrolle und zugängliche Dokumentation, nicht überall eingesetzt werden.

Überblick über die 19 DevOps-Bewertungen

Abbildung 1: Überblick über die analysierten DevOps-Bewertungen

Es wird deutlich, dass die bewerteten Unternehmen große Unterschiede beim DevOps-Reifegrad aufwiesen. (Siehe die Reifegradbewertungen in den letzten beiden Spalten.)

Die am weitesten verbreiteten DevOps-Praktiken

Zu den am häufigsten eingesetzten Praktiken gehören Versionskontrolle (in 12 von 19 Unternehmen) und Scrum-Praktiken (in 10 von 19 Unternehmen). Beide Praktiken sind bereits länger ein wesentlicher Bestandteil der modernen Softwareentwicklung, als es das Konzept DevOps überhaupt gibt (der Begriff DevOps wurde 2009 geprägt).

Zu den eher verbreiteten beobachteten DevOps-spezifischen Praktiken gehören eine Form von Continuous-Integration-Plattform, die durch Commits in der Versionskontrolle ausgelöst wird, sowie eine Kultur des Experimentierens (beides wurde in rund einem Drittel der Unternehmen festgestellt).

Eine Lücke in der DevOps-Praxis: Qualitätssicherung

Die Qualitätssicherung zu automatisieren und Qualität durch Quality Gates und Coding-Konventionen von Anfang an zu integrieren, ist ein sehr wichtiger Schritt. So lassen sich die Geschwindigkeit und Qualität erreichen, die DevOps verspricht.

Dennoch stellte ich fest, dass nur wenige Unternehmen diese Praktiken tatsächlich nutzten. Die meisten Tests und Code-Validierungen erfolgten weiterhin manuell – und waren damit anfällig für menschliche Fehler.

Die meisten Beobachtungen entfielen auf die Kategorie QA

Abbildung 2: Gesamtzahl der Codes je Kategorie des Code-Reifegradmodells. Vorschläge, gelb: von Eficode während des Assessments vorgeschlagen. Auf Kurs, grün: Punkte, die während des Assessments als auf Kurs eingestuft wurden. Aktuell, blau: Summe aus der Problemkategorie und der Kategorie „auf Kurs“; sie kennzeichnet die Themen, an denen derzeit gearbeitet wird.

Hier seht ihr, dass die meisten Beobachtungen auf die Kategorie QA entfielen.

Nach den Assessments wurden jedoch in der Kategorie QA die wenigsten Maßnahmen umgesetzt

Die folgende Grafik bezieht sich nicht auf die Assessments selbst. Sie basiert vielmehr auf Interviews, die ich erst längere Zeit nach den Assessments geführt habe. Sie zeigt, welche Aspekte der Assessments umgesetzt wurden. Grün bedeutet, dass eine Maßnahme vollständig umgesetzt wurde.

Abbildung 3: Anzahl der in jeder Kategorie des Reifegradmodells umgesetzten Vorschläge (basierend auf Interviews, die einige Zeit nach dem Assessment geführt wurden). Vollständig und teilweise umgesetzte Vorschläge sind bis zu einem gewissen Grad austauschbar, da einige Interviewpartner der Meinung waren, dass „nichts jemals vollständig fertig ist“, und Umsetzungen daher nicht als vollständig abgeschlossen markieren wollten.

Diese Grafik analysiert die nach dem Assessment umgesetzten Maßnahmen. Auf welche Kategorien hat sich das Unternehmen nach Erhalt seines DevOps Development Plan und seiner Roadmap konzentriert?

Wie ihr seht, hat die Kategorie QA trotz der meisten Vorschläge von uns im Vergleich zu allen anderen Bereichen die geringsten Fortschritte erzielt.

Das könnte daran liegen, dass andere Kategorien einfacher umzusetzen sind. Ich kam zu dem Schluss, dass es in den anderen Kategorien mehr Quick Wins gab, während die Kategorie QA Vorschläge enthielt, deren Umsetzung viele Ressourcen erfordert. Angesichts der grundlegenden Bedeutung von Qualität für Software ist dieser Schluss jedoch besorgniserregend.

Umfassende DevOps-Transformationen bestehen nicht nur aus Quick Wins und Ad-hoc-Lösungen. Sie müssen auch das große Ganze im Blick behalten. Nur so könnt ihr die Vorteile von DevOps als Teil des Arbeitsalltags eures Unternehmens nutzen.

Unterschiede zwischen Branchen

Ich verglich außerdem Unternehmen aus der Softwarebranche mit Unternehmen aus anderen Branchen.

Abbildung 4: Die durchschnittliche Anzahl von Problemcodes je Branche. Die auf der y-Achse genannten „Codes“ beziehen sich auf eine Datenanalysemethode namens Open Coding/Axial Coding. Sie zerlegt Daten und identifiziert wiederkehrende Konzepte, um Zusammenhänge zwischen Konzepten und Kategorien aufzuzeigen.

Hier sehen wir, dass Softwareunternehmen im Bereich QA schlechter abschneiden als andere Branchen. Wenn Software eure Kernbranche ist, liegt der Fokus darauf, so schnell wie möglich zu liefern. Das kann dazu führen, dass QA-Aspekte vernachlässigt werden. Testpraktiken entwickeln sich nicht unbedingt im gleichen Tempo weiter wie andere Faktoren, die die Geschwindigkeit erhöhen.

In Branchen wie dem Gesundheitswesen oder Bergbau müsst ihr eure Software hingegen beispielsweise nicht so häufig aktualisieren. Produkte haben längere Lebenszyklen, sodass ihr Zeit habt, bessere Quality Gates und Praktiken zu entwickeln.

Auch in der Kategorie Umgebungen und Releases sehen wir einen Unterschied. Softwareunternehmen sind hier voraus, denn für stabile und schnell weiterentwickelte Software braucht ihr eine solide Grundlage. Diese entsteht durch eine stabile Umgebung und Release-Zyklen. Wenn ein Unternehmen seine Software noch immer als Nebenprodukt betrachtet, arbeitet es möglicherweise weiterhin mit Legacy-Infrastruktur.

DevOps als Ganzes ist weniger verbreitet als seine Einzelteile

Die DevOps-Assessments zeigen, dass DevOps als Gesamtkonzept weniger verbreitet ist als seine einzelnen Bestandteile. Es ist unklar, ob Unternehmen eine umfassende DevOps-Transformation anstreben, die eine tiefgreifende kulturelle Zusammenarbeit im gesamten Unternehmen umfasst, oder stattdessen schrittweise Ad-hoc-Änderungen wählen.

Ein einzelnes Tool einzuführen, führt nicht dazu, dass ihr das volle Potenzial von DevOps ausschöpft. Doch – und das mag offensichtlich sein – wenn ihr kontinuierlich kleine Änderungen vornehmt, verbessert sich die Effizienz der Softwareentwicklung stetig.

Warum führten Unternehmen ein DevOps-Assessment durch?

Die Gründe der Unternehmen, ihre DevOps-Praktiken bewerten zu lassen, waren unterschiedlich. Am häufigsten wurde genannt, dass sie wachsen und gleichzeitig Geschwindigkeit und Qualität steigern wollten. Der CTO eines Unternehmens erklärte, dass das Unternehmen wachsen müsse und sicherstellen wollte, dass seine aktuellen Praktiken der Softwareentwicklung skalierbar sind.

Wie ist es, ein DevOps-Assessment zu durchlaufen?

Alle befragten Unternehmensvertreter empfanden die DevOps-Assessments als wertvoll.

Ziel der Assessments ist es, einen ehrlichen und wahrheitsgemäßen Überblick über die Situation der bewerteten Organisation zu geben.

Generell werden DevOps-Praktiken immer beliebter, und alle 19 finnischen Unternehmen, mit denen ich gesprochen habe, empfanden DevOps als vorteilhaft. Es war ermutigend zu sehen, dass die bewerteten Unternehmen die empfohlenen Maßnahmen umsetzten.

Dieser Beitrag basiert auf einer Masterarbeit, die ich 2018 verfasst habe.