DASA DevOps-Prinzipien
Prinzip 1: Customer-Centric Action
Kundenzentrierte Aktionen im DevOps bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Aus der agilen Softwareentwicklung ist dieser Ansatz 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 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.
ITSM Sicht:
Kundenzentrierte Aktionen im DevOps bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Alle Aktivitäten der Serviceerbringung müssen sich an den Kunden orientieren. 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.
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 weitergehender. 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-Servicemanagement-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.
Klassisches Vorgehen (Wasserfallmodell):
Agiles Vorgehen:
Fazit:
Ziel einer jeden Organisation sollte es sein, das Thema "Servicewüste Deutschland" aus den Köpfen der Menschen zu verbannen und jedem Kunden das individuelle Gefühl eines "Königs" oder einer "Königin" zu geben. Dazu gehört nicht nur eine Anpassung in der eigentlichen Umsetzung, sondern auch ein Umdenken in den Köpfen der Mitarbeiter und die Offenheit für neues Vorgehen. Die Kundenorientierung muss darüber hinaus auch mögliche organisatorische Veränderungen nach sich ziehen.
Prinzip 2: Create with the End in Mind
Mit dem Prinzip "Schon zu Beginn an das Ergebnis denken" versucht DevOps, die "klassische" 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.
ITSM Sicht:
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.
Vergleich zwischen aktivitätsorientierter und produktorientierter Struktur:
Fazit:
Es ist der Ansatz, der vermitteln möchte, dass die Unternehmen von der Silokultur in die produktorganisierte Kultur wechseln müssen, um die Organisation nach DevOps auszurichten. Sie müssen als Produktunternehmen agieren, das sich explizit darauf konzentriert, funktionierende Produkte zu bauen, die an Kunden verkauft werden, und alle Mitarbeiter müssen die technische Denkweise teilen, die erforderlich ist, um diese Produkte zu konzipieren und zu realisieren.
Es gibt ein Team für ein Produkt und dieses übernimmt die Verantwortung für alle Prozesse, Funktionen und Anforderungen 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.
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 ist sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team
Die IT erlangt 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. 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.
ITSM Sicht:
Aus Sicht von IT-Servicemanagement ergänzt dieses Prinzip die beiden vorherigen. Die herkömmlich in Prozessen und Abteilungen aufgeteilten Aktivitäten und aufgesplittete Verantwortung werden in ein 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.
- https://www.informatik-aktuell.de/entwicklung/methoden/das-dasa-devops-prinzip-3-end-to-end-responsibility.html
- https://de.wikipedia.org/wiki/RACI
Möglicher Aufbau einer DevOps-Organisation:
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.
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 sehr gutes T-Shape-Profil im Team und bei den Teammitgliedern notwendig anstelle des klassischen IT-Spezialisten.
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.
ITSM Sicht:
Dieses Prinzip kämpft in der praktischen Umsetzung mit ähnlichen Schwierigkeiten wie sie das IT-Servicemanagement 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.
Gegenseitige Abhängigkeiten zum Teamaufbau in der DevOps-Kultur:
Fazit:
Cross-funktionale, autonome Teams sind in der Lage, Innovation ganzheitlich zu denken und gleichzeitig das komplette Aufgabenspektrum über den gesamten Produktlebenszyklus eigenverantwortlich und in effizienter Zusammenarbeit zu erledigen. Voraussetzungen sind sowohl der Kulturwandel in IT-Organisationen, eine schlanke Teamorganisation und -steuerung sowie das agile Mindset und die vielseitigen Fähigkeiten der Mitarbeiter. So wird das Team gemeinsam zum Unternehmenserfolg beitragen.
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 akzeptiert und unterstützt wird, in der Transparenz durch Kennzahlen vorherrscht und in dem ein großes Augenmerk auf die Unternehmensumwelt gelegt wird. Ziel ist es, frühzeitig Veränderungsbedarfe zu erkennen und diese durch kontinuierliche Anpassung und Verbesserungen zu jeder Zeit annehmen 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.
ITSM Sicht:
ITIL hat eine eigene Lebenszyklusphase und damit auch eine eigene Publikation, die sich mit der kontinuierlichen Verbesserung beschäftigt. Hier 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.
Fazit:
Verbesserung ist ein Ziel, welches stets adressiert werden sollte. Dafür können Rahmenbedingungen durch Organisationen geschaffen werden. Eine Kultur, in der ein mögliches Scheitern akzeptiert und unterstützt wird, in der Transparenz durch Kennzahlen vorherrscht und in der ein großes Augenmerk auf die Unternehmensumwelt gelegt wird, um frühzeitig Veränderung zu erkennen und diese durch kontinuierliche Anpassung und Verbesserungen zu jeder Zeit annehmen zu können – das ist die Grundausrichtung, die ein Unternehmen für seinen individuellen Erfolg in dieser schnelllebigen Welt benötigt.
Ein ideales Vorgehen gibt es dabei nicht – jedes Unternehmen muss selbst einen Weg finden, dies umzusetzen – als eigene Herausforderung und riesige Chance für den individuellen Erfolg.
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. Standardisierung und Automation ist ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen.
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 der DevOps-Ingenieure, 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. 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.
ITSM Sicht:
Aus Sicht des IT-Servicemanagement 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.
Automatisierung:
IaaS, Paas und Saas:
Fazit:
Der philosophische Ansatz – alles, was möglich ist, zu automatisieren – kann hohe Anforderungen an das Unternehmen stellen. Die DASA bezieht sich zunächst auf die Development-Pipeline, da diese einen zentralen Prozess in der Softwareentwicklung darstellt. Weiterhin führt die Integration von Continuous Delivery zu einer Anpassung der angrenzenden Prozesse und Systeme. Die Integration von On-Premise- sowie Cloud-Komponenten erfordert ein hohes Skillset der DevOps-Ingenieure, sodass zwar durch die Automatisierung Tätigkeiten auf die Systeme verlagert werden, aber neue 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. Verändert sich die Unternehmenskultur von der klassischen phasenorientierten und manuellen Ausrichtung hin zu hochautomatisierten Unternehmensprozessen mit besonderem Fokus auf Automatisierung, können die freien Ressourcen zur Verbesserung der Marktposition und Unternehmenswahrnehmung genutzt werden. Automatisiere alles, was du kannst – ein Ansatz von insgesamt sechs für den Beginn einer neuen Generation von IT-Abteilungen und ganzer Unternehmen.
Handlungsfelder bei der Etablierung von DevOps
DevOps allein mit einer Automatisierung bzw. dem Aufbau einer Continuous Delivery-Pipeline gleichzusetzen reicht nicht aus. Automation ist zwar ein wichtiger Bestandteil, der jedoch um weitere Aspekte ergänzt werden muss. Durch die aufgeführten und in der Praxis im Einsatz befindlichen Frameworks ergeben sich verschiedene Handlungsfelder. Diese müssen vollständig betrachtet und bei einer Umsetzung in der Praxis bearbeitet werden. Neben der Automatisierung muss eine Kultur für DevOps geschaffen werden, die unter anderem die beiden unterschiedlichen Sichtweisen von Betrieb und Entwicklung aus traditioneller Sicht zusammenführt. Dazu sind Prozesse abzustimmen und eine passende Organisation aufzubauen. Weiterhin muss eine kontinuierliche Verbesserung als passende Mischung etabliert werden.