Die DevOps-Blase

DevOps-Einführung im Rahmen eines Leuchtturm-Projektes

Wie in DevOps Strategies geschrieben und in meinem Blog-Beitrag DevOps and Continuous Delivery in corporations – the myth of prescribed agility kommentiert, sollte nicht versucht werden, DevOps & Continuous Delivery einfach „von oben herab“ anzuordnen und z.B. in einem Schritt flächendeckend in einer Organisation zu etablieren zu wollen.

Der genau umgekehrte Ansatz wäre, zunächst mit nur einem ersten System die DevOps-Einführung zu beginnen. Das funktioniert allerdings auch nicht von alleine – auch dieser Ansatz ist nicht unproblematisch und es müssen hierbei einige Punkte beachtet werden.

Obwohl die Wahrheit „irgendwo“ in der Mitte zwischen den beiden genannten Ansätzen liegt, findet die Idee eines einzelnen Leuchtturm-Projektes sehrt oft großen Zuspruch, denn sie verspricht, sich bei der Einführung von DevOps und Continuous Delivery auf ein einzelnes Produkt und dessen Erfolg fokussieren zu können.

Der Leuchtturm-Ansatz hat zur Folge, dass die Erwartungen an den Erfolg im Sinne der einzusetzenden DevOps- und Continuous Delivery-Praktiken bei einem solchen „Leuchtturmprojekt“ zumeist besonders hochausfallen.

Weiterhin verspricht man sich von einem Leichtturm-Projekt mit hoher Komplexität den Nachweis, dass es möglich ist, eine Continuous Delivery Pipeline mit der in der Organisation notwendigen Komplexität zu erstellen – und zu betreiben.
Und nebenbei soll dieser initiale Beweis für alle weiteren Produkte gelten.

Dies rührt nicht zuletzt auch daher, dass zumeist eine Vielzahl vorhandenen Kritiker aus der „alten Welt“ überzeugt werden sollen. Dies gilt auch für die Anforderungen an das Endprodukt – insbesondere dann, wenn im Rahmen der DevOps-Einführung ein wichtiges Altsystem ersetzt werden soll.

The second system syndrom

Für den genannten Ansatz, ein erfolgreiches Altsystem zu ersetzen sprechen oft mehrere Gründe:
Das Altsystem ist von seiner Architektur und Auslegung den wachsenden Anforderungen in Bezug auf Durchsatz, Anwenderanzahl und regionale Verteilung nicht mehr gewachsen – und nicht mehr skalierbar.
Das Altsystem generiert einen Großteil des Umsatzes und hat einen festen Kundenstamm, der seine eigenen Geschäftsprozesse auf das besagte Altsystem ausgerichtet hat.

Diese Erwartungsverhalten muss im Falle eines einzelnen DevOps-Projektes, auf das sich dann alle Augen richten, von ebendiesem Projekt Gemeistert werden.

Anmerkung:
Dies ist nicht erst seit DevOps so: Auch in der Vergangenheit wurde ich mehrfach mit diesem Muster konfrontiert, dass die Neueinführung einer neuen Technologie oder Prozesses im Rahmen eines Leuchtturmprojektes durchgeführt werden sollte.

Insgesamt soll bei der DevOps/Continuous Delivery-Einführung neben den eigentlichen Aufgaben (Automatisierung, Kultur-Wechsel) „nebenbei“ noch folgendes geleistet werden:

  • Neue Entwicklungsprozesses (Z.B. strikte Agilität, die nicht nur von Entwicklern gelebt, sondern auch von allen Beteiligten verstanden werden muss)
  • Neue Technologie- und damit zusammenhängende Architektur-Paradigmen Viele Altsysteme weisen Client-Server-Architekturen auf und basieren auf RDBMS – Im DevOps-Umfeld finden Micro-Service-Architekturen und NoSQL Datenhaltungsverfahren großen Zuspruch, da diese sich gut für das Continuous Deployment eignen.
  • Vollständige Automatisierung der Deployment- und Testprozesse Damit zusammenhängende werden an Mitarbeiter neue und höhere Anforderungen gestellt, Insbesondere an die QS-Abteilung.
  • Geschäftskritische Anwendungen werden erstellt oder ersetzt.

Im Falle einer Neuimplementierung kommt erschwerend das Second-System Syndrom hinzu:

  1. Zu den funktionalen Features, die mittels DevOps neuimplementierte werden sollen, kommen nach und nach neue Anforderungen hinzu mit dem Ziel, die Unzulänglichkeiten des Altsystems auszugleichen. Theoretisch lässt sich ein solcher Scope Creep durch ein stringentes Anforderungsmanagement in Verbindung mit agilen Prozessen wie SCRUM verhindern bzw. auf ein unausweichliches Maß zu reduzieren. In der Praxis zeigt sich aber, dass die Stakeholder einen erheblichen Druck auf Verbesserungen ausüben, zumal dann, wenn es zu Verzögerungen im DevOps-Einführung kommt. Als Ausgleich werden dann oft Zusagen in Bezug neue Features gemacht.
  2. Weiterhin ist es selbst ohne Scope Creep bei der Neuimplementierung komplexen traditionellen Systemen extrem schwer, das Altsystem mit all seiner relevanten Funktionalität und den inhärent vorhandenen Prozessen neu auferstehen zu lassen. Ein über Jahre lang entwickeltes System hat eine Vielzahl von Iterationen, Wartungs- und Korrektur-Zyklen hinter sich. Darin verbirgt sich extrem viel Know-How, dass über die Zeit aufgebaut und implementiert wurde, jedoch durch Fluktuation in den für das Altsystem zuständigen Teams nicht mehr abrufbar ist – trotz aller Dokumentation. Im für das Neu-System verantwortlichen Team ist dies noch weniger der Fall.

Dies sollte eigentlich offensichtlich sein, trotzdem kommt es immer wieder zu derartigen Leuchtturm-Projekten in Verbindung mit der Einführung neuer Vorgehensweisen und Technologien.

Ein anderer Ansatz könnte sein, das Altsystem zu zerlegen bzw. einzelne zu ersetzende Teile im Altsystem „abzuschalten“ und durch mittels DevOps und Continuous Delivery gestaltetet Produkte ersetzt werden.

Eine weitere Problematik mit Leuchtturmprojekten besteht in der Einzigartigkeit des „DevOps-Projektes“, das dadurch in einer Blase existiert.

Oftmals wird deshalb Anfangs von allen Beteiligten angenommen bzw. gefordert, das DevOps-Projekt auf der „grünen Wiese“ durchführen zu können. Dies bedeutet, dass möglichst keine komplexen Schnittstellen zu Altsystemen existieren, mit Ausnahme z.B. einer initialen Stammdatenübername.
Es kommt in solchen Situationen allerdings dazu, die grüne Wiese als Voraussetzung für die Machbarkeit im Rahmen des Budget und des Zeitplans fest einzuplanen. Mit der Zeit, insbesondere wenn sich in der alten Welt außerhalb der DevOps-Blase ändert, wird diese zugrundeliegende Annahme oft hinfällig und damit der gesamte Zeit- und Budget-Plan des Leuchtturm-Projektes.

Die Blase schrumpft

Die folgenden Einflussfaktoren können zum Zusammenziehen der DevOps-Blase führen:

Personelle Inselsituation

Die Personalsituation kann sich ändern, wenn sowohl Mitglieder des Leuchtturm-Projektes das Projekt verlassen bzw. ausfallen oder vermehrt benötigt werden. In diesem Fall existiert außerhalb der DevOps-Blase innerhalb der Organisation kein Know-How in Bezug auf DevOps, Continuous Delivery, die neue Technologie oder (agilen) Entwicklungsprozesse, die das Leuchtturm-Projekt auszeichnen.
Kann in einem solchen Falle kein personeller Ersatz beschafft werden bzw. dieser nicht zügig eingearbeitet werden, kommt es zu Zeitverzug und Budget-Überzug durch Ineffizienz und Ineffektivität – die DevOps-Blase schrumpft..

Dieser Vorgang setzt sich fort, wenn aufgrund der aufkommenden Notwendigkeit, doch Schnittstellen zu Altsystemen zu integrieren, auch Synchronität mit den Release-Prozessen der Altsysteme notwendig wird – hier werden u.U. die DevOps und CALMS-Anforderungen

Entwicklungsinsel

Dann werden auch die Entwicklungsprozesse in der DevOps-Bubble zunehmend verwässert bzw. an die u.U. noch nicht agile Außenwelt angepasst – oder das Prinzip der Automatisierung beim Deployment und beim Testen wird durchbrochen -es werden z.B. manuelle Änderungen auf der Produktivumgebung ausgeführt. Die DevOps-Blase schrumpft somit weiter.

Kulturinsel

Dazu kommt, dass die DevOps zugrunde liegende Kultur und Prinzipien („CALMS“ Culture / Automation / Lean / Measurement / Sharing) nur in der DevOps-Blase gelebt wird und außerhalb derselben nahezu unbekannt ist oder sogar abgelehnt wird. Dies untergräbt die Verwirklichung der CALMS-Prinzipien nicht nur in der DevOps-Base. Die DevOps-Blase schrumpft noch weiter

Kein Vertrauens-Zufluss

Solange das initiale DevOps/CD-Projekt noch das Einzige Projekt ist und das bisher gelieferte Produkt noch nicht den Erwartungen an das Endprodukt entspricht, hat DevOps in der besagten Organisation seine Existenz (noch) nicht gerechtfertigt. Bei der o.g. überzogenen Erwartungshaltung seitens der Stakeholder oder Verzögerungen, gerät ein solches Leuchtturm-Projekt leicht fundamentalkritischen Beschuss.
Am Ende unterschreitet das vorhandene Vertrauen in das Leuchtturm-Projekt das zu seinem Erfolg notwendige Mindestmaß – Es kommt zur Einstellung des Projektes oder zum „schleichenden Herztod“ (Fluktuation der Mitarbeiter, fortwährende Budget-Kürzungen). Die DevOps-Blase platzt.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.