Das Ende von ITIL?

Wahrscheinlich nicht!

Mit dem Aufkommen von Agile und DevOps sagen einige Leute, dass ITIL tot ist! Stimmt das? Die kurze Antwort lautet "Nein"!

Wir müssen jedoch die Gründe für die Behauptung der Irrelevanz von ITIL und der Veralterung des IT-Service-Managements (ITSM) verstehen. Es ist sicherlich richtig, dass viele Organisationen, die ITIL "implementiert" haben oder "ITIL-konform" oder "ITIL-ausgerichtet" sind, derzeit mit vielen Herausforderungen konfrontiert sind. Zu diesen Problemen gehören unnötige Bürokratie, unflexible und komplexe Prozesse, veraltete Tools und Technologien, isolierte und verfeindete IT-Abteilungen sowie andere wichtige Probleme und Funktionsstörungen.

ITIL und IT Service Management (ITSM) werden häufig als dogmatisch und auf starre Prozesse fixiert angesehen. Eine weitere weit verbreitete Auffassung ist, dass ITIL stark auf den Betrieb und nicht auf die Softwareentwicklung ausgerichtet ist und daher für die "App-Jungs" nicht relevant ist.

Ein Problem der Fehlinterpretation

Viele Organisationen legen die bewährten ITIL-Verfahren falsch aus und/oder setzen die ITSM-Grundsätze schlecht um. Ähnlich verfahren viele Organisationen mit Agile, insbesondere wenn ihre Interpretation von Agile gleichbedeutend ist mit "aus der Hüfte schießen". In den kommenden Jahren werden wir höchstwahrscheinlich erleben, dass viele Organisationen DevOps ausprobieren und dann scheitern. Die Tatsache, dass einige Unternehmen Agile und DevOps schlecht implementieren, sollte jedoch kein Vorwurf an diese unglaublich leistungsfähigen Konzepte sein. In jedem dieser Frameworks - einschließlich ITIL - gibt es mehr "Benutzerfehler" als Mängel.

ITIL war nicht dazu gedacht, eine Einheitsgröße für alle Lösung, die von jeder Organisation auf die gleiche Weise implementiert wird. Eines der ITIL-Mottos lautet "übernehmen und anpassen". Der Zweck dieser Ermahnung ist es, eine flexible Umsetzung des ITIL-Rahmens 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 Bedürfnisse des Unternehmens zu erfüllen und einen Mehrwert für die Kunden zu schaffen. ITIL-Konzepte sollten so implementiert werden, dass die Ergebnisse in Bezug auf Menschen, Prozesse und Technologie optimiert werden.

Angenommener Konflikt existiert nicht

Entgegen der landläufigen Meinung steht ITIL nicht im Widerspruch zu agilem oder DevOps-Denken. ITIL ist auch nicht auf die Infrastruktur oder den Betrieb beschränkt. Die meisten aktuellen Versionen von ITIL konzentrieren sich auf End-to-End-Services. Dazu gehören in der Regel das Management von Anwendungen, Entwicklung, Infrastruktur und Betrieb sowie die Ausrichtung auf die Geschäftsstrategie und den Kundennutzen.

Darüber hinaus verfügt ITIL über einen Entwicklungslebenszyklus, der auf Prinzipien basiert, die fast identisch sind mit dem Lebenszyklus der Softwareentwicklung, der sowohl von Agile als auch von DevOps verwendet wird. Ein großer Teil des ITIL-Lebenszyklus ist das "Service Design", und ITIL ist in Bezug auf die Art und Weise, wie die Anwendungsentwicklung durchgeführt werden soll, ziemlich agnostisch. ITIL hat keine inhärente Vorliebe für den Wasserfall-Ansatz im Projektmanagement und unterstützt Agile ebenso wie jeden anderen möglichen Ansatz für das Design von Services oder die Durchführung von Projekten. ITIL ist meist nicht präskriptiv, wenn es um Werkzeuge, Organisationsstrukturen und die Gestaltung von Richtlinien und Verfahren geht.

Keine Unvereinbarkeit

Viele der in ITIL beschriebenen Best Practices und Konzepte ähneln denen von Agile und DevOps, wenn sie nicht sogar identisch sind - oder sind zumindest nicht unvereinbar mit ITIL. ITIL sagt zum Beispiel nicht, dass man vierteljährliche "Big Bang"-Releases durchführen oder einen langsamen und komplizierten Change-Management-Prozess haben muss. ITIL erlaubt häufige Releases und einen flinken Änderungsprozess.

Das kürzlich veröffentlichte Buch, Technik für Standortzuverlässigkeit: Wie Google seine Produktionssysteme betreibt, beschreibt die DevOps-Implementierung von Google im Detail. DevOps bei Google ist eine Mischung aus agilen Methoden, bewährten ITIL-Verfahren, systematischer Problemlösung und Entscheidungsfindung sowie einer ausgereiften Kultur der kontinuierlichen Verbesserung ohne Schuldzuweisungen. Natürlich läuft all dies auf Googles hochentwickelter proprietärer Technologie für Anwendungen, virtualisierte Infrastruktur, Überwachungs- und Alarmierungs-Tools usw. Google nutzt Best Practices aus einer integrierten und ganzheitlichen Perspektive von Menschen, Prozessen und Technologie, ähnlich dem, was seit den 1980er Jahren von ITIL empfohlen wird.

Google und viele andere Unternehmen nutzen zwei wichtige DevOps-Konzepte - kontinuierliche Integration und kontinuierliche Bereitstellung -, um häufige Veröffentlichungen zu fördern, in manchen Fällen Hunderte pro Tag. Diese Konzepte stehen nicht im Widerspruch zu ITIL, das vorschlägt, dass dies auf kontrollierte Weise mit einer Reihe von Prozessen, Tools und Fähigkeiten geschieht, die auf die Bedürfnisse des Unternehmens abgestimmt sind. DevOps, Agile und Google stimmen alle zu.

DevOps und Agile sind nicht der "Wilde Westen" der IT

Eine systematische Analyse, eine solide Planung und ein sorgfältiges Management sind erforderlich, um ein effektives und effizientes Release-Management-System einzurichten. Dies ist wichtig, wenn das angestrebte Endergebnis ein traditioneller Ansatz zur Durchführung von Releases nach einem vierteljährlichen Zeitplan ist, und es ist sogar noch wichtiger, wenn ein DevOps-Modell mit dem Ziel einer kontinuierlichen Bereitstellung verwendet wird. DevOps und Agile sind nicht gleichbedeutend mit Schlamperei oder "wildem Westen". Disziplin und Struktur sind für ITIL, Agile und DevOps unerlässlich. Google ist in dieser Hinsicht keine Ausnahme.

Integration von ITIL-Best-Practices mit DevOps und Agile

Wie passen also kontinuierliche Integration und kontinuierliche Bereitstellung zu ITIL und anderen bewährten ITSM-Verfahren?

Kontinuierliche Integration und Bereitstellung lassen sich zum Teil dadurch erreichen, dass möglichst viele Änderungen in die Kategorie Standardänderungen (d. h. vorab genehmigte Änderungen) verschoben werden. Ihre ITIL-konforme Änderungsrichtlinie könnte zum Beispiel lauten: "Wenn die vorgeschlagene Änderungsanforderung alle erforderlichen Tests besteht, ist die Implementierung der Änderungsanforderung ohne zusätzliche Genehmigungen oder Managementaufsicht genehmigt" (und umgeht damit das typische wöchentliche Change Advisory Board usw.). Ein weiterer ergänzender Ansatz wäre, so viele Genehmigungspunkte im Änderungsmanagementprozess wie möglich zu automatisieren.

Automatisierung ist der Schlüssel

Automatisiertes Testen und Überwachen gibt es schon lange und wird von den ITIL Best Practices voll unterstützt. DevOps geht hier noch einen Schritt weiter. Bei DevOps besteht das Ziel darin, automatisierte Test- und Überwachungsfunktionen so früh wie möglich in den Entwicklungszyklus zu implementieren. Integrierte codebasierte automatisierte Tests ermutigen den Programmierer, Anwendungen zu entwickeln, die in der Lage sind, fast alles zu erkennen, was mit dem System schief gehen könnte. Wenn der Programmierer wirklich clever ist, wird er sogar versuchen, eine Lösung einzubauen, mit der alle erkannten Probleme automatisch behoben werden können, ohne dass ein menschliches Eingreifen erforderlich ist (und ohne dass ein neues Incident-Ticket erstellt werden muss - obwohl das System eine Informationsmeldung im Event-Management-System erstellen könnte).

DevOps ist in der Regel keine gute Lösung für Altsysteme

Dabei dürfen wir nicht vergessen, dass es in vielen Unternehmen nicht immer realistisch oder wünschenswert ist, in jeder Situation Agile oder DevOps einzusetzen. Was ist mit Altsystemen? Was ist mit Systemen, die weder virtualisiert noch cloudbasiert sind? Was ist, wenn Ihr Unternehmen nicht bereit ist, Agile oder DevOps einzusetzen, weil es an den erforderlichen Fähigkeiten, Tools, der kulturellen Reife, der Organisationsstruktur usw. mangelt? Traditionelle ITIL und/oder andere verwandte Service-Management-Frameworks sind immer noch eine der besten Möglichkeiten, um die Verwaltung von Legacy-IT-Systemen und -Diensten zu bewältigen.

Zusammengefasst: In vielen Organisationen wäre es sinnvoll, eine Kombination von Ansätzen zu verwenden: ITIL für einige Dinge, Agile für einen Teil der Entwicklung, Wasserfall für andere Projekte und DevOps unter bestimmten Umständen, wenn die Bedingungen es zulassen (vielleicht durch die Durchführung eines Pilotprojekts oder den Einsatz von DevOps nur für neue Produkte und digitale Dienstleistungen).

Ist ITIL also tot? Nein! Es ist immer noch relevant und wird in einigen Fällen heute mehr denn je benötigt.

Blog Bild 1
Messung der Problem-Management-Qualität in einer ITIL-Umgebung, Teil 1
Blog Bild 1
Messung der Problem-Management-Qualität in einer ITIL-Umgebung, Teil 2
Blog Bild 1
Messung der Problem-Management-Qualität in einer ITIL-Umgebung, Teil 3
Blog Bild 1
Messung der Problem-Management-Qualität in einer ITIL-Umgebung, Teil 4

Wir sind Experten in:

Kontaktieren Sie uns

für Anfragen, Details oder ein Angebot!