Wir saßen an einem Tisch. Ich befand mich in einem Co-Working-Space, der Arbeitnehmer aus verschiedenen Branchen vereinte, die bereit waren, ihr Wissen und ihre Fähigkeiten mit anderen Fachleuten aus anderen Unternehmen zu teilen. Das war eine neue Erfahrung für mich. Es war 2014 und ich hatte gerade meine ITIL-V3-Zertifizierung erhalten. Ich habe die Ausbildung von 60 meiner Kollegen vorbereitet.
Ein junger Mann, frisch von der Schule, monopolisiert nicht so sehr die Aufmerksamkeit als vielmehr das Gespräch, überzeugt davon, dass er der ganzen fröhlichen Versammlung etwas zu sagen hat… Seine Rede ist ziemlich bestimmend, er wirkt recht selbstbewusst und hat den starken Wunsch, ITIL zu kritisieren…
Ich höre ihn sagen: „Wir müssen unbedingt die Bürokratie beseitigen, die durch die Umsetzung von ITIL in den Organisationen entsteht. Ich vertrete ein Dienstleistungsmanagement, das viel flexibler und effektiver ist. Mein Referenzsystem ist einfach zu implementieren und wird ITIL, das zu viel kostet und Unternehmen in schwerfälligen und unnötigen Prozessen festhält, schnell ersetzen. Alle, die ITIL einführen, bereuen es, weil sie heute gerne aussteigen würden und die Möglichkeit dazu nicht mehr haben.“
Ich hatte gerade eine Woche meiner Zeit investiert und stand kurz davor, einen Auftrag im Wert von 40.000 € zu unterschreiben, um ein ganzes Team in den besten ITIL-Verfahren zu schulen. Sie können sich meine Beunruhigung vorstellen. Gleichzeitig wollte ich aber mehr wissen.
Ich habe daher einige kurze Fragen gestellt:
- Wie lösen Sie Vorfälle entsprechend Ihrem Rahmen?
- Nun, es gibt keine Erklärung, also ist eine Rückkehr zu Excel mehr als genug.
- Wow… Gibt es also ein vorgeschaltetes Risikomanagement, eine proaktive Lösung für potenzielle Zwischenfälle auf der Grundlage von Ereignissen?
- Nicht einmal, Systeme sind von Natur aus stabil…
- OK, gut, und das ist einer Reihe von besonderen technischen Entscheidungen zu verdanken?
- Ja, natürlich, aber hauptsächlich dank einer Entwicklungsmethode, die jeden Fehler an der Quelle ausschließt…
- Eine Agile Methode?
- Was, es gibt noch andere Entwicklungsmethoden?
Da dachte ich: ‚Lass uns weitermachen!‘
- Sagen Sie mir, haben Sie konkrete Beispiele von Organisationen, die in ITIL feststecken und daraus herauskommen möchten? Ich wäre an ihren Erfahrungen interessiert, um dieselben Fehler in meinem Dienst zu vermeiden.
- Nun, ich habe es bereits gesagt, alle!
In diesem Moment wurde mir klar, dass ich es mit einem genialen jungen Mann zu tun hatte, der es gewohnt war, zu argumentieren und zu reden, der aber keinerlei Erfahrung und Kenntnisse im Dienstleistungsmanagement hatte. Ich ließ die Diskussion so enden und verschob die Fortsetzung meiner Befragung später.
Auf dem Rückweg zu unserem Arbeitsplatz sprach ich ihn an und fragte ihn nach dem Namen dieser magischen Best Practice. Er antwortete mir ablenkend: Es heißt „DevOps“. Dies war mein erster Kontakt mit DevOps, und ich hatte den Eindruck, dass dieser Mann die Lektionen seines Gurus zwar gut gelernt, aber die Essenz nicht erfasst hatte. Also habe ich auf eigene Faust recherchiert… einen guten Weg gefunden und bin schließlich in die DevOps-Welt eingestiegen, ohne jemals ITIL zu verlassen.
Zu dieser Zeit gab es nur sehr wenige Unterlagen zu diesem Thema. Am Anfang waren es nur gute Ideen, die zusammen ein Magma voller guter Absichten bildeten, deren enormes Potenzial wir nur erahnen konnten.
In diesem Jahr wurde die erste Formalisierung vorgenommen. Ein Buch über IT und DevOps mit dem Titel „Das Phoenix-Projekt“. Die Geschichte der Transformation eines Unternehmens durch die radikale Umstellung seiner IT-Dienste. Die Lektüre dieses Buches ist so, als ob man Erfahrungen sammelt, ohne etwas zu tun: Es ist sehr lehrreich.
Es stimmt, dass zu Beginn des Buches einige ITIL-Prozesse wegen ihrer Komplexität kritisiert werden, aber in einigen Fällen ist es nicht empfehlenswert, sie ganz abzuschaffen. Im weiteren Verlauf des Buches wird deutlich, welchen wesentlichen Einfluss Best Practices wie ITIL auf den Erfolg der DevOps-Transformation haben, aber auch, wie wichtig es ist, aus diesen Best Practices alles zu eliminieren, was keinen Wert schafft. Wir können dann zu einem Lean-ITIL-Konzept übergehen und einen Teil des Weges zu DevOps zurücklegen.
Im Laufe der Zeit hat DevOps an Reife gewonnen, ebenso wie seine Anwender und Experten, und auf den ersten Seiten der „Foundations“-Schulung wird klar gesagt, dass die drei Inspirationsquellen für DevOps ITIL, Lean und Agilität sind. Um noch ein wenig mehr zu betonen: Die Veralterung von ITIL wird als einer der falschen Mythen über DevOps angesehen. Ich bin der festen Überzeugung, dass IT Service Management und die DevOps-Bewegung keine Gegensätze sind. Im Gegenteil, sie bieten eine perfekte kulturelle Verbindung (dies sind die Worte von Gene Kim, Autor – zusammen mit anderen – des Phoenix-Projekts und des DevOps-Handbuchs, einer kostenlosen Übersetzung des Autors dieses Artikels).
Dieses Zitat stammt aus der Zeit vor der Veröffentlichung von ITIL 4…, das agiler wurde. Wenn DevOps dem Interesse an ITIL V3 keinen Abbruch getan hat, dann gilt das natürlich auch für ITIL 4.
Für die IT-Dienste bleibt es daher unerlässlich, die ITIL-Praktiken zu beachten und anzuwenden, um DevOps erfolgreich nutzen zu können.
Ich denke oft an diesen Jungen zurück. Ich kann ihm nur danken, dass er diese Befragung initiiert hat. Ich mache ihm keinen Vorwurf wegen seiner sorgenfreien Leichtigkeit… Im Gegenteil, ich wünsche ihm, dass er im gleichen Tempo reift wie die Bewegung, die wir heute gemeinsam vertreten.
