Das DASA DevOps-Prinzip 3: End-to-End-Responsibility
Während des IT-Produkt-Lebenszyklus wird ein IT-Produkt (auch Software und IT-Services) bisher von unterschiedlichen Teams betreut. Das IT-Produktkonzept wird von einem Beratungshaus mit gut gemachten Präsentationen erstellt. Dieses wird von einem lokalen IT-Dienstleister umgesetzt, getestet und produktiv gesetzt. Anschließend erfolgt die Übergabe an den Support, welcher von Indien aus kostengünstig betrieben wird. Produktanpassungen und Innovationen werden wiederum durch andere Projektteams eingeführt. Innerhalb dieses Lebenszyklus' kommt es zu Wissensverlusten. Jedes einzelne Team besitzt andere Ziele und interessiert sich kaum für das IT-Produkt an sich bzw. dafür, was nach seiner Arbeit damit passiert. Ein instabiles, fehleranfälliges IT-Produkt kann die Folge sein. Die DASA versucht mit dem dritten Prinzip den Fokus wieder auf das IT-Produkt und den Kunden zu setzen. Der Artikel gibt hierzu praktische Tipps zur Umsetzung dieses Prinzips, um stabilere und qualitativ hochwertigere IT-Produkte als bisher zu entwickeln.
Das DASA DevOps-Prinzip 3: End-to-End-Responsibility
Where traditional organizations develop IT solutions and then hand them over to Operations to deploy and maintain these solutions, in a DevOps environment teams are vertically organized such that they are fully accountable from concept to grave. IT products or services created and delivered by these teams remain under the responsibility of these stable groups. These teams also provide performance support, until they become end-of-life, which greatly enhances the level of responsibility felt and the quality of the products engineered. [1]
Verantwortung im Team
Das dritte Prinzip der DASA bezieht sich auf die End-to-End-Verantwortung eines Teams. Dies bedeutet, dass ein Team vollumfänglich für ein IT-Produkt verantwortlich ist und die Organisation vertikal organisiert ist. Es gibt keine getrennten Projekt- und Supportteams – Übergaben und damit einhergehende Wissensverluste werden vermieden. Dieser Grundsatz geht Hand in Hand mit dem vierten Prinzip, den cross-funktionalen Teams [2]. Statt der bisherigen Aufteilung in einzelne Siloteams soll das verantwortliche Produktteam alle Fähigkeiten mitbringen, um den kompletten Lebenszyklus eines IT-Produktes zu betreuen – von der Konzeption bis zur Einstellung des IT-Produktes. Das dritte Prinzip unterstützt hierbei die vorher beschriebenen Prinzipien durch einen Produktgedanken und eine verbesserte Kundenorientierung. Das Team ist ganzheitlich für das IT-Produkt verantwortlich.
Der IT-Produkt-Lebenszyklus beschreibt den Prozess der IT-Produkterstellung bis hin zur Produktivsetzung und zum anschließendem Support inklusive Weiterentwicklung des IT-Produkts. Am Anfang steht die Entwicklung eines Minimal Viable Products (MVP), welches eine frühe Produktivsetzung ermöglicht. Dieses MVP bildet die erste, für Kunden nutzbare, Version des IT-Produktes mit Grundfunktionalitäten ab. Der Kunde kann am Anfang z. B. nur Waren suchen und bestellen. Anschließend geht es in der Einführung darum, das IT-Produkt durch Weiterentwicklungen um weitere Funktionen zu ergänzen und zu vollenden, wie z. B. das Bewerten von Waren. Kommt eine Funktionalität beim Kunden nicht an, so kann diese angepasst oder gelöscht werden. Durch diese häufigeren Weiterentwicklungen des IT-Produkts ist es sinnvoll, ein Team einzusetzen, um Verluste im Wissenstransfer zu verhindern und immer das "finale IT-Produkt" als Ziel zu sehen (s. DevOps-Prinzip 2 [3]). In der Wachstums- und Reifephase kann hierbei vom Wissen des Teams profitiert werden. Mögliche Innovationen, welche die Reifephase verlängern und somit den Umsatz hochhalten, sind durch ein IT-Produktteam möglich. Erst mit dem Einstellen des Supports endet der Lebenszyklus des IT-Produktes und somit die Verantwortung des Produktteams.
Je nach IT-Produkttypus müssen beim Lebenszyklus firmenspezifische Anpassungen gemacht werden. Handelt es sich um Software, welche sich in ein bestehendes Software- und Architekturkonzept eingliedern muss, oder um eine vollständige Neuentwicklung? Handelt es sich um Standardsoftware oder um Individualsoftware? Beispielsweise wird im ERP-Bereich die Verantwortung über den gesamten Lebenszyklus andere Formen annehmen, als der Aufbau einer neuen, unternehmenseigenen App. Jedes Unternehmen muss sich daher die Frage stellen, wie die Lebenszyklusverantwortung für seine Bereiche umgesetzt werden kann.
Vorteile des Prinzips
Die Vorteile eines Produktteams sind vielfältig. Da das Team für das gesamte Produkt verantwortlich ist und autonom arbeitet, können erreichbare Zielvorgaben erstellt werden. Das Team ist motiviert, gute Arbeit zu liefern, da es selbst entscheidet. Es hat selbst das Konzept erstellt, welches es anschließend umsetzt. Daher profitiert es davon, wenn ein fehlerfreies Produkt ausgeliefert wird, da dadurch Zeit durch notwendige Nacharbeiten reduziert wird und auch Support in Wochenend- und Nachtschichten vermieden werden.
Durch den Bezug auf ein IT-Produkt existiert eine engere Beziehung zum Kunden. Der Kunde hat sowohl in der Konzeptphase als auch später im Support das gleiche Team als Ansprechpartner, evtl. sogar einen konkret benannten Ansprechpartner. Dadurch ist es möglich, schnelleres Feedback einzuholen und einen verbesserten Service anzubieten. Ein "Ticket-Pingpong" mit verschiedenen Teams wird vermieden.
Durch die Betreuung über den gesamten Lebenszyklus wird ein Wissensverlust vermieden, da keine Übergaben an andere Teams notwendig sind. Das Team besitzt die Kenntnisse über den Programmcode und kennt die langfristige Zielsetzung. Durch die enge Zusammenarbeit mit dem Kunden werden Probleme schnell ersichtlich und können frühzeitig und somit effektiver behoben werden. Da Entwicklung und Support nicht isoliert voneinander arbeiten, werden Fehler nicht bei anderen gesucht, sondern es wird an der Lösung gearbeitet.
Ein kontinuierliches Lernen wird durch ein produktorientiertes Team wesentlich verbessert. Es kennt die Abläufe und ist motiviert, Prozesse und Abläufe zu automatisieren, um die eigene Arbeit zu verbessern. Die Analyse, wo das IT-Produkt im Moment steht und wo Änderungen und Verbesserungen notwendig sind, ist durch solch ein Team wesentlich einfacher. Diese Verbesserungen an ihrem IT-Produkt können schneller eingeführt werden, da keine Absprachen mit anderen Bereichen notwendig sind.
Schwierigkeiten bestehen hingegen darin, ein Team so aufzubauen, dass es während des kompletten Lebenszyklus eines IT-Produkts für dieses verantwortlich ist. Vor allem die Organisation und die Kultur innerhalb des Unternehmens und des Teams müssen darauf ausgerichtet sein. Wie diese Gestaltung aussehen kann, wird nun erläutert.
Organisation
Die Einführung von DevOps sollte ebenfalls eine Änderung der bisherigen Projekt- oder Aufbauorganisation beinhalten. Hierbei geben die in dieser Artikelserie geschilderten Kernkonzepte einen Überblick, wie eine Organisation und deren Teams aufgebaut sein sollten.
Conways Law besagt, dass der Aufbau einer Software den Aufbau der Organisation, die sie entwickelt, widerspiegelt [4]. Dementsprechend muss die Organisation für die Umsetzung des DevOps ebenfalls angepasst werden. In der von der DASA vorgeschlagenen DevOps-Organisation stellen Betrieb und Entwicklung keine eigenen Teams mehr dar. Die Teams werden stattdessen nach fachlichem Service gruppiert, sodass sie einen Service bzw. ein Produkt über den kompletten Lifecycle betreuen können. Es gibt nur noch einen kleinen teamübergreifenden Betriebsbereich, der für die Hardware-Bereitstellung und Wartung zuständig ist.
Abb. 2 zeigt, wie eine DevOps-Organisation aufgebaut werden kann. Die Teams innerhalb der Organisation werden so gebildet, dass es fachliche und produktorientierte anstatt funktionsorientierte Teams gibt. Diese Business-System-Teams besitzen sowohl die Verantwortung als auch die Rechenschaftspflicht für ein IT-Produkt über den gesamten Lebenszyklus. Durch diesen Aufbau wird die Eigenverantwortlichkeit des Teams ermöglicht. Es muss weniger zwischen verschiedenen Teams koordiniert werden, da Schnittstellen reduziert werden. Je nach Teamgröße ist es sinnvoll, einen Product bzw. Service Owner zu bestimmen, welcher die Abstimmung mit dem IT-Management übernimmt, das Ziel des Produkts im Auge behält und die Anforderungen an das Produkt mit dem Team gemeinsam priorisiert.
Die Abbildung kann auch dahingehend verstanden werden, dass die dargestellte Struktur noch detaillierter ist, sodass es im Entwicklungsbereich funktionsorientierte Teams gibt, welche auf Entwicklung, auf Testen, etc. spezialisiert sind. Diese Arbeitsschritte werden in den Serviceteams gebündelt. Die Mitarbeiter müssen jedoch befähigt sein, alle notwendigen Aufgaben innerhalb des Teams zu lösen. Hierzu gehören unter anderem die Konzeptionierung und das Design, das Entwickeln, das Testen sowie die Fehleranalyse und der Support. Sowohl die Weiterbildung als auch die Arbeitsweise müssen dahingehend ausgerichtet werden. Oft wird hierbei auch von einem T-Shaped- oder E-Shaped-Profil gesprochen [5]. Näheres dazu auch im Artikel zu DevOps-Prinzip 4 [2].
Die technische Infrastruktur wird durch ein oder mehrere Plattform-Teams erbracht. Diese stellen sowohl die Plattform (Platform as a Service) als auch die Infrastruktur (Infrastructure as a Service), auf der die IT-Produkte der Business-System-Teams ausgeführt werden. Sie können als eine Art "Cloud"-Service Provider betrachtet werden. Damit die richtige Plattform für die IT-Produkte bereitgestellt wird, müssen Plattform-Teams und Business-Service-Teams eng zusammenarbeiten. Der Zugriff auf Leistungen der Plattform-Teams sollte jedoch durch automatisierte Self-Services erfolgen, um keine Wartezeiten zu erzeugen. Ein erhöhter Speicherplatz für einen Server sollte durch einen Mausklick möglich sein. Weitere Beispiele für Leistungen der Plattform-Teams sind Backups und Monitoring-Möglichkeiten.
Vor allem jüngere Unternehmen wie Amazon, Google und Netflix sind dafür bekannt, DevOps zu nutzen. Dass dies auch älteren Unternehmen gelingt, zeigen die Bank of America oder The Gap [6]. Wenn eine Änderung der Organisation in einem Unternehmen nicht möglich ist, so sollte eine Zusammenarbeit der Entwicklung und des Betriebs durch räumliche Nähe und verbesserten Wissenstransfer forciert werden. Dies kann z. B. durch wechselseitige Teilnahme an Teammeetings und gemeinsame Learning-Sessions geschehen.
Kultur
Das Team muss vom Unternehmen befähigt werden, dass es die Verantwortung für einen Service über den gesamten Lebenszyklus übernehmen kann. Regeln, Vorgaben und Ziele sollten daher nicht vom Management kommen, sondern innerhalb des Teams erstellt und kontrolliert werden. Das IT-Management sollte dementsprechend darauf bedacht sein, vor allem die Selbständigkeit der Teams zu fördern und nur übergeordnete Ziele vorzugeben. Dies kann z. B. durch Coaching der Teams erfolgen, sodass diese bzgl. möglicher Methoden der Kontrolle und Verbesserung trainiert werden. Dies beinhaltet vor allem die in der DASA beschriebenen Kompetenzbereiche: Mut, Teambildung, Führungsqualitäten und kontinuierliche Verbesserung. Auch die Kontrolle des Produktes, wo es innerhalb einer Portfolioanalyse steht, und die damit einhergehende Abstimmung mit dem Produktteam, sollte dem IT-Management obliegen.
Den Mitarbeitern muss für diese Arbeitsweise beigebracht werden, innerhalb ihres Unternehmens wie in einem eigenständigen Unternehmen zu denken. Das Team sollte selbständig seine präferierte Arbeitsweise festlegen. Aufgrund der reduzierten Komplexität innerhalb der Organisation sind Prozessdefinitionen weniger wichtig. Diese sind vor allem aufgrund von Übergaben an andere Teams und externer Kontrolle notwendig gewesen. Die Dokumentation erfolgt nur in minimalem Umfang, da sie ebenfalls nicht für Übergaben und Kontrollen benötigt werden. Das Team kontrolliert sich und seine Zahlen selbst. Welche Tools es für Automatisierungen und Monitorings nutzt, bestimmt es ebenfalls selbst.
Auch auf bestehende IT-Servicemanagement-Prozesse kann aufgebaut werden. ITIL und DevOps passen gut zusammen und schließen sich nicht gegenseitig aus. In ITIL selbst lassen sich viele Lösungsmöglichkeiten für DevOps finden. Es kann daher den Umfang bilden, in dem Veränderungen durchgeführt werden können [7]. Ein Vorteil dabei ist, dass Grundlagen schon vorhanden sind und IT-Mitarbeiter mit ITIL schon vertraut sind. Das Monitoring der Service Level Agreements kann z. B. als Kontrollmethode für das Team eingesetzt werden. Da die Mitarbeiter selbst mit den ITIL-Prozessen arbeiten, erkennen sie am schnellsten, wo mögliche Optimierungsmöglichkeiten bestehen – wie beispielsweise die Automatisierung bestimmter Prozesse. Hierbei können Visualisierungstechniken, wie z. B. die Nutzung von Kanban-Karten, helfen, Prozesse abzubilden und Engpässe zu erkennen.
Herausforderungen
Die Herausforderung besteht darin, die Denkweise der Mitarbeiter und die Struktur des Unternehmens auf die Lebenszyklus-Verantwortung anzupassen. Eine Veränderung von heute auf morgen ist nicht zu realisieren. Ein Change-Management, welches sowohl das IT-Management als auch die Mitarbeiter einbindet, ist unabdingbar. Diese besitzen bisher wenig Erfahrung mit der DevOps-Sichtweise und haben zum Teil schlechte Erfahrungen mit Veränderungen gemacht. Innerhalb einer DevOps-Einführung müssen daher Fragen beantwortet und Vorbehalte reduziert werden.
Während der Umsetzung der Lebenszyklus-Verantwortung gibt es je nach technischem Umfeld unterschiedliche Grenzen. Bei der Nutzung von IT-Produkten von Fremdanbietern kann das Produktteam seine technische Plattform nach der Anschaffung ggf. nicht selbst bestimmen. IT-Architektur und Programmiersprachen sind vorgegeben.
In der Praxis zeigt sich, dass bestimmte Aspekte der End-to-End-Verantwortung schon gelebt werden, obwohl es nicht explizit DevOps genannt wird. Es ist daher eine Analyse notwendig, inwieweit auf schon genutzte Organisationsformen und Prozessmethoden aufgebaut werden kann, um die Lebenszyklus-Orientierung weiter umzusetzen und Optimierungspotentiale zu finden. Durch den Ansatz, auf Bestehenden aufzubauen und den Mitarbeitern mehr Verantwortung zu übertragen, wird die Akzeptanz der einzelnen Mitarbeiter verbessert.
Bei neuen Projekten oder der Einführung eines neuen IT-Produkts ist die Nutzung der Lebenszyklus-Verantwortung einfacher. Dies kann z. B. im Rahmen einer Harmonisierung der ERP-Systemlandschaft erfolgen. Das ERP-Modulteam sollte nicht nur das Projekt mitgestalten, sondern sowohl das Konzept als auch den Support übernehmen. Während arbeitsintensiverer Phasen kann es auch von externen Ressourcen erweitert werden, jedoch sollte das Kernteam während des gesamten Lebenszyklus verfügbar sein.
Fazit
Die von der DASA beschriebene End-to-End-Verantwortung ermöglicht es der IT, den Fokus wieder auf das IT-Produkt und den Kunden zu 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. Das DASA-Ausbildungskonzept gibt hierbei Hilfestellungen, wie diese Analyse und Umsetzung erfolgen kann. Je nach genutztem IT-Produkt können hierbei unterschiedliche Zielsetzungen angegangen werden.
- Die DASA DevOps-Prinzipien
- Informatik Aktuell – Philipp Schäfer & Dierk Söllner: Das DASA DevOps-Prinzip 4: Cross-Functional Autonomous Teams
- Informatik Aktuell – Daniel Nee & Dierk Söllner: Das DASA DevOps-Prinzip 2: Create with the End in Mind
- Wikipedia: Gesetz von Conway
- DaVanzo, Sarah; 2012: Business Trend: "E-Shaped" People, Not "T-Shaped"
- Kim et. al.; 2015: Projekt Phoenix, Der Roman über IT und DevOps, O'Reilly, Heidelberg, S. 317 f. und S. 328
- Informatik Aktuell – Martin Beims: ITIL und DevOps machen IT fit für die Digitalisierung
Publikationen
- IT-Service Management mit FitSM
- Perspektivwechsel im IT Service Management: Erfolgsgeschichten oder - Dierk Söllner, Peter Bergmann, itSMF
