Eine detaillierte Analyse von 19 DevOps-Assessments

Ein ungeprüftes Leben ist nicht lebenswert. Ein DevOps Assessment gibt 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 sein Ziel zu erreichen. 

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

Die DevOps Assessments wurden im Rahmen des Eficode DevOps Development Plan Service durchgeführt. 

Zunächst: Was ist ein DevOps Assessment?

Ein DevOps Assessment führt zu einem DevOps Development Plan mit priorisierten Maßnahmen für das jeweilige Unternehmen. Dabei werden die DevOps-Fähigkeiten des Unternehmens umfassend bewertet. Das Assessment analysiert die eingesetzte Technologie und umfasst eine Reihe von Interviews mit dem Entwicklungsteam und der Führungsebene sowie eine Untersuchung der Prozesse. 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 zu überwinden. Im Idealfall ermöglicht die Organisationsstruktur allen Bereichen der Entwicklungsorganisation eine Zusammenarbeit, weil die 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 wiederkehrende Teile der Softwareentwicklung übernehmen, während sich Menschen auf die Schaffung von Mehrwert konzentrieren können. Automatisierte Prozesse können zudem Kundenfeedback, Entwicklungsmetriken, 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 das Upgrade auf neue Versionen als auch das Zurückrollen auf eine ältere Version ist einfach.

Kultur

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

Jede dieser Kategorien umfasst zahlreiche Praktiken, etwa unveränderliche Serverumgebungen, automatisierte Qualitätssicherung, durchgängige Verantwortung für das Produkt und den Abbau von Verständnishürden zwischen verschiedenen Teams.

Einige davon werden in der IT-Branche seit Jahrzehnten breit eingesetzt, andere gab es vor wenigen Jahren noch nicht. Am besten ist es, wenn eine Praxis fest 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 Assessments

Abbildung 1: Überblick über die analysierten DevOps Assessments

Es zeigt sich, dass die bewerteten Unternehmen sehr unterschiedliche Reifegrade bei DevOps 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 schon länger ein wesentlicher Bestandteil moderner Softwareentwicklung, als das Konzept DevOps überhaupt existiert (der Begriff DevOps wurde 2009 geprägt).

Zu den beobachteten, mäßig verbreiteten DevOps-spezifischen Praktiken gehören eine Form von Continuous-Integration-Plattform, die durch Commits in der Versionskontrolle ausgelöst wird, sowie eine Experimentierkultur. Beides wurde in etwa 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 mitzudenken, 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. Der Großteil der Tests und Code-Validierungen erfolgte weiterhin manuell – und war damit anfällig für menschliche Fehler.

Die meisten Beobachtungen wurden in der Kategorie QA gemacht

Abbildung 2: Gesamtzahl der Code-Gruppen in den einzelnen Kategorien des Code-Reifegradmodells. Vorschläge, gelb: von Eficode während des Assessments eingebrachte Vorschläge. Auf Kurs, grün: Themen, die während des Assessments als auf Kurs eingestuft wurden. Aktuell, blau: die Summe aus Problemkategorie und Kategorie „auf Kurs“; sie zeigt Themen, an denen derzeit gearbeitet wird.

Hier seht ihr, dass die meisten Beobachtungen in der Kategorie QA gemacht wurden.

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

Die folgende Grafik bezieht sich nicht auf die Assessments selbst. Sie basiert vielmehr auf Interviews, die ich lange nach den Assessments geführt habe. Sie zeigt, welche Aspekte der Assessments umgesetzt wurden. Grün bedeutet, dass eine Maßnahme vollständig abgeschlossen 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 argumentierten, dass „nie etwas vollständig fertig ist“, und sich daher weigerten, Umsetzungen als vollständig abgeschlossen zu markieren.

Diese Grafik analysiert die Maßnahmen, die nach dem Assessment verändert wurden. 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 allen Bereichen die geringsten Fortschritte gemacht.

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 grundsätzlichen Bedeutung von Qualität für Software ist diese Schlussfolgerung 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 lassen sich 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 Problem-Codes pro Branche. Die auf der y-Achse erwähnten „Codes“ beziehen sich auf eine Datenanalysemethode namens Open Coding/Axial Coding. Dabei werden Daten aufgeschlüsselt und wiederkehrende Konzepte identifiziert, um Beziehungen zwischen Konzepten und Kategorien aufzuzeigen.

Hier sehen wir, dass Softwareunternehmen im Bereich QA schlechter abschneiden als Unternehmen anderer Branchen. Wenn Software eure Hauptbranche ist, liegt der Fokus darauf, so schnell wie möglich auszuliefern. Dabei können QA-Aspekte ins Hintertreffen geraten. Testpraktiken entwickeln sich nicht zwangsläufig im gleichen Tempo weiter wie andere Faktoren, die die Geschwindigkeit erhöhen.

In Branchen wie dem Gesundheitswesen oder Bergbau müsst ihr eure Software dagegen 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 liegen hier vorn, denn für stabile Software, die sich schnell weiterentwickelt, braucht ihr eine solide Grundlage – mit einer stabilen Umgebung und verlässlichen Release-Zyklen. Wenn ein Unternehmen seine Software weiterhin als sekundäres Produkt betrachtet, begnügt es sich möglicherweise mit Legacy-Infrastruktur.

DevOps als Ganzes ist weniger verbreitet als seine einzelnen Bestandteile

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 zum vollen Potenzial von DevOps. Doch – und das liegt vielleicht auf der Hand – wenn ihr kontinuierlich kleine Änderungen vornehmt, verbessert sich die Effizienz der Softwareentwicklung stetig.

Warum ließen Unternehmen ein DevOps-Assessment durchführen?

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 man sicherstellen wolle, dass die bestehenden Praktiken der Softwareentwicklung skalierbar sind.

Wie läuft ein DevOps-Assessment ab?

Alle befragten Unternehmensvertreter empfanden die DevOps-Assessments als hilfreich.

Ziel der Assessments ist es, einen ehrlichen und wahrheitsgetreuen Ü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 empfohlenen Maßnahmen von den bewerteten Unternehmen umgesetzt wurden.

Dieser Beitrag basiert auf meiner Masterarbeit aus dem Jahr 2018.