06750 DevOps – Chance oder Risiko für das IT Service Management?
|
Nach wie vor stehen Unternehmen vor vielfältigen und großen Herausforderungen. IT-Organisationen erleben diese als wichtiger Dienstleister in gleichem Maße und versuchen unter Zuhilfenahme von anerkannten Ansätzen (Scrum, ITIL, Kanban, DevOps usw.) darauf zu reagieren. Dabei existieren häufig noch Missverständnisse oder gar Ablehnung zwischen bestehenden Bereichen (wie beispielsweise zwischen Entwicklung und Betrieb) der IT-Organisation. Wir versuchen zu erklären, ob und wie die bekannten Ansätze ITIL und DevOps kombiniert werden können.
Nach einer kurzen Einführung in die Fragestellung wird die DevOps-Philosophie kurz dargestellt. Darauf werden die zugrunde liegenden Prinzipien von ITIL 4 und DevOps erläutert. Es wird davon ausgegangen, dass nicht jeder beide Ansätze und insbesondere die jeweiligen Prinzipien kennt. Wenn doch, können Sie den Abschnitt 3 überspringen. Im Anschluss wird die Frage beantwortet, ob eine Kombination von ITIL und DevOps möglich ist. Darauf aufbauend werden Vorschläge für eine Kombination geliefert und damit wird die Frage geklärt, wie die beiden Ansätze kombiniert werden können. Zum Abschluss geben wir auf der Basis einer kurzen Zusammenfassung einen Ausblick. von: |
1 Einführung
Lange Zeit hat ITIL als Standardframework für Service Management keine Antwort auf die aktuellen Herausforderungen in modernen IT-Organisationen geben können, wenn es um die Integration von agilen Methoden und die Öffnung hinsichtlich neuer Ansätze zur Bewältigung der Herausforderungen wie disruptive Veränderung in Geschäftsmodellen oder Digitalisierung ging. Viele Unternehmen haben daher im Zuge von agilen Veränderungsprojekten auf den DevOps-Ansatz gesetzt. Damit wird häufig versucht, agile Ansätze unternehmensweit zu etablieren, um die eigene Organisation flexibler und anpassungsfähiger zu gestalten.
Skalierungsansatz für agile Unternehmen?
Mit ITIL 4 steht nun ein Framework für agiles Service Management bereit, das ITIL explizit in Richtung von agilen Ansätzen öffnet und für eine neuartige Nutzung bereitmacht (s. a. Kap. 03810). 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”. ITIL 4 könnte dabei sogar als Skalierungsansatz für agile Unternehmen verstanden werden.
Mit ITIL 4 steht nun ein Framework für agiles Service Management bereit, das ITIL explizit in Richtung von agilen Ansätzen öffnet und für eine neuartige Nutzung bereitmacht (s. a. Kap. 03810). 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”. ITIL 4 könnte dabei sogar als Skalierungsansatz für agile Unternehmen verstanden werden.
Wenn also die These zutrifft, dass die aktuellen Herausforderungen zu umfangreich für einen Ansatz sind, wäre eine Kombination verschiedener Ansätze sinnvoll. Damit könnten zeitgemäße Antworten gefunden werden, indem beispielsweise DevOps und ITIL 4 geschickt kombiniert werden. Dazu müsste sichergestellt sein, dass sich beide Ansätze sinnvoll ergänzen lassen und diese Kombination einen validen Nutzen bringt. Wir stellen uns dieser Fragestellung in zwei Stufen:
| • | Lassen sich die bekannten Ansätze ITIL und DevOps kombinieren? |
| • | Wenn ja: Wie können IT-Organisationen dabei vorgehen und welchen Nutzen können Sie daraus ziehen? |
2 DevOps im Überblick
Entwicklung und Betrieb
DevOps als Kunstwort beschreibt eine Philosophie, die die beiden „Namensgeber” (Entwicklung und Betrieb) 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 hoch performante IT-Organisation zu schaffen.
DevOps als Kunstwort beschreibt eine Philosophie, die die beiden „Namensgeber” (Entwicklung und Betrieb) 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 hoch performante IT-Organisation zu schaffen.
Communitygetriebenes Framework
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 Begriffs „DevOps” sehen kann. Bei genauem Hinschauen sucht man auch rechtliche Hinweise wie ® bei ITIL oder ™ wie beim Scrum Guide vergeblich. 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.
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 Begriffs „DevOps” sehen kann. Bei genauem Hinschauen sucht man auch rechtliche Hinweise wie ® bei ITIL oder ™ wie beim Scrum Guide vergeblich. 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.
Fünf Handlungsfelder
Beim Ziel, über die DevOps-Philosophie eine hoch performante IT-Organisation aufzubauen, können fünf Handlungsfelder betrachtet werden: Kultur, Prozesse, Organisation, Automation und Kontinuierliche Verbesserung (vgl. Abbildung 1).
Beim Ziel, über die DevOps-Philosophie eine hoch performante IT-Organisation aufzubauen, können fünf Handlungsfelder betrachtet werden: Kultur, Prozesse, Organisation, Automation und Kontinuierliche Verbesserung (vgl. Abbildung 1).
Kultur ist die Basis
Basis einer DevOps-Organisation ist die passende Kultur. Dabei sind Aspekte wie kontinuierliches Lernen und Experimentieren, das Streben nach eingebauter Qualität sowie die Übernahme von Verantwortung von Bedeutung. Die Gestaltung der Organisation referenziert u. a. auf Conways Law [1] und versucht produktorientierte Teams zu etablieren sowie über die Architektur eine hohe Unabhängigkeit der Teams zu erreichen. 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 (Lesetipp dazu [2]). Die Teams organisieren sich nach bekannten Methoden wie Scrum oder Kanban und übernehmen auch Betriebsaufgaben. Weiteres Element bei der Gestaltung einer DevOps-Organisation ist dann die durchgängige Automation, beginnend bei der Infrastruktur (Everything as code) bis in die Produktion (Continuous Delivery) sowie die Nutzung von Cloud-Prinzipien und -Technologie. Um die hoch performante Organisation stetig weiter zu entwickeln, ist das letzte Handlungsfeld die Etablierung einer kontinuierlichen Verbesserung, u. a. durch einen entsprechenden Prozess. Für diesen wird auf das Drei-Wege-Modell von Gene Kim referenziert [3].
Basis einer DevOps-Organisation ist die passende Kultur. Dabei sind Aspekte wie kontinuierliches Lernen und Experimentieren, das Streben nach eingebauter Qualität sowie die Übernahme von Verantwortung von Bedeutung. Die Gestaltung der Organisation referenziert u. a. auf Conways Law [1] und versucht produktorientierte Teams zu etablieren sowie über die Architektur eine hohe Unabhängigkeit der Teams zu erreichen. 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 (Lesetipp dazu [2]). Die Teams organisieren sich nach bekannten Methoden wie Scrum oder Kanban und übernehmen auch Betriebsaufgaben. Weiteres Element bei der Gestaltung einer DevOps-Organisation ist dann die durchgängige Automation, beginnend bei der Infrastruktur (Everything as code) bis in die Produktion (Continuous Delivery) sowie die Nutzung von Cloud-Prinzipien und -Technologie. Um die hoch performante Organisation stetig weiter zu entwickeln, ist das letzte Handlungsfeld die Etablierung einer kontinuierlichen Verbesserung, u. a. durch einen entsprechenden Prozess. Für diesen wird auf das Drei-Wege-Modell von Gene Kim referenziert [3].
3.1 DASA DevOps-Prinzipien
DevOps Agile Skills Association
Die DevOps Agile Skills Association (DASA) [4] unterstützt die DevOps-Bewegung mit einem Kompetenzframework für IT-Mitarbeiter. Dieses Kompetenzframework basiert auf den sechs DevOps-Prinzipien der DASA. Sie beschreiben grundlegend, wie eine IT-Organisation sich und vor allem ihre Mitarbeiter in Richtung DevOps entwickeln sollte (weiterführende Beschreibung s. [5]).
Die DevOps Agile Skills Association (DASA) [4] unterstützt die DevOps-Bewegung mit einem Kompetenzframework für IT-Mitarbeiter. Dieses Kompetenzframework basiert auf den sechs DevOps-Prinzipien der DASA. Sie beschreiben grundlegend, wie eine IT-Organisation sich und vor allem ihre Mitarbeiter in Richtung DevOps entwickeln sollte (weiterführende Beschreibung s. [5]).
3.1.1 DASA DevOps-Prinzip 1: Customer-Centric Action
DevOps-Perspektive
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, sodass ü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, um schnell auf veränderte Einflüsse zu reagieren.
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, sodass ü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, um schnell auf veränderte Einflüsse zu reagieren.
Vermeidung von Verschwendung
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.
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 ein 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 (weiterführende Darstellung s. [6]).
ITSM-Perspektive
Aus Sicht des ITSM ist das eine Veränderung. Auch wenn Frameworks wie ITIL den Kunden/Anwender mit der Serviceorientierung in den Mittelpunkt stellen, ist der DevOps-Gedanke weitergehend. Die Verantwortung für einen Service wird einem Team vollumfänglich übertragen und die Organisation so gestaltet, dass das Feedback des Kunden viel intensiver eingeholt und verarbeitet wird. Während in IT-Service-Management-Organisationen ein Service Owner bzw. Manager selten ausreichend Mittel und Befugnisse hat, Kundenbedürfnisse umzusetzen, ist das durch ein Business Service Team rund um einen Service bzw. ein Produkt in DevOps zielgerichteter gestaltet.
Aus Sicht des ITSM ist das eine Veränderung. Auch wenn Frameworks wie ITIL den Kunden/Anwender mit der Serviceorientierung in den Mittelpunkt stellen, ist der DevOps-Gedanke weitergehend. Die Verantwortung für einen Service wird einem Team vollumfänglich übertragen und die Organisation so gestaltet, dass das Feedback des Kunden viel intensiver eingeholt und verarbeitet wird. Während in IT-Service-Management-Organisationen ein Service Owner bzw. Manager selten ausreichend Mittel und Befugnisse hat, Kundenbedürfnisse umzusetzen, ist das durch ein Business Service Team rund um einen Service bzw. ein Produkt in DevOps zielgerichteter gestaltet.
3.1.2 DASA DevOps-Prinzip 2: Create with the End in Mind
DevOps-Perspektive
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 das übernimmt die Verantwortung für alle Prozesse, Funktionen und Aktivitäten innerhalb dieses Produkts. 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 (weiterführende Darstellung s. [7]).
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 das übernimmt die Verantwortung für alle Prozesse, Funktionen und Aktivitäten innerhalb dieses Produkts. 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 (weiterführende Darstellung s. [7]).
ITSM-Perspektive
Die im ITSM anzutreffende Prozessorganisation mit Arbeitsteilung und einer Fokussierung auf Aktivitäten ist einer hohen Kundenzufriedenheit nicht zuträglich. Die einzelnen Prozessteilnehmer verfolgen eigene Ziele und sind häufig nur daran interessiert, ihre beschriebenen Prozessschritte auszuführen. In einer an DevOps-Ideen ausgerichteten IT-Organisation wandelt sich die Orientierung vom Spezialistentum (in komplexen Prozessen eingegliedert) hin zu einer Ausrichtung an der Arbeit und dem Ergebnis. Die Organisation entwickelt sich dabei von der Funktionsorientierung (in Prozessabläufen verbunden) zu einem teambasierten Aufbau. Der Fokus verschiebt sich von Projekten auf Produkte („You build it, you run it.”) und die Arbeit bezieht sich zukünftig nicht mehr auf Einzelne, sondern auf Teams.
Die im ITSM anzutreffende Prozessorganisation mit Arbeitsteilung und einer Fokussierung auf Aktivitäten ist einer hohen Kundenzufriedenheit nicht zuträglich. Die einzelnen Prozessteilnehmer verfolgen eigene Ziele und sind häufig nur daran interessiert, ihre beschriebenen Prozessschritte auszuführen. In einer an DevOps-Ideen ausgerichteten IT-Organisation wandelt sich die Orientierung vom Spezialistentum (in komplexen Prozessen eingegliedert) hin zu einer Ausrichtung an der Arbeit und dem Ergebnis. Die Organisation entwickelt sich dabei von der Funktionsorientierung (in Prozessabläufen verbunden) zu einem teambasierten Aufbau. Der Fokus verschiebt sich von Projekten auf Produkte („You build it, you run it.”) und die Arbeit bezieht sich zukünftig nicht mehr auf Einzelne, sondern auf Teams.
3.1.3 DASA DevOps-Prinzip 3: End-To-End Responsibility
DevOps-Perspektive
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 [8] liegt sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team.
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 [8] liegt sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team.
Die IT erreicht mit dieser Sichtweise, wieder den Fokus auf das IT-Produkt und den Kunden zu setzen. Durch produktverantwortliche Teams können stabilere und qualitativ hochwertigere IT-Produkte als bisher entwickelt werden. Dabei 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 dabei unterschiedliche Zielsetzungen angegangen werden (detaillierte Beschreibung s. [9]).
ITSM-Perspektive
Aus Sicht von IT Service Management ergänzt dieses Prinzip die beiden vorherigen. Die herkömmlich in Prozesse und Abteilungen aufgeteilten Aktivitäten und die aufgesplittete Verantwortung werden in einem Service Team zusammengeführt. Dieses Business Service Team führt alle Tätigkeiten für die Entwicklung und den Betrieb eines Service aus und hat die komplette Verantwortung dafür.
Aus Sicht von IT Service Management ergänzt dieses Prinzip die beiden vorherigen. Die herkömmlich in Prozesse und Abteilungen aufgeteilten Aktivitäten und die aufgesplittete Verantwortung werden in einem Service Team zusammengeführt. Dieses Business Service Team führt alle Tätigkeiten für die Entwicklung und den Betrieb eines Service aus und hat die komplette Verantwortung dafür.
3.1.4 DASA DevOps-Prinzip 4: Cross-Functional Autonomous Teams
DevOps-Perspektive
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 sehr gutes T-Shaped-Profil im Team und bei den Teammitgliedern notwendig anstelle des klassischen IT-Spezialisten. Ein T-Shaped Professional vereint dabei die Vorteile des Spezialisten mit denen eines Generalisten. 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.
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 sehr gutes T-Shaped-Profil im Team und bei den Teammitgliedern notwendig anstelle des klassischen IT-Spezialisten. Ein T-Shaped Professional vereint dabei die Vorteile des Spezialisten mit denen eines Generalisten. 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.
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 (umfassende Erläuterung s. [10]).
ITSM-Perspektive
Dieses Prinzip kämpft in der praktischen Umsetzung mit ähnlichen Schwierigkeiten, wie sie das IT Service Management kennt. Die Anforderungen an die Mitarbeiter wandeln sich noch stärker, und es bedarf einer intensiven und umfangreichen Personal- und Organisationsentwicklung, um die „altgedienten” Menschen zu befähigen. Die Erfahrungen aus einer Neuausrichtung der Mitarbeiter an Prozess- und Serviceorientierung können nun auf Team- und Kundenorientierung angewendet werden.
Dieses Prinzip kämpft in der praktischen Umsetzung mit ähnlichen Schwierigkeiten, wie sie das IT Service Management kennt. Die Anforderungen an die Mitarbeiter wandeln sich noch stärker, und es bedarf einer intensiven und umfangreichen Personal- und Organisationsentwicklung, um die „altgedienten” Menschen zu befähigen. Die Erfahrungen aus einer Neuausrichtung der Mitarbeiter an Prozess- und Serviceorientierung können nun auf Team- und Kundenorientierung angewendet werden.
3.1.5 DASA DevOps-Prinzip 5: Continuous Improvement
DevOps-Perspektive
Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an sich 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 often”) etabliert, die darauf abzielt, aus Fehlern zu lernen.
Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an sich 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 often”) 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 akzeptiert sowie unterstützt wird und in 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 (ausführlichere Darstellung s. [11]).
ITSM-Perspektive
ITIL hat bis zur Version 2011 eine eigene Lebenszyklusphase und damit auch eine eigene Publikation, die sich mit der kontinuierlichen Verbesserung beschäftigt. Darin bietet sich nun die Möglichkeit, die agilen Prinzipen und Erfahrungen zu integrieren. Kontinuierliche Verbesserung ist in agilen Ansätzen noch stärker etabliert und in die tägliche Arbeit integriert. Die eher statische Behandlung in klassischen Ansätzen kann bspw. durch Daily Stand-ups und Retrospektiven erweitert werden. In ITIL 4 ist kontinuierliche Verbesserung an zentraler Stelle im Service Value System verankert worden.
ITIL hat bis zur Version 2011 eine eigene Lebenszyklusphase und damit auch eine eigene Publikation, die sich mit der kontinuierlichen Verbesserung beschäftigt. Darin bietet sich nun die Möglichkeit, die agilen Prinzipen und Erfahrungen zu integrieren. Kontinuierliche Verbesserung ist in agilen Ansätzen noch stärker etabliert und in die tägliche Arbeit integriert. Die eher statische Behandlung in klassischen Ansätzen kann bspw. durch Daily Stand-ups und Retrospektiven erweitert werden. In ITIL 4 ist kontinuierliche Verbesserung an zentraler Stelle im Service Value System verankert worden.
3.1.6 DASA DevOps-Prinzip 6: Automate Everything You Can
DevOps-Perspektive
„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, die Prinzipien aus der Softwareentwicklung auf den IT-Betrieb überträgt. Standardisierung und Automation sind ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen, die der Maxime „Everything as code” folgt.
„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, die Prinzipien aus der Softwareentwicklung auf den IT-Betrieb überträgt. Standardisierung und Automation sind ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen, die der Maxime „Everything as code” folgt.
Everything as code
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 Skill Set 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 nicht mit der Auslieferung von Softwarepaketen, sondern kann darüber hinaus weitere Relevanz erhalten. 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 (weiterführende Informationen s. [12]).
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 Skill Set 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 nicht mit der Auslieferung von Softwarepaketen, sondern kann darüber hinaus weitere Relevanz erhalten. 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 (weiterführende Informationen s. [12]).
ITSM-Perspektive
Aus Sicht des IT Service Management ist die Automation positiv zu bewerten. Die Lebenszyklusphase Service Transition wird dabei aktiv unterstützt und einbezogen. Von einer einfacheren und sicheren Aktualisierung des CMS über eine bessere Unterstützung des Release Management bis zu einer stärkeren Fehlervermeidung im Change Management sind nützliche Impulse vorhanden. Überall dort, wo menschliche Arbeiten ersetzt werden, steigt die Verlässlichkeit von Prozessen und deren Ergebnissen.
Aus Sicht des IT Service Management ist die Automation positiv zu bewerten. Die Lebenszyklusphase Service Transition wird dabei aktiv unterstützt und einbezogen. Von einer einfacheren und sicheren Aktualisierung des CMS über eine bessere Unterstützung des Release Management bis zu einer stärkeren Fehlervermeidung im Change Management sind nützliche Impulse vorhanden. Überall dort, wo menschliche Arbeiten ersetzt werden, steigt die Verlässlichkeit von Prozessen und deren Ergebnissen.
3.2 Die Grundprinzipien von ITIL 4
Die ITIL-Grundprinzipien bilden die Basis von ITIL 4. Sie wurden unter dem Titel ITIL Practitioner erstmals 2015 entwickelt und veröffentlicht sowie für ITIL 4 überarbeitet. Die 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 Service eingehalten werden. Sie ermöglichen es in der Anwendung von ITIL, die notwendigen Ansätze zu definieren und schwierige Entscheidungen zu treffen. Damit erfüllen sie die gleiche Zielsetzung wie bspw. die zwölf Prinzipien des Agilen Manifests oder die Scrum-Werte aus dem Scrum-Guide.
Sieben Prinzipien
Die ITIL-Grundprinzipien sind
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 und |
| • | Optimieren und Automatisieren (s. dazu auch Kap. 03010). |
3.3 Vergleich der Prinzipien
Vergleich der ITIL- und DevOps-Prinzipien
Beim Vergleich der Prinzipien von ITIL 4 und DevOps stellt man fest, dass viele Überschneidungen bestehen, die teilweise nur unterschiedlich zugeordnet oder anders formuliert sind. Die Abbildung stellt fünf verschiedene Fälle dar, die im Folgenden erläutert werden.
Beim Vergleich der Prinzipien von ITIL 4 und DevOps stellt man fest, dass viele Überschneidungen bestehen, die teilweise nur unterschiedlich zugeordnet oder anders formuliert sind. Die Abbildung stellt fünf verschiedene Fälle dar, die im Folgenden erläutert werden.
Werteorientierung = Customer-Centric Action
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 jedoch die Orientierung an Wertströmen bzw. der Wertschöpfungskette. Das ist eine Herausforderung vielfältiger Art für viele IT-Organisationen. Sie betrifft neben organisatorischen Veränderungen insbesondere die Themen Führung sowie Arbeits- und Denkweise der Beteiligten.
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 jedoch die Orientierung an Wertströmen bzw. der Wertschöpfungskette. Das ist eine Herausforderung vielfältiger Art für viele IT-Organisationen. Sie betrifft neben organisatorischen Veränderungen insbesondere die Themen Führung sowie Arbeits- und Denkweise der Beteiligten.
Beide Ansätze fokussieren Automation
Die gleiche direkte Beziehung lässt sich zwischen dem ITIL-Prinzip „Optimieren und Automatisieren” sowie dem DASA-DevOps-Prinzip „Automate everything you can” herstellen. Das ITIL-Prinzip formuliert dabei die Notwendigkeit einer Optimierung vor der Automatisierung prägnanter. Beide Prinzipien stellen die weitgehende 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 ITIL 4 über die Wertströme Top-down.
Die gleiche direkte Beziehung lässt sich zwischen dem ITIL-Prinzip „Optimieren und Automatisieren” sowie dem DASA-DevOps-Prinzip „Automate everything you can” herstellen. Das ITIL-Prinzip formuliert dabei die Notwendigkeit einer Optimierung vor der Automatisierung prägnanter. Beide Prinzipien stellen die weitgehende 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 ITIL 4 über die Wertströme Top-down.
ITIL und DevOps fordern Zusammenarbeit
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 Arbeitsweise. Übergreifende Zusammenarbeit aller Beteiligten ist notwendig und zielt auf verschiedene Aspekte wie Organisation, Verantwortung, Transparenz und Selbstverständnis ab.
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 Arbeitsweise. Übergreifende Zusammenarbeit aller Beteiligten ist notwendig und zielt auf verschiedene Aspekte wie Organisation, Verantwortung, Transparenz und Selbstverständnis ab.
Kontinuierliche Verbesserung
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 ITIL 4 eine Komponente des Service Value System 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.
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 ITIL 4 eine Komponente des Service Value System 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.
Crossfunktionale autonome Teams im Fokus von DevOps
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. Im Original liest sich das so: „Recognition of the need for genuine collaboration has been one of the driving factors in the evolution of what is now known as DevOps. Without effective collaborating, neither Agile, Lean nor any other ITSM framework or method will work. Working together in a way that leads to real accomplishment requires information, understanding, and trust. ”
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. Im Original liest sich das so: „Recognition of the need for genuine collaboration has been one of the driving factors in the evolution of what is now known as DevOps. Without effective collaborating, neither Agile, Lean nor any other ITSM framework or method will work. Working together in a way that leads to real accomplishment requires information, understanding, and trust. ”
Grundlegender Unterschied
Es zeigt sich ein grundlegender Unterschied beider Ansätze. DevOps betont auf der Basis agiler Ansätze die Teamorientierung. DevOps-Teams sind einerseits Produktteams, die entsprechende Services an Kunden liefern. Diese wiederum setzen andererseits auf Services von Plattformteams auf. DevOps-Teams bilden also die organisatorische Umsetzung mit entsprechender Verantwortung für die eigenen Produkte bzw. Services ab. ITIL 4 hält sich da etwas zurück. Ein Grund könnte das in früheren ITIL-Versionen beschriebene Konstrukt von „Customer-facing services” und „Supporting services” sein, das die beschriebene Zusammenarbeit nicht auf Teamebene beschreibt, sondern virtuelle Konstrukte anhand der Services baut, die die funktional getrennten Einheiten zusammenführt.
Es zeigt sich ein grundlegender Unterschied beider Ansätze. DevOps betont auf der Basis agiler Ansätze die Teamorientierung. DevOps-Teams sind einerseits Produktteams, die entsprechende Services an Kunden liefern. Diese wiederum setzen andererseits auf Services von Plattformteams auf. DevOps-Teams bilden also die organisatorische Umsetzung mit entsprechender Verantwortung für die eigenen Produkte bzw. Services ab. ITIL 4 hält sich da etwas zurück. Ein Grund könnte das in früheren ITIL-Versionen beschriebene Konstrukt von „Customer-facing services” und „Supporting services” sein, das die beschriebene Zusammenarbeit nicht auf Teamebene beschreibt, sondern virtuelle Konstrukte anhand der Services baut, die die funktional getrennten Einheiten zusammenführt.
Auf der Basis der Prinzipien sind sich ITIL und DevOps sehr nah. Damit wird die Frage beantwortet, ob eine Kombination beider Ansätze möglich ist. Die jeweiligen Prinzipien zeigen eine weitgehend ähnliche Ausrichtung ohne unüberbrückbare Widersprüche.
4 ITIL und DevOps im Zusammenspiel
Mit ITIL 4 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 sich als äußerst hilfreiches Framework bewiesen. Aber es ist auch nach eigener Einschätzung nicht mehr allein ausreichend für die aktuellen Herausforderungen. DevOps wiederum erweitert den modernen Ansatz einer agilen Produktentwicklung auf der Basis von Scrum um den Betrieb und dringt damit inhaltlich in die Domäne von ITIL vor. Im Folgenden sollen daher die beiden Ansätze über die Formulierung von zentralen Forderungen (vgl. Abbildung 3) verbunden werden.
4.1 Zusammenarbeit ist der Schlüssel zum Erfolg
Zusammenarbeit innerhalb der IT
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 Zusammenarbeit.
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 Zusammenarbeit.
Bisherige Erfahrungen
Meine Erfahrungen in deutschen IT-Organisationen zeigen, dass das Silodenken und eine gewisse Überzeugung von der eigenen Expertise und Bedeutung noch zu stark ausgeprägt sind. Anstatt über die anderen zu reden, sollte man mit ihnen reden. Langjährige ITSM-Praktiker sollten ein Verständnis für die Grundlagen und Vorteile von agilen Methoden entwickeln. Die Arbeit an Impediments (Hindernissen) hat enorme Bedeutung und zieht sich durch das Framework Scrum, u. a. in speziellen Meetings und Rollen, die dafür die Verantwortung tragen. Es wird nicht nur Wert auf fachliche Ergebnisse gelegt, sondern auch an der Zusammenarbeit „gearbeitet”. Entwicklungslastige DevOps-Teams sollten die Erfahrung des Service Management aus dem Betrieb von Applikationen nutzen und gemeinsam mit ihm die DevOps-Zukunft gestalten.
Meine Erfahrungen in deutschen IT-Organisationen zeigen, dass das Silodenken und eine gewisse Überzeugung von der eigenen Expertise und Bedeutung noch zu stark ausgeprägt sind. Anstatt über die anderen zu reden, sollte man mit ihnen reden. Langjährige ITSM-Praktiker sollten ein Verständnis für die Grundlagen und Vorteile von agilen Methoden entwickeln. Die Arbeit an Impediments (Hindernissen) hat enorme Bedeutung und zieht sich durch das Framework Scrum, u. a. in speziellen Meetings und Rollen, die dafür die Verantwortung tragen. Es wird nicht nur Wert auf fachliche Ergebnisse gelegt, sondern auch an der Zusammenarbeit „gearbeitet”. Entwicklungslastige DevOps-Teams sollten die Erfahrung des Service Management aus dem Betrieb von Applikationen nutzen und gemeinsam mit ihm die DevOps-Zukunft gestalten.
Erste Ansätze
Der Aufbau dieses Verständnisses ist Aufgabe des Top-Managements. Es muss die Rahmenbedingungen dafür setzen (s. a. [13]). Die Zusammenarbeit kann zunächst auf einfachem Niveau starten, indem 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.
Der Aufbau dieses Verständnisses ist Aufgabe des Top-Managements. Es muss die Rahmenbedingungen dafür setzen (s. a. [13]). Die Zusammenarbeit kann zunächst auf einfachem Niveau starten, indem 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.
4.2 Das Business muss eingebunden werden
Kunde aktiv einbeziehen
Wenn die IT-Organisation die Zusammenarbeit für sich geklärt hat, muss der Kunde aktiv in die 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 organisiert, kann DevOps mit der täglichen Einbeziehung des Business (festgelegte Ereignisse) punkten. Dabei 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. Und kein Vertrag kann alle Einzelheiten der Zusammenarbeit abdecken.
Wenn die IT-Organisation die Zusammenarbeit für sich geklärt hat, muss der Kunde aktiv in die 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 organisiert, kann DevOps mit der täglichen Einbeziehung des Business (festgelegte Ereignisse) punkten. Dabei 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. Und kein Vertrag kann alle Einzelheiten der Zusammenarbeit abdecken.
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 die Planung einbezieht, denn er allein kann die Wertschöpfung qualifizieren und quantifizieren.
Tipp
Wenn es darum geht, Kunden aktiv in die Veränderung einzubeziehen, wird das unter dem Stichwort BizDevOps schon propagiert und umgesetzt. Der Autor hat gute Erfahrungen mit Workshops, in denen die Parteien u. a. ihre jeweiligen Anforderungen an die anderen formulieren.
Wenn es darum geht, Kunden aktiv in die Veränderung einzubeziehen, wird das unter dem Stichwort BizDevOps schon propagiert und umgesetzt. Der Autor hat gute Erfahrungen mit Workshops, in denen die Parteien u. a. ihre jeweiligen Anforderungen an die anderen formulieren.
4.3 Orientierung an Wertschöpfungsketten
Technologisch getrieben
Meines Erachtens sind viele IT-Bereiche immer noch technologisch unterwegs und weniger bei der konkreten Betrachtung der Wertschöpfung für den Kunden.
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.
Nutzen im Vordergrund
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 Teams können dann die Practices in Kenntnis der konkreten Kundenbedürfnisse nutzen und in die eigene Arbeit integrieren.
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 Teams können dann die Practices in Kenntnis der konkreten Kundenbedürfnisse nutzen und in die eigene Arbeit integrieren.
Tipp
Mit der Methode „Value Stream Mapping” des Lean Managements kann eine aussagekräftige Analyse von Wertströmen in der Praxis durchgeführt werden.
Mit der Methode „Value Stream Mapping” des Lean Managements kann eine aussagekräftige Analyse von Wertströmen in der Praxis durchgeführt werden.
4.4 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. Die Erfahrung im Service Management ist für die umfassende Lieferung von Services weiterhin notwendig, bspw. um die Einhaltung der Verträge sicherzustellen.
ITIL 4 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.
4.5 Teams bilden die operative Grundlage
Erfolgsfaktor Teambildung
Die DevOps-Philosophie gibt Antworten im operativen Bereich, insbesondere mit Blick auf die Menschen und Teams, was bei ITIL nicht angemessen berücksichtigt wurde. Ziel bei der Bildung von Teams ist die Dezentralisierung der Verantwortung und Entscheidungsbefugnis/-befähigung. Insbesondere die Crossfunktionalität und die 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.
Die DevOps-Philosophie gibt Antworten im operativen Bereich, insbesondere mit Blick auf die Menschen und Teams, was bei ITIL nicht angemessen berücksichtigt wurde. Ziel bei der Bildung von Teams ist die Dezentralisierung der Verantwortung und Entscheidungsbefugnis/-befähigung. Insbesondere die Crossfunktionalität und die 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. Die Teams müssen auf der anderen Seite in die gesamte Organisation und die Sicherstellung der Erfüllung der Kundenanforderungen einbettet sein, damit diese Verantwortung im Sinne des Kunden und der IT-Organisation wahrgenommen wird.
Erfahrung mit ITIL
Die Teambildung wurde bei der Anwendung von ITIL nicht angemessen berücksichtigt. Diese Einschätzung beruht auf den praktischen Umsetzungen von ITIL im Sinne von „Command and Control” sowie kleinschrittigem und überwachtem Prozessmodus. Dieses Missverständnis in der Umsetzung von ITSM war zwar nie die Idee von ITIL, findet sich jedoch häufig in der Praxis.
Die Teambildung wurde bei der Anwendung von ITIL nicht angemessen berücksichtigt. Diese Einschätzung beruht auf den praktischen Umsetzungen von ITIL im Sinne von „Command and Control” sowie kleinschrittigem und überwachtem Prozessmodus. Dieses Missverständnis in der Umsetzung von ITSM war zwar nie die Idee von ITIL, findet sich jedoch häufig in der Praxis.
4.6 Automation ist eine Herausforderung
Beide mit Fokus auf Automation
Selbstverständlich hat auch die IT immer wieder über Automatisierung nachgedacht und Projekte durchgeführt. Häufig waren diese jedoch technikgetrieben und isoliert, weil Standarisierung im Sinne von einheitlichem Vorgehen und notwendiger Optimierung nicht ausreichend durchgeführt wurde. Einzelne Tools kamen bedarfsgetrieben zum Einsatz.
Selbstverständlich hat auch die IT immer wieder über Automatisierung nachgedacht und Projekte durchgeführt. Häufig waren diese jedoch technikgetrieben und isoliert, weil Standarisierung 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-Organisation beachten die genannten Probleme weiterhin nur sehr selten. Die Entwicklungsteams automatisieren ihre Arbeit, um Betriebstätigkeiten abzubilden, statt den gesamten Wertstrom zu betrachten, während der Betriebsbereich die Integration der gelieferten Ergebnisse aus der Entwicklung automatisiert.
Ansätze ergänzen sich
Die betrachteten 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, die ein digitales Geschäftsmodell haben. Spotify, Amazon, Netflix sind dafür prominente Beispiele.
Die betrachteten 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, die ein digitales Geschäftsmodell haben. Spotify, Amazon, Netflix sind dafür prominente Beispiele.
4.7 Pragmatismus ist angesagt
End-To-End Responsibility aus Sicht von ITSM
Fokussierung und Reduzierung der Herausforderungen auf einzelne oder gar ein Framework(s) ist nicht zielführend. Aufgabe ist es nicht mehr, Frameworks in Projekten für ein Unternehmen einzuführen, sondern eine Auswahl von „best-of” zu treffen, passgenau für das Unternehmen („Cherry picking”). 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 kann beispielsweise helfen, die Problemlösung in den Teams zu professionalisieren, ebenso wie Tools (Ishikawa usw.) aus dem Lean Management angewendet werden können. Aufwendige Programme zur Unternehmensentwicklung sollten durch einen iterativen Lern- und Entwicklungsprozess ersetzt werden.
Fokussierung und Reduzierung der Herausforderungen auf einzelne oder gar ein Framework(s) ist nicht zielführend. Aufgabe ist es nicht mehr, Frameworks in Projekten für ein Unternehmen einzuführen, sondern eine Auswahl von „best-of” zu treffen, passgenau für das Unternehmen („Cherry picking”). 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 kann beispielsweise helfen, die Problemlösung in den Teams zu professionalisieren, ebenso wie Tools (Ishikawa usw.) aus dem Lean Management angewendet werden können. Aufwendige Programme zur Unternehmensentwicklung sollten durch einen iterativen Lern- und Entwicklungsprozess ersetzt werden.
Die hybride Nutzung von Ansätzen ist notwendig, d. h., eine agile Entwicklung und der stabile Betrieb sind möglich (Beispiele und Fakten s. [16]). Beide Sichten können nicht ohne die jeweils 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.
Es wurde anhand der formulierten Forderungen gezeigt, wie die beiden Ansätze ITIL und DevOps konkret helfen können, IT-Organisationen zur Bewältigung der aktuellen Herausforderungen zu gestalten.
5 Ausblick
JA!
Es wurde gezeigt, dass die im Titel formulierte Frage bejaht werden kann, d. h. ITIL, und DevOps sind zwei starke Partner für erfolgreiche IT-Organisationen. Beide Ansätze lassen sich auf der Basis der jeweiligen Prinzipien kombinieren, da sie vielfältige Überscheidungen aufweisen. An den Stellen, an denen einer der beiden Ansätze Lücken aufweist, kann der andere unterstützend eingesetzt oder durch weitere Werkzeuge ergänzt werden.
Es wurde gezeigt, dass die im Titel formulierte Frage bejaht werden kann, d. h. ITIL, und DevOps sind zwei starke Partner für erfolgreiche IT-Organisationen. Beide Ansätze lassen sich auf der Basis der jeweiligen Prinzipien kombinieren, da sie vielfältige Überscheidungen aufweisen. An den Stellen, an denen einer der beiden Ansätze Lücken aufweist, kann der andere unterstützend eingesetzt oder durch weitere Werkzeuge ergänzt werden.
ITIL ist ein erprobtes Framework und mit den mittlerweile 34 Praktiken ziemlich vollständig mit Hilfestellungen zum Aufbau einer Serviceorganisation. DevOps ist eine Methode, deren Fokus in der verbesserten Zusammenarbeit in den Teams und übergreifend der Teams seine Stärken hat. Beides zusammen ist letztlich notwendig für den Erfolg. Erfolgreiche Organisationen zeigen sich in der für die eigene Herausforderung und den eigenen Reifegrad adäquaten Nutzung der vorhandenen Ansätze.
Die formulierten Anforderungen sollten in unterschiedlicher Weise aufgegriffen und verzahnt vorangetrieben werden. Der dargestellte Aufbau (s. Abbildung 3) stellt dabei eine erste Idee dar, wie in einer Organisation vorgegangen werden könnte. Es ist keinesfalls als zwingende Reihenfolge zu interpretieren.
Herausforderung für die Praxis
Die Herausforderung für die Praxis besteht darin, diese Sichtweise in den Alltag zu überführen. Allen Beteiligten (Stakeholder, Kunde, Management, Entwicklung, Betrieb usw.) ist diese Kombinationsmöglichkeit näherzubringen 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. Statt alle Beteiligten „mitzunehmen” oder „abzuholen”, sollten sie von Beginn an „einbezogen” werden. Das kostet Zeit sowie Geld und benötigt auf allen Seiten Geduld und Verständnis. Lohn dieser Investition ist eine effektive Arbeitsorganisation, die stabil die Kundenanforderungen erfüllt und sich agil auch an zukünftige Veränderungen anpasst.
Die Herausforderung für die Praxis besteht darin, diese Sichtweise in den Alltag zu überführen. Allen Beteiligten (Stakeholder, Kunde, Management, Entwicklung, Betrieb usw.) ist diese Kombinationsmöglichkeit näherzubringen 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. Statt alle Beteiligten „mitzunehmen” oder „abzuholen”, sollten sie von Beginn an „einbezogen” werden. Das kostet Zeit sowie Geld und benötigt auf allen Seiten Geduld und Verständnis. Lohn dieser Investition ist eine effektive Arbeitsorganisation, die stabil die Kundenanforderungen erfüllt und sich agil auch an zukünftige Veränderungen anpasst.
Quellen
2
Kim, Gene; Behr, Kevin; Spafford, George: Projekt Phoenix. Der Roman über IT und DevOps – Neue Erfolgsstrategien für Ihre Firma. O'Reilly, 2015Absolut empfehlenswert! Jeder Leser wird den Protagonisten Brent in seiner Organisation und Umgebung wiederentdecken.
11
16
Puppet: State of DevOps Report, jährliche Erscheinungsweisepuppet.com/resources/whitepaper/state-of-devops-report
