Der Anfang
Wo kam der erste Systemadministrator her? Das weiß kein Mensch. Wer war der erste Entwickler? Niemand weiß es. Eines aber steht fest, auf der einen Seite war der Systemadministrator der pflegte und wartete vielerlei Gerät. Auf der anderen Seite war der Entwickler und der tat nichts als Programme zu erschaffen und Umgebungen zu konfigurieren. Was den Systemadministrator vom Entwickler trennte war der mächtige Verwalter der IT, der über Systemadministrator und Entwickler mit umfangreichen Prozessen, Regeln und vielerlei Aufträgen herrschte. Doch der Verwalter war ein gütiger Mann, der dem Systemadministrator und dem Entwickler stets die Werkzeuge zur Verfügung stellte, die ihnen gefielen. Und der Verwalter vertraute dem Administrator immer mehr Gerät zur Administration und dem Entwickler immer mehr Aufgaben zur Entwicklung an. So verhielt es sich viele Jahre während denen die Aufträge immer umfangreicher, die Systemadministration immer verantwortungsvoller und die Entwicklung immer komplexer wurden. Auch die Administratoren und Entwickler nahmen an Zahl zu, um für den Verwalter der IT Geräte zu administrieren und Programme zu schaffen. Administratoren und Entwickler richteten es sich mit den Prozessen und Regeln des Verwalters recht behaglich ein. Auch wenn die Aufgaben immer mehr und immer komplexer wurden und kaum noch zu bewältigen waren, Administratoren und Entwickler waren zufrieden mit ihren Werkzeugen. Dass die Aufgaben kaum zu bewältigen waren, Fehler und Mängel sich häuften lag sicher auch an manchem Unhold und manchem Ungeist, der sich gelegentlich mit Prozessen, Regeln und Werkzeugen eingeschlichen hatte.
Der Vampir der Veränderung
Nun erkannte der Verwalter, dass es weise wäre Systemadministratoren und Entwickler gemeinsam an den Aufgaben arbeiten zu lassen. Dadurch, so erkannte der weise Verwalter würden Geräte besser administriert und auch komplexe Programme effizienter geschaffen.
Also verkündete der Verwalter den Beschluss, dass Entwickler fürderhin als DevOps die Aufgaben bewältigen werden. Fortan sollten Entwickler auch als Administratoren, Administratoren sollten auch als Entwickler ihr täglich Werk verrichten.
Doch ohje, die Entwickler erkannten im DevOp den schrecklichen Vampir der Veränderung, der sich anschickte ihnen ihre Lieblingswerkzeuge und eingeschliffenen Prozessen wegzunehmen und drohte ihnen die Freude am Tagwerk auszusaugen. Flugs hängten sie sich Knoblauchketten um, badeten in Weihwasser, öffneten die Fenster um das Sonnenlicht in ihre Kammern einzulassen, auf dass der Vampir der Veränderung vertrieben werde.
Nun war guter Rat teuer, wie sollte der Verwalter den Entwicklern die Furcht vor dem Vampir der Veränderung nehmen?
Aber der gute Verwalter wusste Rat, statt den Entwicklern Kreuze und Holzpflöcke gegen den Vampir zu geben, verkündete er die Ziele der Transformation, gab ihnen neue Werkzeuge an die Hand, sorgte für Weiterbildung und schuf Anweisungen. So gelang es dem weisen Verwalter seine Entwickler zu überreden sich mit dem Vampir der Veränderung anzufreunden.
Der weise Verwalter der IT ließ die Entwickler wissen, welch wichtigen Beitrag sie im Prozess der Transformation leisten konnten und wie diese Veränderungen helfen würden ihr tägliches Werk zu verrichten. Auch eine DevOps-Plattform ließ der gütige Verwalter einrichten, auf daß die Entwickler weiterhin ihre liebgewonnenen Werkzeuge und Prozesse verwenden konnten.
Der Trank der Einsicht
Doch nun schreckten die Systemadministratoren auf, weil sie die Veränderungen als großes Risiko wahrnahmen. Das war auch gut so, denn es ist ja auch die Aufgabe der Administratoren ihre Geräte vor riskanten Veränderungen zu bewahren. Die Administratoren sahen sich in einen tiefen dunklen Wald der Veränderung gelockt und mit einer trickreichen hinterhältigen Hexe konfrontiert, die in einem großen Kessel einen seltsamen Trank braute. Noch bevor die Hexe dazu kam den Administratoren einen Schluck des Tranks anzubieten flohen die Administratoren voller Entsetzen.
Der weise Verwalter der IT sah dass seine Administratoren voller Furcht vor der flohen und sich ängstlich in ihren Kammern mit ihren Geräten verkrochen. Wie konnte der gute Verwalter die Administratoren davon überzeugen, vom Hexentrank der Einsicht zu trinken, auf daß sie künftig zu DevOps würden?
Der Verwalter war weise und wusste auch schon Rat. Er bezog seine Administratoren früh genug in den Prozess der Transition mit ein, öffnete die Türen für die Zusammenarbeit mit den Entwicklern und sorgte dafür, dass die Administratoren den DevOps-Gedanken verstanden. Nun da die Administratoren verstanden wie fürderhin Anwendungen entwickelt, bereitgestellt und verwaltet würden und welchen Beitrag sie dabei leisten konnten waren sie plötzlich frei von Furcht und vertrauten dem Trank der der Einsicht den die Hexe ihnen reichte.
Die Banshee der Beschuldigung
Nun da der Verwalter der IT die Tür zur Zusammenarbeit geöffnet hatte galt es, es mit einem anderen Ungeist aufzunehmen, der sich schon lange in der IT bequem eingerichtet hatte. Dieser Ungeist war die Banshee der Beschuldigung. Immer wenn ein Programm nicht das tat was es sollte kam die Banshee der Beschuldigung, ließ einen fürchterlichen Klagegesang erschallen und deutet mit ihren knöchrigen Fingern wechselseitig auf Administratoren und Entwickler. Jedermann der es versäumte rechtzeitig vor dem grässlichen Gesang und den Beschuldigungen zu fliehen musste mit furchtbaren Strafen rechnen. Zur Abwehr der Banshee der Beschuldigung schien es kein Mittel zu geben und so lebten die DevOps weiterhin in der Furcht vor Fehlern und dem Klagelied der Beschuldigung.
Der weise Verwalter hatte lange über die Banshee der Beschuldigung nachgedacht und erkannt, dass sie selbst in Furcht vor Fehlern und Beschuldigungen lebte. Also beschloss der mitfühlende Verwalter mit der Banshee zu sprechen, um zu erfahren wie sie in diesen Zustand gekommen ist. Das war der magische Schlüssel, um Perspektive, Bedürfnisse und Ängste der Banshee zu verstehen. Also ließen der gütige Verwalter und seine Devops fürderhin Empathie und Zusammenarbeit walten. Das war das Mittel gegen die Banshee-Kultur der Beschuldigung.
Die CD-Pipeline eine zerlumpte Mumie
Die DevOps arbeiteten also mit gegenseitigem Vertrauen und Einfühlungsvermögen gemeinsam an der CD-Pipeline. Und endlich konnte sie ihre CD-Pipeline in Betrieb nehmen. Nun war die Begeisterung groß über das gemeinsame Werk. Doch oh weh, in ihrem Eifer übersahen die DevOps, dass ihre CD-Pipeline nur wenige Anwendungen adressierte und nur wenige Entwickler die Vorzüge tatsächlich nutzen konnten. Also schufen die DevOps weitere CD-Piplines, die jede für nur wenige Anwendungen zuständig war. Bald glichen CD-Pipelines einer Horde liederlich gewickelter Mumien.
Der weise Verwalter sah die armen, schlampig eingewickelten Mumien und es zerriss ihm schier das Herz. Also trat er zurück und verschaffte sich einen Überblick über all die Mumien der CD-Pipelines. Schnell erkannte er, dass die DevOp-Teams eine gemeinsame Plattform benötigten, die sie in ihrem Tagwerk unterstützte ohne die Art und Weise zu ändern wie die Teams Anwendungen schufen. Also wurde eine primäre CD-Pipeline geschaffen und jedes DevOp-Team konnte weiterhin mit den eigenen liebgewonnenen Werkzeugen, Sprachen und Prozessen arbeiten und ihre Werke in die primäre kontinuierliche Bereitstellungspipeline einfließen lassen. So verwandelte sich der Haufen schlampig gewickelter Mumien in eine sorgfältig eingewickelte und glückliche CD-Pipeline-Mumie
Das geisterhafte Management
So fuhren der Verwalter der IT und seine DevOp-Teams damit fort die IT aus der tiefen Dunkelheit der konventionellen Entwicklung zu befreien und zum Licht der DevOps zu führen. Dieser Übergang war das Verdienst der tapferen DevOps die an vorderster Front sich gegen die Monster der Veränderung behaupten und diese sogar zu Freunden machen konnten.
Eines Tages begab es sich, dass aus der tiefen Dunkelheit unheimliche Geister aufzusteigen schienen und ebenfalls zum Licht der DevOps-Welt strebten. Kaum dass die unheimlichen Geister das Licht erreichten, erkannten der Verwalter über die IT und seine DevOps, dass der König und seine Fürsten vor ihnen standen. Der König hatte erkannt welche Vorzüge die DevOps-Kultur hatte und wie sie den das Glück und Wohlstand in seinem Reich vermehrte. So versprachen König und seine Fürsten sich voll und ganz der Transformation zur DevOps-Kultur zu verpflichten, auf dass jeder im Königreich am Wohlstand und Glück teilhaben möge.
Metriken des kopflosen Reiters
Da der Verwalter über die IT ein weiser Verwalter war hatte er schon Gerüchte vom kopflosen Reiter der falschen und fehlenden Metriken vernommen. So wusste er, dass Demjenigen gar fürchterliches Unheil drohte, der für fundierte Entscheidungen nicht die richtigen Metriken besaß. Ohne geeignete Metriken gleicht jeder Verwalter über die IT dem kopflosen Reiter, der einen hohlen Kürbis als Kopf auf seinen Schultern trägt. So hatte er schon früh geeignete Metriken ersonnen, die es ermöglichten die Effizienz der DevOps-Kultur zu messen und Problempunkte im DevOps-Prozess zu erkennen und zu verbessern. So konnte der Verwalter über die IT dem König und seinen Fürsten Bericht erstatten und der König ward zufrieden. Ja, der König und seine Fürsten waren so zufrieden, dass sie dem Verwalter über die IT und seinen DevOps jede Unterstützung zusagten, die benötigt wurde, um die DevOps-Kultur zu neuen Höhen zu führen und Glück und Wohlstand im Königreich zu mehren.