Wahrscheinlich nicht!
Mit dem Aufkommen von Agile und DevOps sagen manche, ITIL sei tot! Stimmt das? Die kurze Antwort lautet: „NEIN!“
Wir müssen jedoch die Begründung für die Behauptung verstehen, ITIL sei irrelevant und IT Service Management (ITSM) überholt. Es stimmt durchaus, dass viele Organisationen, die „ITIL implementiert“ haben oder „ITIL-konform“ bzw. „ITIL-ausgerichtet“ sind, derzeit vor vielen Herausforderungen stehen. Dazu zählen unnötige Bürokratie, unflexible und komplexe Prozesse, veraltete Tools und Technologien, siloartige und gegeneinander arbeitende IT-Abteilungen sowie weitere gravierende Probleme und Dysfunktionen.
Es ist üblich, dass ITIL und IT Service Management (ITSM) als dogmatisch und auf starre Prozesse fixiert wahrgenommen werden. Eine weitere verbreitete Ansicht ist, dass ITIL den Betrieb gegenüber der Softwareentwicklung stark bevorzugt und daher für die „App-Leute“ nicht relevant sei.
Ein Problem der Fehlinterpretation
Viele Organisationen interpretieren ITIL-Best Practices falsch und/oder setzen ITSM-Prinzipien schlecht um. Ebenso richten viele Organisationen bei Agile ein Durcheinander an – insbesondere, wenn ihre Interpretation von Agile gleichbedeutend ist mit „aus dem Bauch heraus handeln“. In den kommenden Jahren ist es sehr wahrscheinlich, dass wir viele Organisationen sehen werden, die DevOps versuchen und dann scheitern. Doch nur weil manche Agile und DevOps schlecht umsetzen, ist das kein Urteil über diese unglaublich leistungsfähigen Konzepte. In all diesen Frameworks – ITIL eingeschlossen – gibt es mehr „Anwenderfehler“ als tatsächliche Mängel.
ITIL war nicht als Einheitslösung gedacht, die von jeder Organisation auf die gleiche Weise implementiert wird. Eines der ITIL-Mottos lautet „adopt and adapt“. Ziel dieser Aufforderung ist es, eine flexible Implementierung des ITIL-Frameworks zu fördern.
ITIL soll nicht bürokratisch sein oder Agilität und Innovation behindern. Das Gegenteil ist der Fall. ITIL fördert die Einführung neuer Technologien und Innovationen, um die Anforderungen des Unternehmens zu erfüllen und Wert für Kunden zu schaffen. ITIL-Konzepte sollten so umgesetzt werden, dass die Ergebnisse aus der Perspektive von People, Process and Technology optimiert werden.
Der vermeintliche Konflikt existiert nicht
Entgegen der landläufigen Meinung steht ITIL nicht im Widerspruch zu Agile- oder DevOps-Denken. ITIL ist außerdem nicht auf Infrastruktur oder Betrieb beschränkt. Die aktuellsten Versionen von ITIL konzentrieren sich auf End-to-End-Services. Dazu gehören in der Regel das Management von Anwendungen, Entwicklung, Infrastruktur, Betrieb sowie die Ausrichtung an Geschäftsstrategie und Kundennutzen.
Darüber hinaus verfügt ITIL über einen Entwicklungslebenszyklus, der auf Prinzipien basiert, die nahezu identisch mit dem Softwareentwicklungslebenszyklus sind, den sowohl Agile als auch DevOps verwenden. Ein großer Teil des ITIL-Lebenszyklus ist „Service Design“, und ITIL ist weitgehend agnostisch in Bezug darauf, wie Anwendungsentwicklung durchgeführt werden sollte. ITIL hat keine inhärente Präferenz für den Wasserfallansatz im Projektmanagement und unterstützt Agile ebenso wie jeden anderen möglichen Ansatz zur Gestaltung von Services oder zur Durchführung von Projekten. ITIL ist in Bezug auf Tools, Organisationsstruktur sowie die Gestaltung von Richtlinien und Verfahren überwiegend nicht präskriptiv.
Keine Inkompatibilität
Viele der in ITIL beschriebenen Best Practices und Konzepte sind ähnlich, wenn nicht identisch, mit denen, die in Agile und DevOps vertreten werden – oder sind zumindest nicht mit ITIL unvereinbar. ITIL schreibt beispielsweise nicht vor, dass Sie vierteljährliche „Big-Bang“-Releases durchführen oder einen langsamen und komplizierten Change-Management-Prozess haben müssen. ITIL ermöglicht häufige Releases und einen agilen Change-Prozess.
Das kürzlich veröffentlichte Buch Site Reliability Engineering: How Google Runs Productions Systems, beschreibt Googles DevOps-Implementierung detailliert. DevOps bei Google ist eine Mischung aus Agile-Methoden, ITIL-Best Practices, systematischer Problemlösung und Entscheidungsfindung sowie einer reifen Kultur der kontinuierlichen Verbesserung ohne Schuldzuweisungen. Natürlich basiert all dies auf Googles hochentwickelter proprietärer Technologie für Anwendungen, virtualisierte Infrastruktur, Monitoring- und Alerting-Tools usw. Google nutzt Best Practices aus einer integrierten und ganzheitlichen People-, Process- und Technology-Perspektive – ähnlich dem, was ITIL seit den 1980er-Jahren propagiert.
Google und viele andere Organisationen nutzen zwei wichtige DevOps-Konzepte – Continuous Integration und Continuous Delivery –, um häufige Releases zu fördern, in manchen Fällen Hunderte pro Tag. Diese Konzepte stehen nicht im Gegensatz zu ITIL, das nahelegen würde, dies kontrolliert mit einem Satz von Prozessen, Tools und Fähigkeiten umzusetzen, die auf die Bedürfnisse des Unternehmens abgestimmt sind. DevOps, Agile und Google sind sich darin einig.
DevOps und Agile sind nicht der „Wilde Westen“ der IT
Systematische Analyse, solide Planung und sorgfältiges Management sind erforderlich, um ein effektives und effizientes Release-Management-System aufzusetzen. Das ist wichtig, wenn das gewünschte Endergebnis ein traditioneller Ansatz mit Releases nach einem vierteljährlichen Zeitplan ist, und noch wichtiger bei einem DevOps-Modell mit dem Ziel der Continuous Delivery. DevOps und Agile sind nicht gleichbedeutend mit schlampig oder „wild-wild west“. Disziplin und Struktur sind für ITIL, Agile und DevOps essenziell. Google ist in dieser Hinsicht keine Ausnahme.
Integration von ITIL-Best Practices mit DevOps und Agile
Wie passen also Continuous Integration und Continuous Delivery zu ITIL und anderen ITSM-Best Practices?
Continuous Integration und Delivery lassen sich teilweise erreichen, indem möglichst viele Änderungen in die Kategorie Standard Change (d. h. vorab genehmigt) überführt werden. Ihre ITIL-ausgerichtete Change-Richtlinie könnte beispielsweise lauten: „Wenn der vorgeschlagene Change Request alle erforderlichen Tests besteht, ist er vorab genehmigt und kann ohne zusätzliche Freigaben oder Managementaufsicht umgesetzt werden“ (wodurch Ihr typisches wöchentliches Change Advisory Board usw. umgangen wird). Ein weiterer ergänzender Ansatz besteht darin, so viele Genehmigungspunkte wie möglich im Change-Management-Prozess zu automatisieren.
Automatisierung ist entscheidend
Automatisierte Tests und Monitoring gibt es schon lange und werden von ITIL-Best Practices vollständig unterstützt. DevOps geht hier nur einen Schritt weiter. Bei DevOps besteht das Ziel darin, automatisierte Test- und Monitoring-Funktionen so früh wie möglich in den Entwicklungslebenszyklus zu integrieren. In den Code integrierte automatisierte Tests ermutigen den Programmierer, Anwendungen zu entwickeln, die nahezu alles erkennen können, was potenziell im System schiefgehen könnte. Wenn der Programmierer wirklich versiert ist, versucht er sogar, eine Lösung einzubauen, die alle erkannten Probleme automatisch behebt – ohne dass irgendein menschliches Eingreifen erforderlich ist (und ohne dass ein neues Incident-Ticket erstellt werden muss – obwohl das System im Event-Management-System eine informative Meldung erzeugen könnte).
DevOps ist für Altsysteme in der Regel nicht gut geeignet
Damit gesagt: Vergessen wir nicht, dass es in vielen Organisationen nicht immer realistisch oder vorzuziehen ist, Agile oder DevOps in jeder Situation einzusetzen. Was ist mit Altsystemen? Was ist mit Systemen, die weder virtualisiert noch cloudbasiert sind? Was, wenn Ihre Organisation noch nicht bereit ist für Agile oder DevOps, weil es an den notwendigen Fähigkeiten, Tools, kultureller Reife, Organisationsstruktur usw. fehlt? Traditionelles ITIL und/oder andere verwandte Service-Management-Frameworks sind nach wie vor einige der besten Wege, um das Management von Legacy-IT-Systemen und -Services zu bewältigen.
Fazit: In vielen Organisationen ist es sinnvoll, eine Kombination von Ansätzen zu nutzen: ITIL für bestimmte Themen, Agile für einen Teil der Entwicklung, Waterfall für andere Projekte und DevOps in bestimmten Situationen, in denen die Rahmenbedingungen es zulassen (zum Beispiel durch einen Pilotbetrieb oder indem DevOps nur für neue Produkte und digitale Services eingesetzt wird).
Ist ITIL also tot? Nein! Es ist weiterhin relevant und in manchen Fällen heute mehr denn je erforderlich.
