Mit großer Euphorie wird aktuell das Thema DevOps diskutiert. Dabei werden hohe Erwartungen an dieses Modell gestellt, wie eine deutlich bessere Softwarequalität oder eine höhere Stabilität. Ebenso wird auch von einem großen Motivationsschub für die Mitarbeiter ausgegangen.
Was genau unter dem aus Development und Operation zusammengesetzten Kunstwort DevOps verstanden wird, ist in der Branche nicht wirklich festgelegt [1], [2]. Der Kern der Überlegungen ist dabei aber immer, dass die Verantwortung für Entwicklung und Betrieb zusammengelegt werden, um die gewünschten und vor allem auch dringend notwendigen Effekte zu erzielen.
Dabei wird auch häufig von einem shift-left gesprochen: Die Betriebsverantwortung wird von rechts (Betrieb) nach links (Entwicklung) verlagert – Das ganze vor dem Hintergrund agiler Teams. Häufig gibt es schon agile Entwicklerteams in den Unternehmen, welche z. B. alle zwei Wochen eine neue Version ihrer Anwendung erstellen. Allerdings dauert es dann oft noch Monate bis diese neuen Features produktiv sind und Kundennutzen stiften.
DevOps wurde von den mächtigen Digitalfirmen wie Amazon oder Netflix geprägt. Heute wird DevOps in vielen großen Unternehmen geprüft und eingeführt. Damit fangen dann auch in der Praxis die Probleme an, welche auf eindrucksvolle Weise zeigen, welche gewaltigen Änderungen sich dahinter verbergen: Typischerweise sind die IT-Aufgaben in Großunternehmen stark nach vertikalen Gesichtspunkten untergliedert: Anforderungsmanagement, Implementierung und Betrieb.
Das hier zugrunde liegende Paradigma für die IT-Organisation ist rund 10 Jahre alt und wurde damals unter dem Titel Industrialisierung der IT diskutiert [3]. Die Idee dabei war, IT Services wie Industrieprodukte standardisiert zu managen und zu optimieren. Beispielsweise gibt es ein Support Ticket für einen Passwort Reset zum Fixpreis von 10,20 EUR – so weit, so gut.
Heute hat sich – zum Glück – die Sicht komplett gedreht: Digitalisierung ist der wesentliche Treiber. Extrem auf Arbeitsteilung basierende Industrialisierungsansätze gibt es nicht mehr – zumindest in der Literatur und Fachpresse – aber durchaus in der realen Welt der Unternehmens-IT.
Denn die über die Jahre tief eingeschliffenen Prozesse, wie etwa komplexe ITIL Prozesse über Organisationsgrenzen hinweg, sind so stark verankert, dass sich diese nicht mit einem einfachen Appell ändern bzw. komplett abschaffen lassen. Und genau hier sehe ich die große Gefahr, dass mit DevOps Initiativen in Großunternehmen in Summe eine Verschlechterung eintreten kann. Der Hauptgrund sind dabei die industrialisierten Betriebsprozesse, welche agile Entwicklungsprozesse erdrücken.
Es sind die folgenden drei Punkte, die ich als die besonders dominierenden Einflussfaktoren sehe:
Die Betriebsorganisationen haben ein großes Budget und damit einen großen politischen Einfluss.Dies führt dazu, dass die im Betrieb vorherrschenden Denkweisen und Managementmethoden auf die Entwicklung angewendet werden. Die Entwickler werden damit in ihrer Agilität ausgebremst. Die Dezentralisierung der Risiken ist schwieriger als gedacht. DevOps erfordert, dass Entscheidungen soweit wie möglich dezentral getroffen werden. In stark hierarchisch geprägten Organisationen ist es aber letztlich so, dass für kritische Entscheidungen, z. B. über eine mögliche Systemdowntime, der Mut in den Teams als auch die Werte in der Organisation noch nicht stark genug ausgeprägt sind.
Die hohen Abhängigkeiten erfordern letztlich doch komplexe Abstimmungsprozesse. Ein Merkmal von Unternehmens-IT ist die hohe Abhängigkeit und Komplexität der Systeme. Diese aufzubrechen, wird gerade erst gestartet. Microservice orientierte Architekturen sind dabei eine Möglichkeit. Aber häufig trifft man aktuell auf komplexe Abhängigkeiten.
Kurzum anstatt die avisierten Vorteile zu erzielen, kann DevOps zu einer Verschlechterung in der IT Delivery führen. Die erweiterte Verantwortung in den Entwicklungsteams kann nicht richtig im Unternehmensalltag gelebt werden. Um dennoch DevOps erfolgreich einzuführen, ist es notwendig, den Wandel aktiv zu gestalten. Dabei gibt es fünf, eng miteinander verbundene Handlungsfelder, die zu bearbeiten sind (siehe Abbildung unten)
Beispielsweise ist die neue Aufteilung der Verantwortlichkeit auch durch entsprechende Architekturen – Stichwort Microservices – zu unterstützen. Gewachsene Monolithen sind häufig schwer in einem DevOps Deliverymodell zu betreiben, da diese die Übernahme der Verantwortung durch ein kleines Team aufgrund der hohen Komplexität nicht unterstützen. Stattdessen finden sich dort heute viele Prozesse und nach Tätigkeiten organisierte Teams.
Dies, sowie die weiteren Handlungsfelder, geben noch viel Material und Diskussionsbedarf für den NTT DATA Blog.
Mich würde jetzt interessieren, wie nehmen Sie DevOps war? Ich freue mich über Ihre Kommentare.