Das DASA DevOps-Prinzip 2: Create with the End in Mind
"Wer kein Ziel im Leben hat, verläuft sich", sind die passendsten Worte zum zweiten DASA DevOps-Prinzip "Create with the End in Mind". Das Zitat stammt vom einem Mann, der sich vom Farmerjunger zum Kaufmannsgehilfen arbeitete, anschließend Anwalt wurde und sich vom Parlamentarier zum Präsidenten wählen ließ.
Was hat Präsident Abraham Lincoln mit DevOps zu tun? Aus Sicht der IT mit Sicherheit zunächst nichts. Aber der Hintergrund der Zielsetzung von Präsidenten Lincoln war genau der, den das zweite Prinzip verfolgt – schon zu Beginn an das Ergebnis denken. Lincoln war sich bewusst, dass es schwer wird, der Präsident der Vereinigten Staaten von Amerika zu werden, er hat aber sein Ziel stets fokussiert.
Das DASA DevOps-Prinzip 2: Create with the End in Mind
Organizations need to let go of waterfall and process-oriented models where each unit or individual works only for a particular role/function, without overseeing the complete picture. They need to act as product companies that explicitly focus on building working products sold to real customers, and all employees need to share the engineering mindset that is required actually to envision and realize those products. [1]
IT-Organisation nach DevOps
So ist es auch bei einer an DevOps ausgerichteten IT-Organisation. Damit ein DevOps-Team ebenso erfolgreich werden kann, ist es wichtig, das Endergebnis zu kennen, zu definieren und schriftlich festzuhalten. Hier ist es hilfreich, die Erwartungshaltung und Anforderung des Kunden bzw. des Projektes zu kennen, um das Ziel zu definieren, bevor die Projektumsetzung startet. Somit ist für ein DevOps-Team die Planung der Ergebnisse eine große, aber wichtige Herausforderung. Dies fördert das Produkt und Servicedenken, sowie die Zusammenarbeit zwischen Kunden und DevOps-Team und innerhalb des DevOps-Teams selbst.
Es wird Situationen und Probleme geben, die nicht planbar sind und das Team vor Schwierigkeiten stellen. An einer solche Situation muss analysiert werden, ob diese Probleme das Gesamtziel des Projektes gefährden und somit aktiv beseitigt werden müssen, oder ob diese eben nicht das Projektziel gefährden und somit nicht priorisiert behandelt werden müssen.
Um dem Kunden einen schnellen Benefit zu ermöglichen, steht die Entwicklung eines Minimal Viable Products (MVP) zu Beginn des Projektes im Vordergrund. Dieses MVP bildet die erste Version der Software, die dem Kunden zur Verfügung gestellt wird. Ist das Projektziel beispielsweise die Bereitstellung einer Software, die die Arbeitszeit der Mitarbeiter erfasst, kann beispielsweise die Funktionalität nur auf den Check-in und Check-out beschränkt werden, ohne einen vollständigen Stammdatensatz anlegen zu müssen. Nach der Bereitstellung des MVP geht es mit weiteren Kernfunktionalitäten weiter, beispielsweise das Anlegen eines eigenen Benutzeraccounts oder das Ändern bereits erfasster Arbeitszeiten.
Somit wird es in einer DevOps-Organisation weniger das Vorgehen nach dem Wassermodell oder ähnlicher prozessorientierter Modelle geben, da diese sich nicht auf das Gesamtziel fokussieren, sondern auf einzelne Teile des Projekts. Diese Modelle ermutigen Einheiten in einem bestimmten Bereich zu arbeiten, anstatt das Gesamtbild zu überwachen. Projekte, die nach prozessorientierten Vorgehensmodellen bearbeitet werden, sind weder agil noch transparent und verhindern somit auch den Wissenstransfer innerhalb des Teams.
Da klar definierte Kunden- oder Projektziele sich durch Veränderungen am Markt, neue Anforderungen oder weitere Faktoren durchaus ändern können, sollte der transparente Wissensaustausch mit dem Kunden immer gewährleistet werden. Kleine Änderungen am Produkt, beispielsweise durch Anpassungen am Programm werden den Kunden stets mitgeteilt. Ebenso werden kleine Losgrößen an den Kunden übermittelt, um diesen auf den aktuellsten Stand zu halten. Der Kunde behält somit jederzeit den Überblick, hat die Möglichkeit verschiedene Funktionalitäten zu testen, Einstellungen zu hinterfragen und Korrekturen vornehmen zu lassen. Dieser permanente Austausch ermöglicht es, dass nicht nach einer längeren Entwicklungsphase Bausteine erstellt und implementiert wurden, die der Kunde in seinem Anforderungsprofil nicht definiert oder gar verändert hat. Dieses Feedback zwischen DevOps-Team und Kunden bringt somit stets Vorteile, die für beiden Parteien wertbringend sind. Der Fokus verschiebt sich von Projekten auf Produkte und die Arbeit bezieht sich zukünftig nicht mehr auf Einzelne, sondern auf Teams.
Aufbrechen der Silokultur
Um die Fokussierung auf die Produkte zu lenken, muss in erster Linie das "Silodenken" (als Synonym für Abteilungsdenken und -handeln) aufgebrochen werden. Das bedeutet, dass es einen kulturellen Wandel im Unternehmen geben muss. Hier setzt das DASA-Prinzip an, um die Notwendigkeit und die Inhalte der neuen Kultur und Organisation zu verstehen und zu akzeptieren. Diese Struktur muss langsam in die vorhandene Unternehmenskultur eingebracht werden. Dafür gibt es verschiede Ansätze, die die Mitarbeiter umsetzen können, um eben abteilungsübergreifendes Handeln und Denken zu fördern.
Dadurch wird gewährleistet, dass die Verantwortung für das Produkt beim DevOps-Team liegt und die benötigte Agilität eingehalten werden kann. Ihr Ziel ist es, so die Geschwindigkeit der Entwicklung, der Auslieferung sowie die Software-Qualität zu erhöhen und den Produktanforderungen gerecht zu werden. Von der ersten bis zur letzten Zeile Programmcode trägt jedes DevOps-Team die volle Verantwortung für das zu betreuende Produkt. Diese Verantwortungsübernahme fällt unter das Motto "You build it – you run it". Abb. 1 zeigt den Vergleich zwischen der aktivitätsorientierten und der produktorientierten Struktur.
Um diese Darstellung zu verdeutlichen, werden verschieden Beispiele angeführt, die die Unterschiede der beiden Unternehmenskulturen aufzeigen.
Bei der isolierten aktivitätsorientierten Struktur werden die einzelnen Arbeitspakete speziell für Teilabschnitte eines Prozesses optimiert. Jede Abteilung (oder Ressource) überlegt sich, wie die anfallenden Aufgaben schnellstmöglich bearbeitet werden können, um Kapazitäten einzusparen oder Zeit für andere Aufgaben zu gewinnen. Ob eine solche Teiloptimierung Auswirkung auf Folgeprozesse oder Abteilungen haben kann, wird meist zweitrangig betrachtet. Erschwerend kommt hinzu, dass eine einzelne Abteilung die Auswirkung nicht beurteilen kann, da es eben nicht als ein Prozess, sondern als eine Teilaufgabe gesehen wird, die schnell zu beenden ist.
Somit ist es für eine Person in einer Silo-Organisation schwierig, die Auswirkungen ihrer Handlungen in einem anderen Bereich der Silo-Organisation zu erkennen und Maßnahmen zur Verbesserung zu treffen. Die Entwicklung von Software ist eine Anstrengung eines Teams, die schwer zu erreichen ist, wenn man an verschiedenen Orten mit unterschiedlichen Zielen, unterschiedlichen Prioritäten und keiner übergreifenden Sicht auf die Arbeitsliste des Teams arbeitet.
Fehlende Verantwortlichkeit für das Endprodukt verstärkt diesen Ansatz. Da die verschiedenen Aktivitäten im Zusammenhang mit der Erstellung von Software auf mehrere Ressourcen verteilt sind, die sich gegebenenfalls noch an verschiedenen Standorten befinden, fühlt sich keine Abteilung im Prozess für das Endprodukt verantwortlich.
In aktivitätsorientierten Unternehmen werden wöchentliche Termine wie Statusmeeting, Prozessplanung, Ticket-Calls usw. eingehalten. Wenn dies der Fall ist, kommen mehrere Personen aus verschiedenen Abteilungen zusammen und berichten über den aktuellen Status einer Störung, eines Deployments oder des Bearbeitungsstands eines Entwicklungsabschnittes. Erst in diesem Status erfahren die anderen Abteilungen den Fortschritt der beteiligten Kollegen aus den anderen Abteilungen. Eine exakte Ressourcen- und Zeitplanung wird somit deutlich erschwert. Zwischen diesen Terminen erfolgt in der Regel eine asynchrone Kommunikation per Mail, die nicht immer jeden zuständigen Bearbeiter erreicht. Somit kommen die relevanten Informationen nicht immer an die Kollegen, für die diese relevant wären. Hier setzt die produktorientierte Struktur entgegen, indem eine produktorientierte Teamleistung gefördert wird. Der Prozessdurchsatz wird somit gegenüber einer Silostruktur erhöht.
Als weiteres Beispiel wäre die Störungsbehebung anzuführen. Bei einer produktorientierten Kultur werden Störungen beispielsweise vom Helpdesk an das entsprechende Produktteam geleitet. Intern wird die Störung analysiert, kategorisiert, der Fehler identifiziert, der Fehler behoben und die Lösung bereitgestellt. Ein Team sitzt an der Störungsbehebung und liefert eine schnelle Lösung gegenüber Kunden, Anwender und Software. Es bedarf keiner Weiterleitung an Kollegen anderer Abteilungen um zu analysieren, ob beispielsweise die Schnittstelle zum Anwender oder zu weiterer Software unterbrochen ist.
Der Aufbau von WIP (Work in Progress) wird somit bei Übergabemomenten an andere Zuständigkeiten verhindert. Die Wartezeit verkürzt sich dadurch, dass die Bearbeitung in einem Team bleibt und nicht erst auf Rückmeldung der anderen Abteilung gewartet werden muss. Diese Vorgehensweise unterstützt das Ziel im Lean Management, die Anhäufung von Arbeit (WIP) zu verhindern, ganz im Sinne von "Stop starting, start finishing!". Jeder überschüssige WIP sorgt weiterhin für Verzögerungen, da einzelne Ressourcen an verschiedenen Aktivitäten arbeiten und man "geistige Rüstzeiten" einkalkulieren muss. Bei jeder Störung oder Anforderung zu einem anderen Thema muss der Mitarbeiter sich ein Gesamtbild der Situation verschaffen, um entsprechend eine zielführende Weiterbearbeitung zu ermöglichen. Bei jeder Aufgabenumschaltung geht unnötig Zeit für die Behebung von Störungen verloren, die durch eine produktorientierte Struktur vermieden werden kann.
Die folgende Tabelle zeigt die entscheidenden Merkmale der jeweiligen Organisation auf und verschafft einen ganzheitlichen Überblick.
| Merkmale aktivitätsorientierter Organisation | Merkmale produktorientierter Organisation |
|---|---|
| Ressourcen führen jeweils eine bestimmte Aufgabe in einer Kette von Ereignissen aus, beispielsweise das Aktualisieren einer Datenbank. | Ressourcen sind darauf ausgerichtet, Arbeiten zu liefern, die mehrere Fähigkeiten erfordern, z. B. ein Entwickler, der Testvorrichtungen im Code erstellt, weiß auch, wie er einen Lieferprozess automatisieren kann. |
| Ressourcen sind funktional organisiert, das heißt, es werden Ressourcen zu bestimmten Ressourcenpools hinzugefügt, die Spezialisierungen widerspiegeln, z. B. ein Pool von Datenbankadministratoren. | Die Ressourcen sind in einem Team organisiert, das für ein Produkt verantwortlich ist, welches es liefert und betreibt. |
| Ressourcen arbeiten an Projekten mit einem Anfang und einem Ende, und Ressourcen können mehreren Projekten gleichzeitig zugewiesen werden. | Das Team ist während seines gesamten Lebenszyklus mit dem Produkt verbunden und allein für ein laufendes Produkt verantwortlich. Dies dokumentiert sich im Satz "You build it, you run it" . |
| Die Organisation arbeitet mit Personen, die als Experten schwierig austauschbar sind und an denen die Abläufe häufig "hängen". | Hier liegt der Fokus auf Teams und der Überzeugung, dass gut funktionierende Teams durch die Zusammenarbeit bessere Leistungen bringen. |
| Diese Art von Organisation ist für die Ressourcennutzung optimiert. | Diese Art von Organisation ist für Schnelligkeit optimiert. |
Silo-Organisationen verfügen über Ressourcen, die auf Spezialisierungen gruppiert sind, und können aus Sicht der Ressourceneffizienz optimiert werden, jedoch nicht aus Sicht des Prozessdurchsatzes (oder -flusses).
Produktfokussierte und somit agile Teams sind multidisziplinärer Natur, wobei das gesamte Team alle Fähigkeiten besitzt, um ein Produkt in Produktion zu bringen und es in der Produktion zu halten. Durch die Konzentration des Wissens und aller Fähigkeiten in einem Team auf das Endprodukt werden teure Übergabemomente auf ein Minimum reduziert und der Prozessdurchsatz stetig optimiert. Dadurch wird in einer DevOps-Organisation sichergestellt, dass die gewünschte Funktion für den Kunden schnellstmöglich bereitgestellt wird.
Ein stark verbreiteter Ansatz um von einer aktivitätsorientierten Organisation zur produktorientierten Organisation zu gelangen, ist das 3-Wege-Model nach Gene Kim [2].
Das 3-Wege-Modell
Gene Kim hat drei Wege formuliert, die für die Entwicklung einer DevOps-Organisation notwendig sind.
Der erste Weg ermöglicht einen schnellen Links-nach-Rechts-Arbeitsablauf von der Entwicklung bis zum Betrieb zum Kunden. Um diesen schnellen Ablauf zu gewährleisten, muss die Arbeit sichtbar gemacht werden, beispielsweise mittels Kanban-Board.
Eine physikalische Wertkette ist im Vergleich zu einer technologischen Wertkette für jedermann sichtbar. Es kann beobachtet werden, wie die physische Arbeit von Station zu Station weitergegeben wird. Dies ist in der Wertkette der Technologie beispielsweise durch Zuweisen eines Tickets mittels Ticketsystems möglich.
Diese Qualitätssteigerung sorgt dafür, dass die globalen Ziele eingehalten werden können. Die Vorlaufzeit, die benötigt wird, um interne oder externe Kundenwünsche zu erfüllen, wird durch die Bereitstellung von Code in die Produktionsumgebung reduziert.
Den schnellen und konstanten Rückfluss von rechts nach links auf allen Stufen des Wertstroms ermöglicht der zweite Weg. Verstärktes Feedback verhindert, dass Probleme wieder auftreten. Ebenfalls kann durch permanentes Feedback eine frühzeitige Problemerkennung ermöglicht werden, sodass notfalls das funktionierende System schnell wieder hergestellt werden kann. Dadurch werden sichere Arbeitssysteme geschaffen, bevor gravierende Fehler auftreten können.
"Der dritte Weg ermöglicht die Schaffung einer generativen, hoch vertrauensvollen Kultur, die einen dynamischen, disziplinierten und wissenschaftlichen Ansatz für Experimente und Risikobereitschaft unterstützt und die Schaffung von organisationalem Lernen sowohl von unseren Erfolgen als auch von Fehlern erleichtert."
Ist nach erfolgreicher Auslieferung des Endproduktes der Kunde mit der Leistung des DevOps-Teams zufrieden, empfiehlt es sich, sofern vorhanden, weitere Projekte mit dem gleichen Team bzw. der entsprechenden Organisation in die Wege zu leiten. Einerseits können die Kundenanforderungen durch DevOps-Teams schneller umgesetzt werden und andererseits ist es für beide Parteien besser nachvollziehbar, wie die Anforderungen und Umsetzung zu verstehen sind. Darüber hinaus wird der Fokus auf die Maximierung des Produktes durch Minimierung unnötiger Aktivitäten gelegt. Der Grund dafür ist, dass während der Übergaben mehr Zeit verloren geht als die tatsächliche Zeit, die benötigt wird, um die gewünschte Arbeit auszuführen. Die permanente Verkürzung und Verstärkung der Rückkopplungsschleifen sorgen für ein immer stabileres und sichereres Arbeitssystem. Das Arbeitssystem wird auch auf dem dritten Weg dahingehend gestaltet, dass die Effekte, die sich durch neues Wissen des Feedbacks aufzeigen lassen, in Verbesserungen verwandeln lassen [3].
Die Umstrukturierung auf eine produktorientierte Organisation lässt sich aber nicht allein durch die Wandlung von Prozessen und durch den Aufbau von Teams erreichen. Einer der entscheidenden Faktoren ist weiterhin der Mensch, der sich als Mitarbeiter bei einem Wechsel auf eine produktorientierte Organisation auf einen anhaltenden Wechsel der Unternehmenskultur einlassen muss.
Anforderungen gegenüber Mitarbeitern
IT-Organisationen, die sich in Richtung einer DevOps-Organisation wandeln wollen, müssen das Change-Management beachten. Eine solche Entscheidung bedeutet einen vollständigen Kulturwandel und kann nicht zu einem festen Stichtag umgesetzt werden, denn das würde dazu führen, dass alle Abteilungen sich zum Stichtag neu orientieren. Bei einem kleineren Unternehmen von zehn bis zwanzig Mitarbeitern ist das durchaus möglich, nicht aber bei einem Unternehmen mit einer Personalgröße von 15.000 Mitarbeitern. Die Mitarbeiter kennen die definierten Prozesse, haben die Arbeit nach der vorhandenen IT-Service-Management-Methode routiniert und haben die Services unterstützend aufgebaut.
Die Projektmitglieder, die sich dieser Pilotphase unterziehen, brechen die Silostruktur auf und entwickeln etwas Neues im Unternehmen.
Um also eine Umstellung zu ermöglichen, ist es empfehlenswert, zu ermitteln, welche Bereiche, welche Abteilungen durch DevOps unterstützt werden können. In diesen Abteilungen können Pilotprojekte durchgeführt werden. Dazu ist es notwendig, dass die dort eingesetzten Mitarbeiter nicht nur durch externe Unterstützung geschult und beraten werden, sondern auch verstehen, was es bedeutet, den kompletten Prozess nun agiler zu gestalten. Zu diesem Zeitpunkt kann mittels Schulungen und Seminaren Wissen vermittelt werden, um den Grundgedanken von DevOps zu verstehen. Es gilt intern zu definieren und zu bestimmen, was Agilität ausmacht und wie sie im Unternehmen eingesetzt werden kann. Die Projektmitglieder, die sich dieser Pilotphase unterziehen, brechen die Silostruktur auf und entwickeln etwas Neues im Unternehmen.
Elementar dafür ist, dass die Entscheidung Bottom-up, also von den Mitarbeitern gelebt werden muss, auch wenn die Entscheidung vom Management getroffen wurde. Somit muss das ganze Team der Abteilung DevOps umsetzen wollen. Die größten Herausforderungen der Agilität ist die damit verbundene Transparenz. Eine solche Arbeitsweise, die verlangt, dass alle Tätigkeiten, alle abgeschlossenen aber auch offenen Aufgaben aufzeigt werden, bringt Vor- aber auch Nachteile mit sich. Es kann als Druckmittel gegenüber Projektmitgliedern genutzt werden und dazu führen, dass Kollegen sich in diesem Arbeitsumfeld nicht sicher fühlen. Andererseits schafft es eben die gewünschte Transparenz, um zu erkennen, was abgeschlossen ist, und was nicht. Transparenz ist unverzichtbar um eine Arbeitsumgebung nach DevOps zu schaffen.
Die IT-Abteilung im Unternehmen ist nicht mehr als eigene Ressource anzusehen, denn die Entwickler befinden sich nun direkt im Service. Das führt dazu, dass die Ressource IT gegebenenfalls stärker besetzt werden muss, damit diese nicht mehr als rar anzusehen ist.
Ergänzend zur Agilität und zur Transparenz kommt eine Veränderung im ITIL-Vorgehen hinzu. Diese Änderungen fokussieren sich auf die Bereiche Service Transition und Service Operation. Womit auf das Handlungsfeld ITIL eingegangen wird.
Fazit
In diesem Beitrag wurde das zweite DASA DevOps-Prinzip dargestellt. 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.
Weiterhin erreicht dieser Ansatz die Verkürzung von WIP’s durch 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. Durch "Create with the End in Mind" wird mittels der Produktteams der vollumfängliche Prozess des Produktes überblickt und das Ziel des Produktes immer fokussiert, angestrebt und erreicht.
- Die DASA DevOps-Prinzipien
- G. Kim: The Three Ways: The Principles Underpinning DevOps
- G. Kim, J. Humble, P. Debois & J. Willis, 2017: Das DevOps Handbuch
Publikationen
- IT-Service Management mit FitSM
- Perspektivwechsel im IT Service Management: Erfolgsgeschichten oder - Dierk Söllner, Peter Bergmann, itSMF
