Innerbetriebliche Wertefluss IT4IT

DevOps – Schneller, besser und sicherer

Es führt kein Weg mehr an DevOps vorbei. Der kürzlich erschienene «2016 State of DevOps Report» von DORA, den Experten des «DevOps Research and Assessment» lassen keinen Zweifel mehr aufkommen, dass mit der neuen agilen Methode ein enormes Potential bereitsteht. Konkret sollen sogenannte «High-Performance IT Organisationen» gegenüber dem breiten Durchschnitt mehr als 200-mal häufiger neue Releases ausrollen, sind 24-mal schneller beim Beheben von Softwarefehlern, haben 3-mal weniger Ausfälle wegen nicht erfolgreichen Changes sowie sage und schreibe 2’500-mal schnellere Durchlaufzeiten.

Diese Zahlen sind so eindrücklich, dass man sie gern als zu utopisch und marktschreierisch überlesen möchte. Immer öfters hört und liest man aber auch bei uns in der Schweiz von Unternehmen, welche bereits erste Erfolge mit dieser neuen Methode ausweisen können. Organisationen, welche es offenbar geschafft haben, den Rösti-Graben zwischen den Developers und den Operations zu überwinden und bürokratische Silo-Konstruktionen zum Einstürzen brachten.

Die Operations-Leute haben guten Grund, die Produktion zu schützen und unkontrollierte Änderungen möglichst zu vermeiden. Andererseits wollen die Entwickler dem Druck des Business Rechnung tragen und möglichst schnell neue Funktionalität liefern. Ein klassischer Zielkonflikt, welcher die IT in den letzten Dekaden geprägt hat und der bis heute nie richtig gelöst werden konnte. Ein inhärenter Zielkonflikt sozusagen. Das Business soll wählen zwischen «schnell und hudelig» oder «langsam dafür stabil». Qualität vor Zeit wurde dem Business beschieden, weil ansonsten keine Garantie übernommen wurde.

Man muss sich von dieser stereotypischen Sichtweise lösen, will man das Phänomen «DevOps» besser verstehen. Es ist bei weitem nicht so, dass der Entwickler die Produktion in die Knie zwingen will. Auch der Produktionsverantwortliche will die Weiterentwicklung des Business nicht verhindern. Alle wollen im Grunde nur das Beste für das Unternehmen beitragen. Das ist eine wichtige Grundeinstellung, für ein neues Zusammenarbeitsmodell.

Heute versuchen sich bereits einzelne Teams mit Scrum- oder CSI-Ansätzen in ihrem Arbeitsbereich zu optimieren. Was nützen aber mit agilen Sprints erarbeitete Software-Lösungen, wenn diese bei der Releaseplanung wieder aufgestaut werden, um nur als integriertes Ganzes zu einem späteren Zeitpunkt getestet und ausgeliefert zu werden. Zu selten betrachtet man den ganzen Wertestrom von der Idee zur Konzeption, von der Umsetzung in der Entwicklung bis zum Testen, vom Deployment bis in den hoffentlich nutzenstiftenden Betrieb. Überall sind neue Köpfe und Werkzeuge involviert und machen ihr «Ding», wie es eben immer getan wurde. Am Schluss wagt schon niemand mehr zu fragen, was der Nutzen für den Kunden genau ist.

Innerbetriebliche Wertefluss IT4IT

Innerbetriebliche Wertefluss IT4IT

DevOps ist anders. Der Erfolg von DevOps geht über die Nahtstelle von der Entwicklung und dem Betrieb hinaus. Es ist wie so oft nicht primär eine technische Vereinfachung, sondern ein kultureller Wandel von Nöten, welcher die Zusammenarbeit von der Idee bis hin zum Wert generierenden Services komplett auf den Kopf stellt. DevOps ist zwar ein Kunstname aus Development und Operations, sollte jedoch eher «Value-Flow» heissen. Der gesamte Wertefluss will verstanden sein. Dazu gehören auch gemeinsame Anreize und Ziele. Alle Teams stecken die Köpfe zusammen und betrachten, die einzelnen Schritte und beteiligten Prozesse, um zu verstehen, wie sich der Mehrwert entwickelt und wo unnötige Barrieren zu Verzögerungen und Verschwendung führen.

Es braucht hierzu ein Hinterfragen von bestehenden Denkmustern. Da Veränderungen und Stabilität in aller Regel diametral entgegengesetzt sind, werden Änderung aufgeschoben, um sie dann in grösseren gesammelten „Chargen“ als Release in die Produktion zu überführen. Komplexe Systeme reagieren nicht gut auf solch grosse Veränderungen. Es wäre effektiver, die Changes kontinuierlich über die Zeit in kleinen Schritten gesteuert umzusetzen. Daraus ergibt sich die paradoxe Erkenntnis, dass häufigere Wechsel besser für Stabilität sorgt.

Eine andere Sichtweise ist auch die Wahrung der gläsernen Produktion. Wenn die Volatilität der Änderungen künstlich unterdrückt wird, dann neigt die Produktion dazu, eher anfällig auf Änderungen zu reagieren. Risiken sind kaum sichtbar, weil permanent versucht wird, «jeglichen» Schaden von der Produktion fernzuhalten. Wenn dann doch etwas passiert, so wird es kritisch für das Business, weil der Fehler wie eine Stecknadel im Heuhaufen des grossen Releases gesucht werden muss. Wer in steriler Umgebung aufwächst, lernt sich nicht im «dreckigen» Alltag zu behaupten.

Der Entwickler muss künftig seine Software so bauen, dass diese robust ist. Die Qualität muss in der Antifragilität der entwickelten Lösung sein. Dies bedeutet hierbei nicht einfach nur Robustheit oder Stärke, sondern viel mehr die Eigenschaft auf Fehler im System und auf sich spontan ändernder Randbedingungen in geeigneter Weise, eben antifragil, reagieren zu können.

DevOps kann aber sehr spannend werden, wenn man alte Sichtweisen über Bord zu werfen bereit ist: Teams erlernen gemeinsam, schneller und in grösseren Taktraten zu liefern und gleichzeitig sich besser auf das Business auszurichten. Mit DevOps wird der Graben zwischen Entwicklung und Betrieb zugeschüttet. Stabilität und hohe Änderungsdichte müssen kein Widerspruch mehr sein. Wie der DOSA-Bericht zeigt, mit DevOps liefert die IT schneller, besser und zudem noch stabiler und sicherer als herkömmliche Betriebskonzepte.


 

2 Comments
  • Bernd Schachinger

    19. October 2016 at 11:20

    Toller Artikel, Martin !
    Bringt die Sache auf den Punkt. An DevOps kommt man heute kaum noch vorbei, wenn es auch Unkenrufe gibt nach dem Motto „haben wir immer schon so gemacht…“, aber davon sollte man sich nicht beirren lassen.
    Es entfaltet seine ganze Wirksamkeit erst in Kombination mit agilen Entwicklungsmethoden und neuen Tools die dieses Vorgehen unterstützen.
    Besonders gut gefällt mir das Statement: „Die Qualität muss in der Antifragilität der entwickelten Lösung sein.“
    Dazu sind wir noch weit entfernt, weil Reifegrade bei der Softwareentwicklung i.d.R. nicht gefragt sind. Ich würde jedoch künftig Reifegrade einer Software auch mit deren Intelligenz und Antifragilität koppeln.
    Man darf gespannt sein, was noch kommt. Die Software der autonomen Fahrzeuge wird diesen Weg gehen müssen…

  • Martin Andenmatten

    19. October 2016 at 16:16

    Hallo Bernd,

    danke für Dein Feedback. Ja – wir stellen dies aktuell bei diversen Projekten fest. Es werden so ziemlich alle alten Zöpfe abgeschnitten und grundsätzlich hinterfragt.

    Die Entwicklung wird derzeit sehr stark unterstützt von der neuen Referenzarchitektur „IT4IT“, welche ich nur mit dem Bild hier referenziert habe. Aber liess Dich allenfalls auch auf die Beiträge zu IT4IT ein. Damit werden auch Grundlagen geschaffen, Valueflows durchgängig zu implementieren.

    Gruss
    –Martin

Post a Comment