Ein radikaler Vorschlag

Warum wir kontinuierlich alles kaputt machen sollten

Jeff Sussna

© Shutterstock.com/Chones

Jeff Sussna spricht sich in Bezug auf Continuous Delivery und Systemänderungen für tiefgreifende Refaktorisierungen aus. Diese führen seiner Ansicht nach zu insgesamt weniger Ausfällen, geringeren Kosten, sowie zu stabileren Systemen.

Nur wenige Dinge in der IT sind mühseliger und nervenaufreibender als die Portierung oder Refaktorisierung eines langlebigen Systems. Sie könnte zwar so etwas Einfaches wie das Verschieben einer Anwendung auf neue Hardware beinhalten. Allerdings drohen auch komplexe Aufgaben wie beispielsweise die Refaktorisierung der Softwarearchitektur oder der Architektur des zugrundeliegenden Netzwerks.

Die Entdeckung von im übertragenen Sinne Moder und Schimmel ist ein unvermeidbarer Bestandteil dieses Prozesses, nach dem Motto „Oh, ja, das Netzwerk wurde auf diese Weise eingerichtet, weil hier diese seltsame Verbindung zwischen diesen beiden sonderbaren Prozessen besteht.“

Continuous Delivery lehrt uns, dass kleine, häufige Änderungen deutlich leichter zu verwalten, testen und reparieren sind als große, sporadische. In den Worten von Jez Humble: „[…] continuous delivery becomes even more important when you’re risk averse. Big-bang releases are horribly risky.“ Kontinuierliche Änderungen scheinen zwar zu kontinuierlichen Ausfällen zu führen. Entgegen der Intuition reduzieren sie jedoch die fehlerbedingten Gesamtkosten.

Systeme „verrotten“ mit der Zeit, selbst dann, wenn sie nicht verändert werden. Die Gründe hierfür können in menschlichem Versagen bzw. in der Vergesslichkeit liegen. Oder aber die damaligen Entscheidungen sind den aktuellen Umständen nicht mehr angemessen. Das Aufspüren verrotteter Teile ist im Grunde nicht viel anders als die Durchführung von Integrationstests. Je mehr man auf einmal macht, desto komplexer wird es, die auftauchenden Probleme zu verstehen und zu reparieren.

Die Notwendigkeit, schnelle Änderungen durchführen zu können, zeigt sich auf allen Ebenen. Sowohl neue Geschäftsanforderungen als auch neue technische Lösungen stellen sich in immer höherem Tempo ein. Gestern waren es die Cloud und virtuelle Maschinen. Heute lauten die Zauberwörter Cloud-native und Container. Wer weiß schon, was uns morgen erwarten wird?

Die Erwartungen an die Fähigkeit der IT, Systeme portieren und refaktorisieren zu können, steigen ebenfalls. Wir können es uns nicht länger erlauben, unsere Furcht davor zu verdrängen. Stattdessen müssen wir darüber nachdenken, die Prinzipien der Continuous Delivery auch auf Systemänderungen anzuwenden.

Die Idee, eine tiefgreifende Refaktorisierung auf allen Ebenen des IT-Stack durchzuführen, mag radikal, ja sogar töricht klingen. Auf jeden Fall wird diese Vorgehensweise, da sie ständig verrottete Stellen aufspürt, zu kontinuierlichen Ausfällen führen. Allerdings wird sie, ähnlich wie Continuous Delivery, insgesamt zu weniger Ausfällen, geringeren fehlerbedingten Kosten und stabileren Systemen beitragen. Am wichtigsten jedoch: Dies alles wird sie tun, während sie gleichzeitig unsere Fähigkeit, kontinuierliche Änderungen umsetzen zu können, schärft. Diese Fähigkeit ist der bis dato wichtigste Geschäftsimperativ des 21. Jahrhunderts.

Dieser Artikel ist im Original auf Ingineering.IT erschienen.

Aufmacherbild: idea concept with broken bulbs and one glowing bulb von Shutterstock / Urheberrecht: Chones

Geschrieben von
Jeff Sussna
Jeff Sussna
Jeff Sussna is the founder of Ingineering.IT, a Minneapolis technology consulting firm that helps enterprises and Software-as-a-Service companies adopt 21st-century IT tools and practices. He is also the author of ‘Designing Delivery: Rethinking IT in the Digital Service Economy’ and is a regular speaker on the topics of design and DevOps.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: