Wahrscheinlich nicht!<\/p>\n
Mit dem Aufkommen von Agile und DevOps sagen manche, ITIL sei tot! Stimmt das? Die kurze Antwort lautet: \u201eNEIN!\u201c <\/p>\n
Wir m\u00fcssen jedoch die Begr\u00fcndung f\u00fcr die Behauptung verstehen, ITIL sei irrelevant und IT Service Management (ITSM) \u00fcberholt. Es stimmt durchaus, dass viele Organisationen, die \u201eITIL implementiert\u201c haben oder \u201eITIL-konform\u201c bzw. \u201eITIL-ausgerichtet\u201c sind, derzeit vor vielen Herausforderungen stehen. Dazu z\u00e4hlen unn\u00f6tige B\u00fcrokratie, unflexible und komplexe Prozesse, veraltete Tools und Technologien, siloartige und gegeneinander arbeitende IT-Abteilungen sowie weitere gravierende Probleme und Dysfunktionen. <\/p>\n
Es ist \u00fcblich, 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\u00fcber der Softwareentwicklung stark bevorzugt und daher f\u00fcr die \u201eApp-Leute\u201c nicht relevant sei. <\/p>\n
Viele Organisationen interpretieren ITIL-Best Practices falsch und\/oder setzen ITSM-Prinzipien schlecht um. Ebenso richten viele Organisationen bei Agile ein Durcheinander an \u2013 insbesondere, wenn ihre Interpretation von Agile gleichbedeutend ist mit \u201eaus dem Bauch heraus handeln\u201c. 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 \u00fcber diese unglaublich leistungsf\u00e4higen Konzepte. In all diesen Frameworks \u2013 ITIL eingeschlossen \u2013 gibt es mehr \u201eAnwenderfehler\u201c als tats\u00e4chliche M\u00e4ngel. <\/p>\n
ITIL war nicht als Einheitsl\u00f6sung<\/em> gedacht, die von jeder Organisation auf die gleiche Weise implementiert wird. Eines der ITIL-Mottos lautet \u201eadopt and adapt\u201c. Ziel dieser Aufforderung ist es, eine flexible Implementierung des ITIL-Frameworks zu f\u00f6rdern. <\/p>\n ITIL soll nicht b\u00fcrokratisch sein oder Agilit\u00e4t und Innovation behindern. Das Gegenteil ist der Fall. ITIL f\u00f6rdert die Einf\u00fchrung neuer Technologien und Innovationen, um die Anforderungen des Unternehmens zu erf\u00fcllen und Wert f\u00fcr Kunden zu schaffen. ITIL-Konzepte sollten so umgesetzt werden, dass die Ergebnisse aus der Perspektive von People, Process and Technology optimiert werden. <\/p>\n Entgegen der landl\u00e4ufigen Meinung steht ITIL nicht im Widerspruch zu Agile- oder DevOps-Denken. ITIL ist au\u00dferdem nicht auf Infrastruktur oder Betrieb beschr\u00e4nkt. Die aktuellsten Versionen von ITIL konzentrieren sich auf End-to-End-Services. Dazu geh\u00f6ren in der Regel das Management von Anwendungen, Entwicklung, Infrastruktur, Betrieb sowie die Ausrichtung an Gesch\u00e4ftsstrategie und Kundennutzen. <\/p>\n Dar\u00fcber hinaus verf\u00fcgt ITIL \u00fcber einen Entwicklungslebenszyklus, der auf Prinzipien basiert, die nahezu identisch mit dem Softwareentwicklungslebenszyklus sind, den sowohl Agile als auch DevOps verwenden. Ein gro\u00dfer Teil des ITIL-Lebenszyklus ist \u201eService Design\u201c, und ITIL ist weitgehend agnostisch in Bezug darauf, wie Anwendungsentwicklung durchgef\u00fchrt werden sollte. ITIL hat keine inh\u00e4rente Pr\u00e4ferenz f\u00fcr den Wasserfallansatz im Projektmanagement und unterst\u00fctzt Agile ebenso wie jeden anderen m\u00f6glichen Ansatz zur Gestaltung von Services oder zur Durchf\u00fchrung von Projekten. ITIL ist in Bezug auf Tools, Organisationsstruktur sowie die Gestaltung von Richtlinien und Verfahren \u00fcberwiegend nicht pr\u00e4skriptiv. <\/p>\n Viele der in ITIL beschriebenen Best Practices und Konzepte sind \u00e4hnlich, wenn nicht identisch, mit denen, die in Agile und DevOps vertreten werden \u2013 oder sind zumindest nicht mit ITIL unvereinbar. ITIL schreibt beispielsweise nicht vor, dass Sie viertelj\u00e4hrliche \u201eBig-Bang\u201c-Releases durchf\u00fchren oder einen langsamen und komplizierten Change-Management-Prozess haben m\u00fcssen. ITIL erm\u00f6glicht h\u00e4ufige Releases und einen agilen Change-Prozess. <\/p>\n Das k\u00fcrzlich ver\u00f6ffentlichte Buch Site Reliability Engineering: How Google Runs Productions Systems,<\/em> beschreibt Googles DevOps-Implementierung detailliert. DevOps bei Google ist eine Mischung aus Agile-Methoden, ITIL-Best Practices, systematischer Probleml\u00f6sung und Entscheidungsfindung sowie einer reifen Kultur der kontinuierlichen Verbesserung ohne Schuldzuweisungen. Nat\u00fcrlich basiert all dies auf Googles hochentwickelter propriet\u00e4rer Technologie f\u00fcr Anwendungen, virtualisierte Infrastruktur, Monitoring- und Alerting-Tools usw. Google nutzt Best Practices aus einer integrierten und ganzheitlichen People-, Process- und Technology-Perspektive \u2013 \u00e4hnlich dem, was ITIL seit den 1980er-Jahren propagiert. <\/p>\n Google und viele andere Organisationen nutzen zwei wichtige DevOps-Konzepte \u2013 Continuous Integration und Continuous Delivery \u2013, um h\u00e4ufige Releases zu f\u00f6rdern, in manchen F\u00e4llen Hunderte pro Tag. Diese Konzepte stehen nicht im Gegensatz zu ITIL, das nahelegen w\u00fcrde, dies kontrolliert mit einem Satz von Prozessen, Tools und F\u00e4higkeiten umzusetzen, die auf die Bed\u00fcrfnisse des Unternehmens abgestimmt sind. DevOps, Agile und Google sind sich darin einig. <\/p>\n Systematische Analyse, solide Planung und sorgf\u00e4ltiges Management sind erforderlich, um ein effektives und effizientes Release-Management-System aufzusetzen. Das ist wichtig, wenn das gew\u00fcnschte Endergebnis ein traditioneller Ansatz mit Releases nach einem viertelj\u00e4hrlichen Zeitplan ist, und noch wichtiger bei einem DevOps-Modell mit dem Ziel der Continuous Delivery. DevOps und Agile sind nicht gleichbedeutend mit schlampig oder \u201ewild-wild west\u201c. Disziplin und Struktur sind f\u00fcr ITIL, Agile und DevOps essenziell. Google ist in dieser Hinsicht keine Ausnahme. <\/p>\n Wie passen also Continuous Integration und Continuous Delivery zu ITIL und anderen ITSM-Best Practices?<\/p>\n Continuous Integration und Delivery lassen sich teilweise erreichen, indem m\u00f6glichst viele \u00c4nderungen in die Kategorie Standard Change (d. h. vorab genehmigt) \u00fcberf\u00fchrt werden. Ihre ITIL-ausgerichtete Change-Richtlinie k\u00f6nnte beispielsweise lauten: \u201eWenn der vorgeschlagene Change Request alle erforderlichen Tests besteht, ist er vorab genehmigt und kann ohne zus\u00e4tzliche Freigaben oder Managementaufsicht umgesetzt werden\u201c (wodurch Ihr typisches w\u00f6chentliches Change Advisory Board usw. umgangen wird). Ein weiterer erg\u00e4nzender Ansatz besteht darin, so viele Genehmigungspunkte wie m\u00f6glich im Change-Management-Prozess zu automatisieren. <\/p>\n Automatisierte Tests und Monitoring gibt es schon lange und werden von ITIL-Best Practices vollst\u00e4ndig unterst\u00fctzt. DevOps geht hier nur einen Schritt weiter. Bei DevOps besteht das Ziel darin, automatisierte Test- und Monitoring-Funktionen so fr\u00fch wie m\u00f6glich in den Entwicklungslebenszyklus zu integrieren. In den Code integrierte automatisierte Tests ermutigen den Programmierer, Anwendungen zu entwickeln, die nahezu alles erkennen k\u00f6nnen, was potenziell im System schiefgehen k\u00f6nnte. Wenn der Programmierer wirklich versiert ist, versucht er sogar, eine L\u00f6sung einzubauen, die alle erkannten Probleme automatisch behebt \u2013 ohne dass irgendein menschliches Eingreifen erforderlich ist (und ohne dass ein neues Incident-Ticket erstellt werden muss \u2013 obwohl das System im Event-Management-System eine informative Meldung erzeugen k\u00f6nnte). <\/p>\n 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\u00fcr Agile oder DevOps, weil es an den notwendigen F\u00e4higkeiten, 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\u00e4ltigen. <\/p>\n Fazit: In vielen Organisationen ist es sinnvoll, eine Kombination von Ans\u00e4tzen zu nutzen: ITIL f\u00fcr bestimmte Themen, Agile f\u00fcr einen Teil der Entwicklung, Waterfall f\u00fcr andere Projekte und DevOps in bestimmten Situationen, in denen die Rahmenbedingungen es zulassen (zum Beispiel durch einen Pilotbetrieb oder indem DevOps nur f\u00fcr neue Produkte und digitale Services eingesetzt wird).<\/p>\n Ist ITIL also tot? Nein! Es ist weiterhin relevant und in manchen F\u00e4llen heute mehr denn je erforderlich. <\/p>\n","protected":false},"excerpt":{"rendered":" Wahrscheinlich nicht! Mit dem Aufkommen von Agile und DevOps sagen manche, ITIL sei tot! Stimmt das? Die kurze Antwort lautet: \u201eNEIN!\u201c Wir m\u00fcssen jedoch die Begr\u00fcndung f\u00fcr die Behauptung verstehen, ITIL sei irrelevant und IT Service Management (ITSM) \u00fcberholt. Es stimmt durchaus, dass viele Organisationen, die \u201eITIL implementiert\u201c haben oder \u201eITIL-konform\u201c bzw. \u201eITIL-ausgerichtet\u201c sind, derzeit […]<\/p>\n","protected":false},"author":5,"featured_media":1917,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35],"tags":[],"ppma_author":[83],"class_list":["post-65505","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sonstige"],"acf":[],"yoast_head":"\nDer vermeintliche Konflikt existiert nicht<\/h4>\n
Keine Inkompatibilit\u00e4t<\/h4>\n
DevOps und Agile sind nicht der \u201eWilde Westen\u201c der IT<\/h4>\n
Integration von ITIL-Best Practices mit DevOps und Agile<\/h4>\n
Automatisierung ist entscheidend<\/h4>\n
DevOps ist f\u00fcr Altsysteme in der Regel nicht gut geeignet<\/h4>\n