ITIL und DevOps im Zusammenspiel
Der erste Teil des Artikels "Hybride IT-Organisationen mit ITIL4 und DevOps" hat die bekannten Ansätze ITIL und DevOps erklärt und verglichen. Dieser zweite Teil bringt die beiden Frameworks zusammen.
Mit ITIL4 ist eine notwendige und sinnvolle Öffnung des Frameworks in Richtung DevOps und agiler Methoden vollzogen worden. Aus Sicht des Autors hat sich ITIL damit selbst neu erfunden und seinen Platz als äußerst hilfreiches Framework unter Beweis gestellt.
Der Zweck einer jeden Organisation besteht in der Erzeugung eines Wertes, ITIL4 spricht von Value. Den Stakeholdern entsteht dieser Wert, bzw. wird durch den Nutzen für die Stakeholder repräsentiert. Die starke Einbeziehung der Stakeholder, besonders der Service-Konsumenten, wird durch das Konzept der Value Co-Creation in ITIL4 unterstrichen. Immer mehr Unternehmen verstehen, dass Value durch eine aktive Zusammenarbeit zwischen Service-Provider und Anwendern sowie anderen Organisationen, die Teil der jeweiligen Beziehung sind, geschaffen wird. ITIL4 betont daher den Aufbau von interaktiven Beziehungen, die gegenseitigen Nutzen ermöglichen.
ITIL4 ist nicht allein ausreichend für die Bewältigung der aktuellen Herausforderungen. DevOps wiederum erweitert den modernen Ansatz einer agilen Produktentwicklung um den Betrieb und drängt damit inhaltlich in die Domäne von ITIL vor. Im Folgenden sollen daher die beiden Ansätze über die Formulierung von möglichen Ansatzpunkten verbunden werden (siehe Abbildung 5).
Zusammenarbeit ist der Schlüssel zum Erfolg
ITIL formuliert ein entsprechendes Grundprinzip, agile Methoden haben es quasi in der DNA: Zusammenarbeit und Kommunikation. Wichtiger als die fachlich ergänzenden Themen ist die Bereitschaft beider Seiten zur Kollaboration statt Kooperation. Meine Erfahrungen in deutschen IT-Organisationen zeigen, dass das Silodenken und eine gewisse Überzeugung der eigenen Expertise und Bedeutung noch zu stark ausgeprägt sind. Anstatt über die Anderen zu reden, sollte man mit ihnen reden und gemeinsam Verantwortung für Kunden und Wertströme übernehmen..
Langjährige ITSM-Praktiker sollten ein Verständnis für die Grundlagen und Vorteile von agilen Methoden entwickeln. Die Arbeit an Impediments (Beseitigung von Hindernissen) hat enorme Bedeutung und wird durch spezielle Meetings und Rollen, die dafür die Verantwortung tragen, umgesetzt. Es wird nicht nur Wert auf fachliche Ergebnisse gelegt, sondern auch an der Zusammenarbeit "gearbeitet".
Entwicklungslastige DevOps-Teams sollten die Erfahrung des Service-Managements aus dem Betrieb von Applikationen nutzen und gemeinsam mit ihm die DevOps-Zukunft gestalten.
Der Aufbau dieses Verständnisses ist Aufgabe des Top-Managements. Es muss die Rahmenbedingungen dafür setzen [1]. Die Zusammenarbeit kann zunächst auf einfachem Niveau starten, indem bspw. die Betriebsanforderungen in die Abnahmekriterien der Entwicklungsteams (Definition of Done) aufgenommen werden und die Betriebsverantwortlichen an den Sprint Reviews teilnehmen. Das bedeutet einen ersten Einstieg in die Zusammenarbeit, bevor über organisatorische Veränderungen nachgedacht wird.
Auf den Punkt gebracht:
Erfolgreiche Unternehmen schaffen es, Kundenbedürfnisse zu erfüllen. Basierend auf einer gemeinsamen und einheitlichen Sicht auf das Business muss die Lieferung von Services bzw. Produkten im Mittelpunkt der Organisation und Arbeit der IT stehen.
Das Business muss eingebunden werden
Wenn die IT-Organisation die Zusammenarbeit für sich geklärt hat, muss der Kunde aktiv in die Umsetzung und Veränderung einbezogen werden. In beiden Methoden existieren dazu Vorstellungen und Erfahrung in der Anwendung. Während ITIL eher auf die vertraglichen Aspekte Wert legt und die Leistungserbringung in Prozessen bzw. Praktiken organisiert, kann DevOps mit der operativen Einbeziehung des Business (festgelegte Ereignisse) punkten. Hier liefern beide Ansätze aus ihren Einsatzgebieten wertvolle Tipps, die zusammengeführt werden müssen. Auch die vertrauensvollste Zusammenarbeit von DevOps-Teams mit dem Kunden benötigt eine geregelte Grundlage, jedoch kann kein Vertrag alle Einzelheiten der Zusammenarbeit abdecken.
Nachhaltige Wertschöpfung kann nur unter aktiver Mitwirkung der Kunden geschaffen werden.
Es ist daher wichtig, dass die IT-Organisation auf der Basis einer gemeinsamen Sichtweise mit einer Stimme spricht und den Kunden auf der Grundlage seiner Anforderungen schon in der Planung einbezieht, denn er allein kann die Wertschöpfung qualifizieren und quantifizieren.
Auf den Punkt gebracht:
Nachhaltige Wertschöpfung kann nur unter aktiver Mitwirkung der Kunden geschaffen werden. Dazu muss ein umfassender Rahmen geschaffen und in der täglichen Zusammenarbeit gelebt werden.
Orientierung an Wertschöpfungsketten
Meines Erachtens sind viele IT-Bereiche immer noch "technologisch unterwegs" und weniger bei der konkreten Betrachtung der Wertschöpfung für den Kunden. Eine Wertstromorientierung beginnt mit dem Kunden und endet bei ihm. Die Automatisierung von Lieferprozessen bis in die Produktion (Continuous Delivery) übergibt die Releaseverantwortung an den Kunden, muss aber den gesamten Prozess betrachten.
Die Einbindung des Business in die Beschreibung der Wertschöpfungskette unterstützt dieses dabei, seine Anforderungen nutzenorientiert zu formulieren. Die Tätigkeiten innerhalb der IT-Organisation können sich dann genau auf diesen Nutzen konzentrieren. Das Service Value System und die Service Value Chain liefern dazu einen sehr guten Rahmen. Die produktorientierten DevOps-Teams können dann die Practices in Kenntnis der konkreten Kundenbedürfnisse nutzen und in die eigene Arbeit integrieren.
Auf den Punkt gebracht:
Die Orientierung an Wertschöpfungsketten hilft dem Business, die eigene Arbeit besser zu verstehen, liefert eine wertvolle Vorgabe für die IT und unterstützt die Kundenorientierung nachhaltig.
Mehrwert auf Unternehmensniveau schaffen
Service-Management basierend auf ITIL hat langjährige Erfahrung und vielfältige Expertise in der Planung, der Durchführung, der Steuerung und Optimierung von Services insbesondere in mittleren und großen Organisationen. Agile Ansätze fokussieren auf den Menschen und die Organisation in Teams sowie verstärkte Autonomie und dezentrale Entscheidungen. Die Erfahrung im Service-Management ist für die umfassende Lieferung von Services weiterhin notwendig, bspw. um die Einhaltung der Verträge (d. h. die Erwartung der Kunden zu erfüllen) sicherzustellen, während der Umgang mit Komplexität erfolgreich mit DevOps angegangen wird.
ITIL4-Practices können gemeinsam mit dem Expertenwissen der Mitarbeiter genutzt werden, um Aktivitäten und Verantwortung in die Teams zu verlagern. Diese Dezentralisierung ist notwendig und sinnvoll. Sie sollte von ITSM-Experten begleitet werden und sich an den präferierten Unternehmenswerten orientieren.
Das Service-Management muss sich wie andere Unternehmensbereiche bei den anstehenden organisatorischen Veränderungen "einsortieren" und insbesondere die Veränderung in Richtung der Produktorganisation unterstützen. Dabei können die eigenen Stärken eingebracht werden, gekoppelt mit einer selbstkritischen Betrachtung der Erfolge.
Auf den Punkt gebracht:
Insbesondere bei einer umfassenden Sicht auf Unternehmen sind die Vorteile beider Ansätze perfekt kombinierbar. ITIL4 sichert den Blick auf das Ganze und schafft den weiten Organisationsrahmen für kunden- bzw. produktorientierte Teams, die dann im Operativen durch ihre Arbeit Wert liefern.
Teams bilden die operative Grundlage
Die DevOps-Philosophie gibt Antworten im operativen Bereich, insbesondere mit Blick auf die Menschen und Teams, was bei ITIL nicht angemessen berücksichtigt wurde. Diese Einschätzung beruht auf den praktischen Umsetzungen von ITIL in der Vergangenheit im Sinne von "Command and Control" mit granular vorgedachtem und überwachten Prozessmodus. Diese Fehlinterpretation bei der Anwendung von ITSM war zwar nie die Idee von ITIL, findet sich jedoch häufig in der Praxis.
Ziel bei der Bildung von Teams ist die Dezentralisierung der Verantwortung und Entscheidungsbefugnis/-befähigung. Insbesondere die Crossfunktionalität und gemeinsame Produktorientierung stellen einen wesentlichen Bezug der eigenen Arbeit zum Gesamtergebnis her. Anstelle der kleinteiligen Sicht auf einzelne Schritte in einem Prozess erbringen die Teams zusammenhängend einen weitgehenden Teil der Arbeit in einer Wertschöpfungskette.
Diese Teams müssen in einen passenden Gesamtrahmen eingebunden werden, der ihnen auf der einen Seite weitgehende Autonomie gewährleistet, damit die Dezentralisierung der Entscheidungsfindung und Verantwortung die volle Wirkung entfalten kann. Auf der anderen Seite müssen sie in die gesamte Organisation und Sicherstellung der Erfüllung der Kundenanforderungen einbettet sein, damit diese Verantwortung im Sinne des Kunden und der IT-Organisation wahrgenommen wird.
Eine schöne Beschreibung der Erfahrungen und vor allem der permanenten Anpassung von Spotify findet sich im Whitepaper von Christoph Schmiedinger "Vorbild Spotify – Was Sie beachten sollten, bevor Sie das Organisationsmodell kopieren" [2]. Dort wird zum Beispiel schön herausgearbeitet, wie Spotify mit der allseits bekannten Organisation (Teamorientierter Aufbau mit starker dezentraler Autonomie) nach 2012 diese angepasst hat, um Kundenbedürfnisse stärker und besser abbilden zu können.
Auf den Punkt gebracht:
Prozessorientierte Organisationen sind in der Vergangenheit häufig als Antwort zur Überwindung von Silodenken und -handeln gebildet worden. Wirkliche Verantwortung und dezentrale Entscheidungskompetenz kann jedoch nur über End-to-end-Verantwortung in produktorientierten Teams erreicht werden.
Automation ist eine Herausforderung
Selbstverständlich hat auch die IT immer wieder über Automatisierung nachgedacht und Projekte durchgeführt. Häufig waren diese jedoch technikgetrieben und isoliert, weil Standardisierung im Sinne von einheitlichem Vorgehen und notwendiger Optimierung nicht ausreichend durchgeführt wurde. Einzelne Tools kamen bedarfsgetrieben zum Einsatz. Die derzeitigen Ansätze in den IT-Organisationen beachten die genannten Probleme weiterhin nur sehr selten. Die Entwicklungsteams automatisieren ihre Arbeit, um Betriebstätigkeiten abzubilden, anstatt den gesamten Wertstrom zu betrachten, während der Betriebsbereich die Integration der gelieferten Ergebnisse aus der Entwicklung automatisiert.
Die in diesem Artikel betrachten Ansätze ITIL und DevOps unterstreichen die Bedeutung von Automatisierung in der IT und bieten jeweils in ihrer Domäne Lösungen an. ITIL beschreibt die Notwendigkeit der vorgelagerten Prozessoptimierung und die Orientierung an der Wertschöpfungskette. DevOps liefert die technische Umsetzung und unter anderem die vielfältigen Erfahrungen von Unternehmen wie Spotify, Amazon oder Netflix, die ein digitales Geschäftsmodell haben.
Auf den Punkt gebracht:
Die Technologie zur Automation ist vorhanden und muss mit Blick auf übergreifende Prozesse und die Wertströme adäquat in der IT genutzt werden. Das erfordert Experten und Vertreter aus beiden Domänen: ITIL4 liefert den Überbau, DevOps das technische Know-how.
Pragmatismus ist angesagt
Fokussierung und Reduzierung der Herausforderungen auf einzelne oder gar ein Framework(s) ist nicht zielführend. Aufgabe ist es nicht mehr, Frameworks mithilfe von umfangreichen und teuren Change-Projekten für ein Unternehmen einzuführen, sondern eine Auswahl von "Best-of-Practises" zu treffen, passgenau für das Unternehmen (Cherry picking). Das Ziel ist eine anpassungsfähige Organisation. Neben den erwähnten Methoden ITIL, Scrum und Kanban sind weitere vorhanden, die jeweils gute Lösungen liefern. Der DMAIC-Cycle aus dem Lean Six Sigma [3] kann beispielsweise helfen, die Problemlösung in den Teams zu professionalisieren, ebenso wie Tools (Ishikawa usw.) aus dem Lean-Management angewendet werden können. Aufwändige Programme zur Unternehmensentwicklung müssen durch einen iterativen und kontinuierlichen Lern- und Entwicklungsprozess ersetzt werden, der die Organisation reaktionsfähig gestaltet.
Die hybride Nutzung von Ansätzen ist notwendig, d. h. eine agile Entwicklung und der stabile Betrieb sind möglich. Sehr schöne Beispiele und Fakten liefert der jährliche State of DevOps Report [4].
Beide Sichten können nicht ohne die andere erfolgreich sein. Im Grunde genommen ist das genau das, was DevOps tut. Es integriert als Philosophie die geeignetsten Werkzeuge aus unterschiedlichen Methoden und kombiniert sie zu einem Ansatz.
Auf den Punkt gebracht:
"Machen ist wie wollen, nur krasser!" Dieser schöne Satz, der auf T-Shirts und Kaffeetassen erhältlich ist, beschreibt die "banale" Herausforderung. Beide Seiten müssen aufeinander zugehen und dabei die eigene, langjährige Erfahrung einbringen und sich auf die gleiche Erfahrung der anderen Seite einlassen.
Verbindung von ITIL4 und DevOps
Dieses Kapitel hat anhand der verschiedenen Ansatzpunkte gezeigt, wie die beiden Ansätze ITIL und DevOps konkret helfen können, IT-Organisationen zur Bewältigung der aktuellen Herausforderungen zu gestalten. Im Prinzip nähern sich ITIL4 und DevOps dem gleichen Thema von zwei Seiten. ITIL4 stellt (wie bisher) die Governance sicher und bietet einen umfassenden Rahmen, während DevOps die Autonomie der Teams nutzt und Selbstorganisation gewährleistet. ITIL muss dabei mehr Flexibilität ermöglichen und Dezentralität fördern, während DevOps die Zusammenarbeit aller Beteiligten unterstützen und den Blick auf Ganze garantieren muss (Abb. 6).
Praxisbeispiele
Die Kombination von ITIL4 und DevOps wird aus Sicht des Autors noch nicht offensiv in Projekten angegangen bzw. konkret unter diesem Titel umgesetzt. Ein Grund dafür ist sicherlich, dass ITIL4 in der Praxis noch keine Relevanz hat. Sehr wohl können jedoch aktuelle Projektbeispiele in diesem Beitrag dargestellt werden, bei denen ITIL in älteren Versionen genutzt wird und jahrelange Erfahrung in der Anwendung vorliegt, die nun mit DevOps zusammengeführt wird. Hier haben die IT-Organisationen auf ihre jeweils individuelle Weise eine hybride IT-Organisation aufgebaut bzw. sind dabei. Die folgenden drei Praxisbeispiele nutzen die zu Beginn dieses Kapitels dargestellten Ansatzpunkte (s. Abb. 5).
IT-Tochter im Konzern
Das betrachtete Unternehmen ist als IT-Service-Provider in einem größeren Konzern eingebunden und hat das Projekt "Office aus der Cloud" als Anlass genommen, agile Denk- und Arbeitsweisen in einem Projekt umzusetzen. Die Einschätzung, dass die vorherrschende Organisation (Silo- und Prozessdenken, starke Spezialisierung bei Mitarbeitern, Projekte zum Aufbau von Betriebstätigkeiten) sich mit einer modernen und von außen getriebenen Applikationserneuerung schwer tun wird, führte zu dem Entschluss, zunächst ein kleines DevOps-Team auf- und schrittweise auszubauen.
Die Zusammenarbeit zwischen Entwicklung (Projekte) und Betrieb als Schlüssel zum Erfolg hat sich in diesem Beispiel als wichtig herausgestellt. Besonders hilfreich ist dabei der Pragmatismus gewesen. Verschiedene Faktoren haben einen permanenten Abgleich zwischen Zielen und realen Gegebenheiten sowie den machbaren Maßnahmen begünstigt und immer wieder die Mitarbeiter zusammengebracht. Das Business wurde von Beginn an eingebunden, unter anderem bei der Entscheidung und Umsetzung der Arbeitsformen. Die Orientierung an Wertschöpfungsketten und die Schaffung eines Mehrwerts auf Unternehmensniveau war von Beginn an nicht im Fokus, unter anderem bedingt durch den technikgetriebenen Auftrag. Bei der Bildung der Teams hat die Organisation viele Erfahrungen gesammelt. Insbesondere die Skalierung beim Ausbau und die Integration bestehender organisatorischer Einheiten machten häufige Veränderungen in den Teams und Rollen notwendig. Diese Erfahrungen führten unter anderem dazu, das gesamte Unternehmen in eine teamorientierte Organisation zu überführen.
Ablösung einer Kernapplikation im Konzern (Finanzbranche)
In diesem Praxisbeispiel ist das Projektziel die Ablösung einer wichtigen Applikation eines Konzerns in der Finanzbranche im Rahmen eines umfangreichen Programms. Es wurden agil arbeitende Entwicklungsteams gebildet, die im Rahmen eines mehrjährigen Releaseplans (u. a. schrittweise Ausdehnung der unterstützten Geschäftsprozesse und Steigerung der Anwenderzahlen) direkt in eine Produktivumgebung entwickeln und somit von Beginn an den DevOps-Ansatz von Continuous Delivery umsetzen. Dazu wurde der bestehende Betriebsbereich zunächst direkt vom Programm "angesteuert" und zum ersten Releasedatum als Team in das Programm integriert.
Die Zusammenarbeit zwischen Entwicklung und Betrieb ist aktuell für dieses Programm ein wichtiger Erfolgsfaktor. Alle beteiligten Mitarbeiter sind räumlich soweit möglich zusammengeführt worden und tauschen sich direkter aus. Unterstützt wird dies durch ein Lenkungsgremium, das aus Führungskräften von Entwicklung und Betrieb sowie ausgewählten agilen Coaches aus den Teams besteht und die gemeinsame Verantwortung verinnerlicht hat. Es trifft sich wöchentlich und betrachtet neben dem fachlichen Fortschritt auch die kulturelle Entwicklung im Programm. Problematisch ist die Einbindung des Business. Unter anderem hemmen der wirtschaftliche Druck und effizienzgetriebene Sichtweisen die notwendige Veränderung bei der Integration der Fachbereiche in die Arbeit des Programms. Die Orientierung an Wertschöpfungsketten erfolgt verstärkt, weil das im auftraggebenden Business gesteigert umgesetzt wird. Durch den Start in das Programm mit einer agilen Organisation bilden Teams die operative Grundlage. Dieser Punkt ist auch bei der Ausweitung der Projektteams im Programm jederzeit beachtet worden, ebenso wie die Automation als Herausforderung zumindest im Programm bewältigt wurde (CD-Pipeline).
Digitale IT-Tochter im Maschinenbau
Wie viele deutsche Unternehmen hat in diesem Praxisbeispiel ein klassischer Maschinenbaukonzern für seine Aktivitäten im Bereich der Digitalisierung eine IT-Tochter (aus-)gegründet. In diese Tochter wurden verschiedene Aufgaben transferiert, gemeinsam mit entsprechenden Mitarbeitern. Neben dem Ausbau der Digitalisierung wurden auch bestehende Aufgaben für die IT-Infrastruktur übertragen. Die Mitarbeiter in der IT-Tochter werden um gezielte Neueinstellungen ergänzt.
Bei der Zusammenarbeit zwischen Entwicklung und Betrieb als Schlüssel zum Erfolg ist aus Sicht des Autors noch Entwicklungspotential vorhanden. Die Bildung einer neuen Organisation hat weder auf Leitungsebene noch bei den Mitarbeitern automatisch zu einem Gefühl der Zusammengehörigkeit geführt. Die vielerorts bekannten Gräben zwischen Entwicklung/Projekten und Betrieb wurden beim Start in die neue Organisation nicht ausreichend genug beachtet und abgebaut. Das Business ist zwar eingebunden worden, kann jedoch nicht in allen Bereichen den Zweck und die Vorteile in der operativen Arbeit nachvollziehen, u. a. wenn die Zusammenarbeit innerhalb der IT nicht funktioniert. Die von der Mutter vorgegebene und vorgelebte Orientierung an Wertschöpfungsketten ist in diesem Fall sehr hilfreich. Die ingenieursmäßige Betrachtung des Geschäftsmodells und der Businessaktivitäten unterstützt die Strukturierung der Aktivitäten in der IT. Der insgesamt zunächst fehlende Pragmatismus bekommt durch die neue Organisationsform ein wenig Auftrieb. In der kleineren Organisation können einfach umsetzbare Entscheidungen eher getroffen werden.
Ausblick
Dieser Beitrag hat gezeigt, dass die im Titel formulierte Frage bejaht werden kann, d. h. ITIL4 und DevOps lassen sich auf der Basis der jeweiligen Prinzipien anhand der vielfältigen Überschneidungen in den Grundprinzipien kombinieren. An den Stellen, an denen einer der beiden Ansätze Lücken aufweist oder einen unterschiedlichen Fokus hat, kann der andere unterstützend eingesetzt oder durch weitere Werkzeuge ergänzt werden.
ITIL ist ein erprobtes Framework und mit den zahlreichen Praktiken ziemlich vollständig mit Hilfestellungen zum Aufbau einer Service-Organisation. DevOps ist ein Ansatz, dessen Hauptfokus in der verbesserten Zusammenarbeit in den Teams seine Stärken hat. Beides zusammen ist letztlich notwendig für den Erfolg. Erfolgreiche Organisationen zeichnen sich in der für die eigene Herausforderung und den eigenen Reifegrad adäquaten Nutzung der vorhandenen Ansätze aus. Das setzt die in diesem Beitrag erläuterten Punkte voraus. Die erläuterten Praxisbeispiele zeigen die vielfältigen Herausforderungen, die verschiedenen Rahmenbedingungen und vor allem die unterschiedlichen Herangehensweisen sowie Reifegrade in deutschen Unternehmen.
Die formulierten Ansatzpunkte sollten in unterschiedlicher Weise aufgegriffen und verzahnt vorangetrieben werden. Die in Abb. 5 dargestellte Übersicht beschreibt eine erste Idee, was in einer Organisation beachtet werden sollte. Die mögliche Reihenfolge oder Gewichtung ist organisationsindividuell zu ermitteln.
Die Herausforderung für die Praxis besteht darin, diese Sichtweise in den Alltag zu überführen. Allen Beteiligten (Stakeholdern, Kunden, Management, Entwicklung, Betrieb, usw.) ist diese Kombinationsmöglichkeit näher zubringen und an die jeweilige Organisation anzupassen. Dabei ist neben der fachlichen und methodischen Arbeit zu beachten, dass dieser Weg viel Empathie und soziale Kompetenz benötigt.
Anstatt alle Beteiligten "mitzunehmen" oder "abzuholen", sollten sie von Beginn an einbezogen werden. Das kostet Zeit und Geld und benötigt auf allen Seiten Geduld und Verständnis. Das Ergebnis ist eine hoch performante und vor allem anpassungsfähige IT-Organisation, die als kompetenter Partner das Business unterstützt. Letztlich haben viele "agile" Transformationsprojekte genau dieses Ziel.
- DevOps and Collaboration: Fraternizing with the Enemy?
- C. Schmiedinger: Vorbild Spotify? (auch als Podcast)
- Wikipedia: DMAIC-Cycle aus dem Lean Six Sigma
- 2019 State of DevOps Report
Kommentare (0)