Hybride IT-Organisationen mit ITIL4 und DevOps

Seit einigen Jahren erleben IT-Organisationen die aktuellen Veränderungen im wirtschaftlichen Umfeld sowie bei den Geschäftsmodellen ihrer Kunden mit immer stärkeren und kurzfristigeren Herausforderungen für die eigene Organisation und Arbeit. Als wichtiger und zentraler Dienstleister müssen sie sich in gleichem Maße dieser Problematik stellen und versuchen unter Zuhilfenahme von anerkannten Ansätzen wie Scrum, ITIL [1], Kanban, DevOps, SAFe usw. darauf zu reagieren. Dabei existieren häufig Missverständnisse oder Ablehnung zwischen bestehenden Bereichen in IT-Organisationen und es werden teilweise erbitterte Diskussionen und Kämpfe um das "richtige Framework" und den "perfekt passenden Ansatz" zur Problemlösung geführt. Diese wären bei richtiger Kombination der vorhandenen und bekannten Ansätze nicht notwendig. Dieser Artikel liefert einen Beitrag zur sinnvollen Verknüpfung aktuell verfügbarer Ansätze für genau diese Diskussion. Er klärt, ob und wie die bekannten Ansätze ITIL und DevOps kombiniert werden können.
Nach einer kurzen Einführung in die Thematik dieses Beitrages werden im folgenden Kapitel die beiden Ansätze ITIL (mit der aktuellen Version 4) und DevOps kurz dargestellt. Danach werden die zugrundeliegenden Prinzipien beider Ansätze in Unterkapiteln erläutert. Dabei geht der Autor davon aus, dass nicht jeder Leser beide Ansätze und insbesondere die jeweiligen Prinzipien kennt. Sollten sie als Leser also ITIL4 und DevOps sowie deren Prinzipien bereits kennen, können sie diese Teile überspringen. Der zweite Teil des Artikels beantwortet abschließend die Frage, ob eine Kombination von ITIL und DevOps möglich ist. Darauf aufbauend liefert er Vorschläge für eine Kombination und klärt damit, wie sich die beiden Ansätze sinnvoll ergänzen können. Drei Praxisbeispiele runden den Blick auf das Zusammenspiel von ITIL4 und DevOps ab. Der letzte Abschnitt gibt auf Basis einer kurzen Zusammenfassung einen Ausblick.
1 Einführung
Nach wie vor stehen Unternehmen vor vielfältigen und großen Herausforderungen. Kunden wie auch Mitarbeiter werden anspruchsvoller und bestehende Geschäftsmodelle scheinen am Ende zu sein. Technologische Fortschritte wie Cloud-Computing oder Blockchain bringen neue Wettbewerber und verändern die Ansprüche an eigene Mitarbeiter sowie die Form der Zusammenarbeit intern wie extern.
Mit ITIL4 steht seit dem Februar 2019 ein Framework für agiles Service-Management bereit, das ITIL explizit in Richtung von agilen Ansätzen öffnet und für eine neuartige Nutzung bereit macht. ITIL4 versteht sich selbst als eine Antwort auf die beschriebenen Herausforderungen aus Sicht des IT-Service-Management. In einer früheren Version hat ITIL bereits formuliert, "dass sich in der Praxis gezeigt hat, dass zwar jedes Konzept für sich gut gedacht ist, doch keins die perfekte Lösung für das Service-Management bietet. Vielmehr ergänzen sie sich. In der Tat kombinieren viele Organisationen verschiedene Konzepte, um ihre IT effektiver zu managen und zu verbessern".
Wenn also die These zutrifft, dass die aktuellen Herausforderungen zu umfangreich für eine Methode sind, wäre eine Kombination sinnvoll. Damit könnten zeitgemäße Antworten gefunden werden, indem beispielsweise DevOps und ITIL4 geschickt zusammengeführt werden. Dazu müsste sichergestellt sein, dass sich beide Ansätze sinnvoll ergänzen lassen und diese Kombination einen Nutzen bringt. Dieser Artikel stellt sich dieser Problematik mit zwei Leitfragen:
- Lassen sich die bekannten Ansätze ITIL und DevOps kombinieren?
- Wenn ja: Wie können IT-Organisationen dabei vorgehen und welcher Nutzen entsteht?
2 ITIL und DevOps im Kurzüberblick
Dieses Kapitel stellt beide Methoden kurz dar. Für das Framework ITIL4 ist das einerseits wichtig, weil sich mit dieser Version einige Änderungen zur alten Version ITIL aus 2011 ergeben haben. DevOps wird andererseits in der Praxis noch sehr häufig unterschiedlich definiert, beschrieben und interpretiert.
ITIL4
ITIL ist in den 1980er Jahren entwickelt worden und bezeichnet sich selbst als "Best-Practice-Leitfaden für Service-Management". Seitdem hat ITIL eine Reihe von substanziellen Veränderungen erfahren und sich über die Versionen V2, V3 sowie Edition 2011 zur heutigen Variante ITIL4 weiterentwickelt [2]. Diese wurde Anfang 2019 veröffentlicht. ITIL4 stellt keine umfassend neue Version dar, sondern eine konsequente Weiterentwicklung auf Basis der langjährigen und etablierten Erfahrungen, die zeitgemäß modernisiert wurden. Beispielsweise wurde der komplette Servicelebenszyklus abgeschafft und in eine übergreifende Betrachtung eines Service-Value-Systems überführt. Viele bekannte Praktiken wurden mit Blick auf Lean-Management, Agilität und DevOps angepasst. Besonders im Fokus steht bei ITIL4 die gemeinsame Wertschöpfung durch Service-Provider und Service-Konsumenten (Value Co-Creation) in Wertströmen (Value Streams).
Service Value System
ITIL4 wurde zu einem durchgängigen Ansatz eines Service Value Systems (SVS) weiterentwickelt (s. Abb. 1) und geht damit über die Lebenszyklusbetrachtung von Services (s. frühere ITIL-Versionen) hinaus. Das Service Value System besteht aus einer Nachfrage (Opportunity/Demand), die durch die Service Value Chain in einen Wert (Value) überführt wird. Den Rahmen dafür geben die Guiding Principles als Basis und Governance als stabilisierendes und steuerndes Element sowie die Practices als bewährte Methodensammlung, abgerundet durch eine kontinuierliche Verbesserung.
Im Mittelpunkt steht nun die gemeinsame Wertschöpfung durch Service Beziehungen. Der Kunde wird als wesentliches Element in diesem Prozess betrachtet, die Service Beziehungen gehen jedoch darüber hinaus. Sie berücksichtigen erstmals explizit die Service Ketten und das innerhalb dieser Ketten der Service Provider ebenfalls zum Kunden wird. Das Service Value System begreift die Mitwirkung des Kunden als essenziell für die Wertschöpfung und stellt dar, wie verschiedene Komponenten und Aktivitäten in Organisationen zusammenwirken, um Wertschöpfung durch eine IT-Unterstützung zu ermöglichen.
Service Value Chain
Die Service Value Chain (SVC) ist in das Service Value System eingebettet. Sie besteht aus einer Reihe miteinander verbundener Aktivitäten (Abb. 2). Die optimale Abstimmung dieser Aktivitäten führt zu einem funktionalen Betriebsmodell für die Entwicklung, Bereitstellung und kontinuierliche Verbesserung von Services.
Die Anpassungsfähigkeit der SVC ermöglicht es Organisationen, auf veränderte Anforderungen ihrer Stakeholder so effektiv und effizient wie möglich zu reagieren, indem Varianten dieser Sequenzen definiert und als Wertströme betrachtet und gestaltet werden. Mit dem Service Value System hat ITIL4 die bis dato geprägte Sicht auf einen Servicelebenszyklus in Richtung einer wertstromorientierten Darstellung verändert. In diesem sind wesentliche Aspekte wie Guiding Principles und Practices sowie die Service Value Chain enthalten.
Value Co-Creation
Eine steigende Anzahl von Organisationen versteht, dass Mehrwert verstärkt durch eine aktive Zusammenarbeit zwischen Anbieter und Nutzer sowie anderen Organisationen, die Teil der jeweiligen Beziehung sind, geschaffen wird. ITIL4 legt daher Wert auf den Aufbau von interaktiven Beziehungen, die gegenseitigen Nutzen ermöglichen. Auf der einen Seite können Anbieter die kontinuierliche Verbesserung ihrer Services und der gesamten Organisation sicherstellen. Nutzer müssen sich andererseits aktiv einbringen, Services in Anspruch zu nehmen und an der Erzeugung des Mehrwertes mitzuwirken. Sie beziehen dafür Services, die eher ihren Erwartungen entsprechen und daher einen größeren Nutzen bieten.
Guiding Principles
Die Guiding Principles in ITIL4 bieten im Sinne von Leitplanken eine umfassende und ganzheitliche Sichtweise, wie eine Service-Organisation (und somit auch ein Service-Management) die Arbeiten planen, steuern und ausführen sollte.
Der Fokus liegt auf Zusammenarbeit, Automatisierung sowie Einfachheit und spiegelt die Prinzipien aus anderen Ansätzen wider. Sie werden im Kapitel 3.1 (Die ITIL4-Grundprinzipien) detaillierter erläutert.
Practices
ITIL4 erweitert die Prozesse früherer ITIL-Versionen um zusätzliche Elemente wie Kultur, Technologie, Informations- und Datenmanagement. Diese ganzheitliche Vision einer Arbeitsweise wird als "Practice" bezeichnet und ist ein wesentlicher Bestandteil von ITIL4. Die altbekannten und vielfach implementierten Prozesse werden nun als Set von individuell kombinierbaren Praktiken dargestellt.
Diese insgesamt 34 Management-Praktiken sind zusammengehörige organisatorische Ressourcen, die auf die Erledigung bestimmter Aufgaben oder das Erreichen bestimmter Ziele ausgerichtet sind. Für jede Praktik enthält ITIL4 unterschiedliche Empfehlungen, wie z. B. wichtige Begriffe und Konzepte, Erfolgsfaktoren, wichtige Aktivitäten und Informationsobjekte [3]. Die ITIL4-Praktiken sind organisatorische Fähigkeiten, ein bestimmtes Gebiet zu beherrschen und sie bei Bedarf zur Anwendung zu bringen, damit das zur gemeinsamen Wertschöpfung beiträgt.
DevOps
DevOps als Kunstwort beschreibt eine Philosophie, die die beiden "Namensgeber" Development und Operations zusammenbringt. Das Ziel ist es, kontinuierliche Softwarebereitstellung sicherzustellen, um schneller auf Marktveränderungen reagieren zu können und Kundenanforderungen besser gerecht zu werden. Dabei sind die gegenläufigen Ansätze einer agilen Softwareentwicklung mit schneller und häufiger Lieferung von neuen Features und dem Anspruch eines sicheren und stabilen Betriebs in Einklang zu bringen. In der Praxis kann das Verständnis dieser Zielsetzung noch verbessert werden: Häufig wird DevOps lediglich als Aufbau einer kontinuierlichen Bereitstellung von neuen Features für Applikationen verstanden und damit eher auf die technische Sicht im Sinne einer Automation reduziert.
Die erfolgreiche Betrachtung des Lebenszyklus einer Anforderung der Fachbereiche von der ersten Formulierung bis zur produktiven Nutzung im Live-System erfordert jedoch einen umfassenderen Blick, der organisatorische, kulturelle und technische Belange berücksichtigt. DevOps baut als Antwort auf diese Herausforderung eine Brücke zur Zusammenarbeit zwischen Kunden, Entwicklung und Betrieb, um eine hochperformante IT-Organisation zu schaffen.
Im Unterschied zu bestehenden Frameworks wie ITIL oder Scrum ist DevOps kein neues Framework. Es gibt weder einen Rechteinhaber noch eine Institution, die sich als inhaltlicher Eigentümer des Begriffes "DevOps" oder gar weitergehender Inhalte sehen kann. Insofern existieren weder allgemeingültige Definitionen noch Vorgaben, was zum Aufbau einer DevOps-Organisation sinnvoll und notwendig ist. Eine wachsende Community hat sich etabliert, um eigene Erfahrungen, praktische Überlegungen und Sichtweisen auszutauschen und so diese Philosophie in aller Öffentlichkeit und gemeinsam weiter zu entwickeln. In deutschen Unternehmen etablieren sich mehr und mehr Initiativen, die sich mit den Inhalten, Gestaltungsmöglichkeiten und Vorteilen von DevOps beschäftigen. Beim Ziel, über die DevOps-Philosophie eine hoch performante IT-Organisation aufzubauen, können 5 Handlungsfelder betrachtet werden (Abb. 3).

Basis einer DevOps-Organisation ist die passende Kultur. Dabei sind Aspekte wie kontinuierliches Lernen und Experimentieren, das Streben nach eingebauter Qualität und die Übernahme von Verantwortung sowie crossfunktionale Zusammenarbeit anstelle funktionaler Silos im Sinne von Kollaboration von Bedeutung.
Die Gestaltung der Organisation referenziert u. a. auf Conways Law [4] und versucht produktorientierte Teams zu etablieren sowie über die Architektur eine hohe Unabhängigkeit der Teams zu erreichen. Diese Teams erhalten eine höhere Autonomie und mehr Verantwortung.
Einher damit gehen im Handlungsfeld Prozesse prinzipielle Änderungen, wie bspw. die Verschiebung des Fokus weg von Projekten und hin zu Produkten sowie auf Teams anstatt Spezialisten. Die Teams organisieren sich nach bekannten Methoden wie Scrum oder Kanban und übernehmen auch Betriebsverantwortung/-aufgaben.
Weiteres Element bei der Gestaltung einer DevOps-Organisation ist die durchgängige Automation, beginnend bei der Infrastruktur (Everything as code) bis in die Produktion (Continuous Delivery) sowie der Nutzung von Cloud-Prinzipien und -Technologie.
Um die hochperformante Organisation stetig weiterzuentwickeln, ist das fünfte Handlungsfeld die Etablierung einer kontinuierlichen Verbesserung, u. a. durch einen entsprechenden Prozess. Für diesen wird bspw. auf das 3-Wege-Modell von Gene Kim referenziert [5]. Es werden erprobte Methoden aus dem Lean-Management und anderen betriebswirtschaftlichen Ansätzen genutzt.
3 ITIL und DevOps im Vergleich
Die ITIL4-Grundprinzipien
Die ITIL-Grundprinzipien bilden die Basis von ITIL4. Sie wurden unter dem Titel ITIL Practitioner erstmals 2015 entwickelt und veröffentlicht und im Jahr 2018/2019 für ITIL4 überarbeitet. Diese Grundprinzipien unterstützen IT-Organisationen dabei, die ITIL-Leitlinien zu übernehmen und an ihre individuellen Gegebenheiten anzupassen. Sie sollten in jeder Phase der Bereitstellung von Services eingehalten werden. Sie ermöglichen in der Anwendung von ITIL die sinnvollen Ansätze zu definieren und notwendige Entscheidungen nachvollziehbar zu treffen. Damit erfüllen sie die gleiche Zielsetzung wie bspw. die 12 Prinzipien des Agilen Manifests [6] oder die Scrum-Werte für agile Produktentwicklung [7].
Die ITIL-Grundprinzipien sind:
- Werteorientierung
- Dort beginnen, wo man steht
- Sich iterativ entwickeln und Feedback einbeziehen
- Zusammenarbeit und die Sichtbarkeit fördern
- Ganzheitlich denken und arbeiten
- Auf Einfachheit und Praktikabilität achten
- Optimieren und Automatisieren
und werden im Folgenden detaillierter erläutert.
Werteorientierung
Alles, was die Organisation unternimmt (operative Tätigkeiten, Projekte, weitere Aktivitäten und Initiativen, usw.), sollte direkt oder indirekt mit dem Wert für die Organisation selbst, deren Kunden und anderen Stakeholdern in Beziehung gesetzt werden. Die konkrete Gestaltung kann je nach Organisation unterschiedlich ausgeprägt sein und bspw. Umsatz, Kosten, EBIT oder Wachstum bedeuten. Diese übergeordnete Zielsetzung wird in Wertströmen (Value Streams) konkretisiert.
Ein Wertstrom ist eine Reihe von Aktivitäten, die eine Organisation unternimmt, um Produkte und Services für den Kunden zu entwickeln und bereitzustellen. Er kombiniert die Wertschöpfungsaktivitäten der Organisation. Die Optimierung der Wertströme kann die Prozessautomatisierung oder die Umstellung auf neue Technologien und Arbeitsweisen beinhalten, um die Effizienz zu steigern oder die Anwenderzufriedenheit zu verbessern.
ITIL4 stellt damit deutlich den Mehrwert des Kunden in den Mittelpunkt. Während in der Version 1 reine Funktionen beschrieben wurden, wechselte der Fokus in Version 2 zu den Prozessen und in der Version 2011 zum Service.
Dort beginnen, wo man steht
Es ist in der Regel nicht notwendig, etwas völlig Neues zu erstellen. Bevor Veränderungen angegangen werden, sollte immer der Status Quo betrachtet und gewürdigt werden. Es geht also einerseits darum, zu verstehen, was im aktuellen Zustand gut funktioniert und was weiterentwickelt werden kann. Andererseits verweist dieses Prinzip darauf, was die konkreten Schwachpunkte sind, die es zu verbessern gilt.
In der Organisation befindet sich viel Nützliches, auf dem man aufsetzen kann. Wichtig ist eine Bewertung des aktuellen Zustands, um die weiteren Nutzungsmöglichkeiten richtig zu verstehen. Das sollte eine sinnvolle Kombination von Messung und Beobachtung vorhandener Services und Methoden sein.
Allein aus Gründen der Akzeptanz in der Organisation sollte man nicht Bestehendes ungeprüft verwerfen und prinzipiell immer etwas Neues erschaffen. Mit Blick auf die systemischen Gesetzmäßigkeiten sollte berücksichtigt werden, was bereits besteht und genutzt werden kann. Systemische Gesetzmäßigkeiten sind psychologische Wirkungsgesetze. Ähnlich wie die Naturgesetze sind sie immer wirksam. Sie "gelten" unabhängig davon, ob es im System ein Bewusstsein dafür gibt oder nicht. Verstößt ein System (Team, Abteilung, Bereich) gegen diese Prinzipien, entstehen Konflikte. In den systemischen Gesetzmäßigkeiten wird u. a. beschrieben: "Was ist, muss anerkannt werden" und es gilt ein "Recht auf Zugehörigkeit". Es gibt in jeder Organisation sehr viel Nützliches in den aktuellen Services, den bestehenden Prozessen und Programmen sowie Projekten und bei vielen Mitarbeitern.
Sich iterativ weiterentwickeln und Feedback einbeziehen
Auch große Initiativen sollten iterativ durchgeführt werden. Die Aufteilung der Aufgaben in kleinere, überschaubare Bereiche ermöglicht eine zeitnahe Durchführung und schnellen Abschluss. Damit ist der Fokus für jede Initiative einfacher zu erreichen und die einzusetzende Energie kann zielgerichteter eingesetzt werden.
Das geplante Ergebnis der Gesamtinitiative wird durch die kleinen Schritte inkrementell erreicht. Die laufende Bewertung und eventuelle Überarbeitung stellt sicher, dass veränderten Gegebenheiten Rechnung getragen werden kann. Fortschritte werden schnell sichtbar und die Nutzung von Feedback hilft bei der kontinuierlichen Ausrichtung am Ziel.
Dieses Vorgehen sollte sich im Einklang mit dem Konzept des Minimum Viable Products (MVP) befinden [8]. ITIL4 definiert das MVP als Produkt mit nur den nötigsten Funktionen, um frühe Kunden zufriedenzustellen und Feedback für die künftige Produktentwicklung zu geben.
Durch die Aufteilung der Aufgaben in überschaubare Lieferobjekte, die schnell ausgeführt und abgeschlossen werden können, wird der Fokus auf die Aktivitäten stärker und einfacher zu halten sein. Die Vision des IT-Service-Managements muss dabei kontinuierlich neu bewertet und gegebenenfalls überarbeitet werden, um Veränderungen Rechnung zu tragen und sicherzustellen, dass die Konzentration auf den Wert (s. Prinzip 1) nicht außer Acht gerät.
Zusammenarbeit und Sichtbarkeit fördern
Die Wahrscheinlichkeit eines langfristigen Erfolgs kann gesteigert werden, wenn die Initiativen die richtigen Personen für die richtigen Rollen einbeziehen. Kooperation und Zusammenarbeit sind in der heutigen Zeit sinnvoller als isolierte Arbeit ("Silodenken"), die häufig durch Prozesse, Systeme, Dokumentation und Kommunikation in einzelnen Geschäftseinheiten ausgelöst wird.
Die Zusammenarbeit sollte nicht nur zwischen den zunächst offensichtlichen Beteiligten erfolgen (bspw. Entwickler mit Operation-Teams = DevOps), sondern weitergedacht werden (bspw. Kunden und Stakeholder, d. h. "Biz" einbeziehen = BizDevOps). Diese Form der Zusammenarbeit erfordert von den Beteiligten gegenseitige Information, ein gemeinsames Verständnis und Vertrauen. Ergebnisse sollten sichtbar gemacht und Informationen ausgetauscht werden.
Um Verbesserungen angemessen umzusetzen, sollte der Arbeitsfluss mit seinen Ergebnissen sichtbar gemacht werden (Transparenz) und von allen Beteiligten verstanden werden. Hier kann der Ansatz des Value Stream Mappings sehr gut genutzt werden, gerade weil die fehlende Visualisierung häufig auf ein Kommunikationsproblem oder Siloarbeit hinweist.
Dann kann eine Identifizierung von Engpässen und den Verschwendungsarten des Lean-Management erfolgen [9]. Dieses Prinzip beruht folglich auf der Einsicht, dass die Zusammenarbeit über Grenzen hinweg zu Ergebnissen führt, die einen höheren Wert sowie eine höhere Bedeutung für die Ziele haben und damit auch die Wahrscheinlichkeit eines langfristigen Erfolgs steigert.
Ganzheitlich denken und arbeiten
Kein Service, keine Praktik, kein Prozess, keine Abteilung und kein Supplier stehen allein. Die Arbeitsergebnisse werden hochwertiger, wenn sie integriert erarbeitet werden. Aus der isolierten Sicht der Arbeit mag sogar die Einschätzung zutreffen, dass es einfacher ist, den eigenen Teil der Arbeit isoliert von anderen zu leisten. Die Services und Produkte von heute sind jedoch zu komplex. Ein ganzheitlicher Ansatz für das IT-Service-Management beinhaltet das Verständnis dafür, wie alle Teile eines Unternehmens zusammenwirken. Im Prinzip muss man den gesamten Wertestrom im Blick haben, um den Durchsatz zu erhöhen und die gegenseitige Abhängigkeit zu erkennen (Auswirkungen identifizieren, analysieren und planen) und zu verringern. In solch komplexen Systemen kann sich die Veränderung eines Teils vielfältig auf andere auswirken, es ist daher eine durchgängige Transparenz erforderlich, wie die Nachfrage erfasst und in Wert umgesetzt wird.
Alle Aktivitäten der Organisation sollten sich auf die Wertschöpfung konzentrieren und die vier Dimensionen des Service-Managements (Organisation und Personen, Information und Technologie, Partner und Lieferant, Wertströme und Prozesse) einbeziehen. Alle Beteiligten müssen ein Verständnis entwickeln, wie die Teile einer Organisation auf eine integrierte Weise zusammenarbeiten. Das erfolgt durch umfassende Transparenz in allen Schritten des Wertstroms.
Auf Einfachheit und Praktikabilität achten
Ergebnisorientiertes Denken sollte im Vordergrund stehen, um Lösungen zu entwickeln. Diese praktische Form der Werteorientierung führt zu entsprechend wertvollen Ergebnissen. Wenn ein Prozess, ein Service, eine Aktion oder eine Metrik keinen Wert liefert, kann er/sie eliminiert werden. Der Versuch, für jede Ausnahme eine Lösung zu finden, führt oft zu einer unnötigen Verkomplizierung. Zielsetzung sollten Regeln sein, die zur allgemeinen Behandlung von Ausnahmen verwendet werden können. Entscheidend für ein einfaches und praktisches Service-Management ist es, genau zu verstehen, wie etwas zur Wertschöpfung beiträgt. Einfachheit ist dabei die ultimative Raffinesse: "Perfektion ist nicht dann erreicht, wenn man nichts mehr hinzufügen, sondern nichts mehr weglassen kann." (Antoine de Saint-Exupéry).
Organisationen sollten Automatisierung anstreben, um die Verschwendung von Ressourcen zu vermeiden.
Einfache Abläufe werden zudem schneller von den Beteiligten verstanden und akzeptiert. Es ist nicht nötig, in einem Prozess jede nur erdenkliche Variante abzubilden. Der Standardablauf muss einfach bleiben und kann sich an dem Prinzip "Minimum Viable Process" orientieren [10].
Optimieren und Automatisieren
Moderne Organisationen müssen den Wert der Arbeit, die von ihren menschlichen und technischen Ressourcen geleistet wird, maximieren. Technologie kann Organisationen helfen, häufige und sich wiederholende Aufgaben zu bewältigen, so dass die Beteiligten für komplexere Entscheidungsvorgänge freie Kapazitäten erhalten.
Alle Ressourcen sollten produktiv (effektiv und effizient) eingesetzt werden. Organisationen sollten daher, wo immer es sinnvoll ist, eine Automatisierung anstreben, um die Verschwendung von Ressourcen zu vermeiden. Menschliche Arbeit und Unterstützung sollten nur dort geschehen, wo sie einen wirklichen Mehrwert liefern.
Die Automatisierung von Standard- und Wiederholungsaufgaben kann in diesem Zusammenhang nicht nur den Einsatz des Personals optimieren, sondern auch ihre jeweilige Erfahrung und das Wissen verbessern. Zudem werden Organisationskosten gesenkt und Quellen für menschliche Fehler reduziert.
Die DASA DevOps-Prinzipien
Die DevOps Agile Skills Association (DASA) unterstützt die DevOps-Bewegung mit einem Kompetenzframework für IT-Mitarbeiter. Dieses Kompetenzframework basiert auf den sechs DASA DevOps-Prinzipien. Sie beschreiben grundlegend, wie eine IT-Organisation sich und vor allem seine Mitarbeiter in Richtung DevOps entwickeln sollte.
DASA DevOps-Prinzip 1: Customer-Centric Action
Kundenzentriertheit im DevOps bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Aus der agilen Softwareentwicklung ist dieser Ansatz in Form eines Reviews (Fachlich) und einer Retrospektive (Zusammenarbeit) nach jeder Iteration bekannt und hat sich als sehr erfolgreich herausgestellt.
Um die gesamte Wertschöpfungskette in der IT zu unterstützen, muss das Feedback bis zur produktiven Nutzung ausgedehnt werden. Dabei werden bspw. A/B-Tests eingesetzt oder einfach das Nutzungsverhalten analysiert. Alle Aktivitäten der Serviceerbringung müssen sich an den Kunden und Anwendern orientieren.
Die beschriebene Ausrichtung an der Wertschöpfungskette muss zu einer permanenten Überprüfung der Aktivitäten führen, so dass überflüssige Arbeiten schnell erkannt und eliminiert werden. IT-Organisationen müssen dazu die Fähigkeit erlangen, sich ähnlich wie junge Start-ups kontinuierlich neu zu erfinden und schnell auf veränderte Einflüsse zu reagieren.
Konkret heißt das, mit Blick auf die Verschwendungsarten aus dem Lean-Management den Fokus auf die Vermeidung von Verschwendung zu legen. Das resultiert in einer kontinuierlichen Weiterentwicklung der Strategie und den daraus abgeleiteten Aktivitäten, auch durch kontinuierliche Investition in Produkte und Services mit Blick auf ein Höchstmaß an Kundenzufriedenheit.
Ziel sollte es sein, das Thema Servicequalität stärker in den Köpfen der IT-Mitarbeiter zu verankern. Dazu gehören dann neben der Anpassung in der eigentlichen Umsetzung auch das Umdenken in der täglichen Arbeit der Mitarbeiter und die Offenheit für neues Vorgehen. Die Kundenorientierung sollte darüber hinaus auch organisatorische Veränderungen nach sich ziehen, bspw. durch Auflösen der bestehenden organisatorischen Silos zugunsten von produktorientierten Teams.
DASA DevOps-Prinzip 2: Create with the End in Mind
Mit dem Prinzip "Schon zu Beginn an das Ergebnis denken" versucht DevOps, die prozessorientierte Vorgehensweise mit individuellen Rollen und Funktionen in eine produktorientierte Organisation zu verwandeln. Diese agiert mit dem Ziel, funktionierende Produkte an Kunden zu liefern und mit einer dazu passenden Denkweise zu agieren. Diese Zielsetzung manifestiert sich in der entsprechenden Aufbau- und Ablauforganisation. Diese muss den Überblick über das übergeordnete und angestrebte Ergebnis sicherstellen.
Wichtig ist, dass die beteiligten Mitarbeiter diese durchgängige Sichtweise verinnerlicht haben, um daraus ableitend Produkte und Service zu erschaffen. IT-Organisationen müssen als Produktunternehmen agieren, die sich explizit darauf konzentrieren, funktionierende Produkte zu entwickeln, die an Kunden geliefert werden.
Alle Beteiligten müssen die umfassende Denkweise teilen, die erforderlich ist, um diese Produkte zu konzipieren und zu realisieren. Es gibt ein Team für ein Produkt und es übernimmt die Verantwortung für alle Prozesse, Funktionen und Aktivitäten innerhalb dieses Produktes.
Dieser Ansatz verfolgt das Ziel, das Ganze zu sehen und zu erkennen und nicht nur ein Teil einer Prozesskette oder einer Funktion zu sein. Weiterhin erreicht dieser Ansatz die drastische Reduzierung der Kommunikation mit anderen Abteilungen und sorgt durch die permanente Verkürzung und Verstärkung der Rückkopplungsschleifen für ein immer stabileres und sichereres Arbeitssystem.
DASA DevOps-Prinzip 3: End-To-End Responsibility
Eine Ende-zu-Ende-Verantwortung bedeutet aus Sicht von DevOps, dass die traditionelle Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams ("Von der Wiege bis zur Bahre") aufgelöst wird. Diese Teams entwickeln und betreiben die Services, ebenso wie sie Support leisten. Dieser Umstand erhöht deutlich das Niveau der gefühlten und realen Verantwortung und somit die Qualität der entwickelten Produkte und Services, denn im Sinne des RACI-Modells liegt sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team [12].
Die IT kann mit dieser Verantwortung wieder den Fokus auf das IT-Produkt bzw. den Service setzen. Durch produktverantwortliche Teams können stabilere und qualitativ hochwertigere IT-Produkte als bisher entwickelt werden. Hierbei müssen bestehende Organisationen, Prozesse und Arbeitsweisen analysiert und dem Prinzip angepasst werden. Eine neue Denkweise innerhalb des Unternehmens ist dabei erforderlich. Je nach genutztem IT-Produkt können hierbei unterschiedliche Zielsetzungen angegangen werden.
DASA DevOps-Prinzip 4: Cross-Functional Autonomous Teams
Die Forderung nach crossfunktionalen, autonomen (vertikal organisierten) Teams aus Sicht von DevOps ist eine Weiterentwicklung agiler Ansätze. Scrum als bekanntestes agiles Framework setzt ebenfalls auf diese Teamorganisation. Um eine hochwertige Serviceerbringung sicherzustellen, ist ein fein ausbalanciertes Set an Wissen und Fähigkeiten notwendig.
Es ist also ein eher generalistisches Profil im Team und bei den Teammitgliedern anstelle des klassischen IT-Spezialisten notwendig. Das bedeutet nicht, dass diese Teams keine Spezialisten mehr benötigen. Ähnlich wie bei einer guten Fußballmannschaft sollte jedoch jeder Spieler das Ganze im Blick haben ("Gute Verteidigung beginnt beim Stürmer!") und flexibel auf verschiedenen Positionen einsetzbar sein ("Es spielen nicht immer die elf Besten, sondern die beste Elf").
Cross-funktionale, autonome Teams können somit Innovationen ganzheitlich denken. Gleichzeitig können sie das gesamte Aufgabenspektrum über den kompletten Produktlebenszyklus eigenverantwortlich und in effizienter Zusammenarbeit erledigen. Voraussetzung ist dabei der Kulturwandel in den IT-Organisationen. Er wird begleitet durch eine schlanke Teamorganisation und -steuerung sowie die vielseitigen Fähigkeiten der Mitarbeiter. So wird das Team gemeinsam zum Unternehmenserfolg beitragen.
DASA DevOps-Prinzip 5: Continuous Improvement
Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an verändernde Bedingungen (Kundenanforderungen, technologische Rahmenbedingungen, Gesetze und Verordnungen, usw.) anpassen können müssen. DevOps setzt dabei auf Prinzipien von Lean-Management, um Verschwendung zu vermeiden sowie Kosten zu senken und die Liefergeschwindigkeit zu erhöhen. Experimente werden gefördert und eine neue Fehlerkultur (Fail fast, fail offen) etabliert, die darauf abzielt, aus Fehlern zu lernen.
Für kontinuierliche Verbesserung müssen Rahmenbedingungen in den IT-Organisationen geschaffen werden: Eine Kultur, in der Experimente und Lernen aus Fehlern gefordert und gefördert wird, sowie der Transparenz durch Kennzahlen vorherrscht.
Ziel ist es, frühzeitig Veränderungsbedarfe zu erkennen und diese durch kontinuierliche Anpassung und Verbesserungen zu jeder Zeit vornehmen zu können. Diese Grundausrichtung benötigen IT-Organisationen für ihren individuellen Erfolg in dieser schnelllebigen Welt. Ein ideales Vorgehen (Best Practice) gibt es dabei nicht. Jedes Unternehmen muss selbst einen Weg als eigene Herausforderung und große Chance für den individuellen Erfolg finden.
DASA DevOps-Prinzip 6: Automate Everything You Can
"Automatisiere alles was du kannst!" ist eine im Prinzip unmissverständliche Forderung. Sie setzt unter anderem auf der kontinuierlichen Verbesserung auf bzw. unterstützt diese, um schnelle Lieferzyklen zu realisieren, die dann zu sofortigem Feedback durch die Kunden führen. Die Automation umfasst dabei nicht nur den Entwicklungsprozess, sondern auch die darunterliegende Infrastruktur.
Unter dem Begriff "Infrastructure as code" wird damit eine neue Art der Servicelieferung beschrieben, welche Prinzipien aus der Softwareentwicklung auf den IT-Betrieb überträgt. Standardisierung und Automation ist ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen, die der Maxime "Everything as code!" folgt.
Die weitreichende Forderung, alles, was möglich ist, zu automatisieren, stellt hohe Anforderungen an die IT-Organisation. Zunächst bezieht sich das auf die Development-Pipeline, da diese einen zentralen Prozess in der Softwareentwicklung darstellt. Die Integration von Continuous Delivery führt zu einer Anpassung der angrenzenden Prozesse und Systeme. Die Integration von On-Premise sowie Cloud-Komponenten erfordert dann ein hohes Skillset des DevOps-Teams, sodass zwar durch die Automatisierung Tätigkeiten auf die Systeme verlagert werden, aber neue und anspruchsvollere Tätigkeitsgebiete entstehen. Die Integration von DevOps in das Unternehmen endet hierbei nicht mit der Auslieferung von Softwarepaketen, sondern kann darüber hinaus weitere Relevanz erhalten. Beispielsweise werden klassische Testaktivitäten sowohl nach vorne (in die Konzeption und Entwicklung) als auch nach hinten (in Produktivsysteme) im Prozess verlagert.
Verändert sich die Unternehmenskultur von der eher klassischen und manuellen Ausrichtung hin zu Unternehmensprozessen mit besonderem Fokus auf Automatisierung, können die freien Ressourcen zur Verbesserung der Marktposition genutzt werden.
Die 6 DASA DevOps-Prinzipien
Das DASA DevOps-Kompetenzmodell und die 6 DevOps-Prinzipien wurden von Dierk Söllner bei Informatik Aktuell bereits in einer Artikelserie intensiv beschrieben.
Vergleich der Prinzipien
Beim Vergleich der Prinzipien stellt man fest, dass viele Überschneidungen bestehen, die teilweise nur unterschiedlich zugeordnet oder anders formuliert sind. Die Abb. 4 stellt die verschiedenen Verbindungen zwischen den ITIL4 und DevOps-Prinzipien dar, die in der Folge erläutert werden.
- Das Prinzip "Werteorientierung" aus ITIL korrespondiert mit dem DASA DevOps-Prinzip "Customer Centric Action". Das ITIL-Prinzip ist etwas umfassender und allgemeingültiger, weil es nicht nur den Kunden im Fokus hat und unterschiedliche Werte formuliert. Beide Prinzipien betonen die Orientierung am Outcome im Sinne von Resultat, Wirkung oder Ergebnis. Wertströme bzw. Wertstromketten sind dann richtigerweise eine mögliche Implementierung dieser Ausrichtung. Das ist eine Herausforderung vielfältiger Art für viele IT-Organisationen. Sie betrifft neben organisatorischen Veränderungen die Themen Führung sowie Arbeits- und Denkweise der Beteiligten. Für diese gilt das besonders dann, wenn sie durch mangelnde Sichtbarkeit ihre Wirksamkeit auf den Kundenwert und fehlendem Kundenkontakt kein Verständnis dafür entwickeln konnten.
- Die gleiche direkte Beziehung lässt sich zwischen dem ITIL-Prinzip "Optimieren und Automatisieren" sowie dem DASA DevOps-Prinzip "Automate everything you can" ziehen. Das ITIL-Prinzip formuliert dabei die Notwendigkeit einer Optimierung vor der Automatisierung prägnanter. Beide Prinzipien stellen die weitgehendende Notwendigkeit einer Automatisierung vieler Aktivitäten in den Vordergrund. IT-Organisationen müssen nun das, was jahrzehntelang Grundlage für die eigene Arbeit als Dienstleister für Kunden (Fachbereiche) war, bei sich umsetzen. Das externe Geschäftsmodell muss nun auf die interne Organisation übertragen werden. Interessant ist sicherlich auch die unterschiedliche Stoßrichtung: Während DevOps eher bottom-up aus den Teams heraus vorgeht, kommt ITIL4 über die Wertströme top-down.
- Die Prinzipienpaare "Zusammenarbeit und Sichtbarkeit fördern" und "Ganzheitlich denken und arbeiten" (ITIL) sowie "Create with the end in mind" und "End-to-end-responsibility" (DASA DevOps) adressieren jeweils zusammen die veränderte Art der Arbeitsweise. Übergreifende Zusammenarbeit aller Beteiligten ist notwendig und zielt auf verschiedene Aspekte wie Organisation, Verantwortung, Transparenz und Selbstverständnis ab.
- Das DASA DevOps-Prinzip "Continuous Improvement" ist recht allgemein gehalten und wird in den drei ITIL Prinzipien "Dort beginnen, wo man steht", "Auf Einfachheit und Praktikabilität achten“ sowie „Sich iterativ entwickeln und Feedback einbeziehen" formuliert. Die kontinuierliche Verbesserung ist in ITIL4 eine Komponente des Service Value Systems und das "Continual Improvement" eine Practice. Da DevOps auf agilen Methoden basiert, sind die dort beschriebenen Mechanismen (bspw. das Ereignis Retrospektive oder die Rolle Scrum Master) implizit auch in DevOps vorhanden.
- Für das DASA DevOps-Prinzip "Cross-Functional Autonomous Teams" findet sich kein explizit passendes ITIL-Prinzip. Beim Grundprinzip "Zusammenarbeit und Sichtbarkeit fördern" wird zwar hervorgehoben, dass die Silo-Aktivitäten vermieden werden müssen. Mit Hinweis auf DevOps wird eine echte, unverfälschte Zusammenarbeit gefordert, nicht jedoch zusammengehörig als Team. Daran zeigt sich ein grundlegender Unterschied beider Ansätze. DevOps fokussiert auf Basis agiler Ansätze die Teamorientierung. DevOps-Teams sind einerseits Produkt-Teams, die entsprechende Services an Kunden liefern. Diese wiederum setzen andererseits auf Services von Plattform-Teams auf. DevOps-Teams bilden also die organisatorische Umsetzung mit entsprechender Verantwortung für die eigenen Produkte bzw. Services ab. ITIL4 hält sich hier etwas zurück. Ein Grund könnte das in früheren ITIL-Versionen beschriebene Konstrukt von "Customer facing services" und "Supporting services" sein, welches die beschriebene Zusammenarbeit nicht auf Teamebene beschreibt, sondern virtuelle Konstrukte anhand der Services baut, die die funktional getrennten Einheiten zusammenführt.
Dieses Kapitel hat damit die Frage beantwortet, wie ähnlich sich beide Ansätze sind. Die jeweiligen Prinzipien zeigen eine weitgehend verwandte Ausrichtung ohne unüberbrückbare Widersprüche.
Im zweiten Teil des Artikels wollen wir uns mit den konkreten Kombinationsmöglichkeiten auseinandersetzen.
Teil 2: ITIL und DevOps im Zusammenspiel
Erfahren Sie alles über das Zusammenspiel von ITIL und DevOps im zweiten Teil des Artikels.
- ITIL is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved
- Zur Geschichte von ITIL: Wikipedia: IT Infrastructure Library
- ITIL 4
- Wikipedia: Gesetz vom Conway
- Gene Kim: The Three Ways: The Principles Underpinning DevOps
- Das Agile Manifest
- Scrum Guide
- Wikipedia: Minimum Viable Product
- 7 Verschwendungsarten
- Robert Falkowitz: Minimum viable process
- DevOps Agile Skills Association (DASA)
- Wikipedia: RACI