Der lange und steinige Weg zur Resilienz – Teil 2: Das Tal der Feature-Vollständigkeit

Im letzten Beitrag haben wir den Grundstein für unsere Reise zur Resilienz gelegt, indem wir geklärt haben, was Resilienz ist. Das war notwendig, um ein gemeinsames Ziel für unsere Reise zu schaffen.

In diesem Beitrag werden wir den Ausgangspunkt unserer Reise betrachten und diskutieren, warum es nicht mehr sinnvoll ist, dort zu verweilen.

Beachte, dass ich eine prototypische Reise eines Unternehmens von Null zu Resilienz beschreiben werde. Der Ausgangspunkt und die Zwischenstationen sind Zustände, die ich selbst schon mehrfach erlebt habe. Dennoch handelt es sich um ein vereinfachtes Modell, was bedeutet, dass der Weg deines Unternehmens anders aussehen kann.

Vielleicht kannst du den Zustand deines Unternehmens nicht mit einem einzigen Ort in Verbindung bringen, den ich beschreiben werde. Vielleicht findest du in deinem Unternehmen eine Mischung von Eigenschaften, einige von Ort A und einige von Ort B. Das ist alles völlig in Ordnung. Die Realität ist immer verworrener als ein gutes Modell.

Die Reise, die ich diskutieren werde, soll helfen, über den Zustand deines Unternehmens nachzudenken und über sinnvolle nächste Schritte nachzudenken. Sie liefert Erkenntnisse, die für die nächste Zwischenstation der Reise notwendig sind. Es werden typische Maßnahmen erörtert, die erforderlich sind, um zu diesem Zwischenstopp zu gelangen. Sie zeigt Abwägungen und blinde Flecken auf. All diese Dinge sind Argumentationshilfen. Nicht mehr. Aber auch nicht weniger.

Die Metapher des Bergsteigens

Ich werde eine Bergsteiger-Metapher verwenden, um den Weg zur Resilienz zu beschreiben. Wir beginnen in einem scheinbar lieblichen Tal und erklimmen schrittweise den Gipfel, wobei wir unterwegs auf mehreren Hochebenen Rast machen.

Ich verwende diese Metapher, um zu verdeutlichen, dass die Reise zur Resilienz keine schöne und einfache Fahrt auf einer asphaltierten Straße ist, mit heruntergekurbeltem Fenster, ausgestrecktem Arm, Wind in den Haaren und einer schönen Melodie aus dem Radio.

Das wünschen sich viele Menschen, Entscheidungsträger auf höherer Ebene ebenso wie Software-Ingenieure. Sie hätten gerne eine einfache 5-Punkte-Liste, die sie einfach abhaken können, und dann – voilà – sind sie resilient. Mission erfüllt! Juhu!

Leider ist es nicht so einfach. Resilienz zu erlangen ist harte Arbeit, vor allem die späteren Schritte. Deshalb verwende ich die Metapher des Bergsteigens, um das zu verdeutlichen:

• Es wird nicht einfach sein.

• Teile der Reise werden anstrengend sein.

• Es wird Hindernisse auf dem Weg geben, die wir überwinden müssen.

Aber die Aussicht vom Gipfel ist atemberaubend ... ;)

Veränderung als orthogonales Thema

Viele der Hindernisse, die wir überwinden müssen, haben mit der Umsetzung von Veränderungen zu tun – technische Veränderungen, Kommunikationsänderungen, Prozessänderungen und organisatorische Veränderungen. Wie ich in früheren Beiträgen erörtert habe, sind Veränderungen immer schwierig und chaotisch. Wie ich außerdem in meinem Beitrag über das Dilemma zwischen Bedarf und Wunsch dargelegt habe, reicht es nicht aus, die Menschen zu überzeugen (was schon schwer genug ist). Es ist auch notwendig, das übergeordnete System, die Organisation und die Art der Zusammenarbeit zu ändern.

Viele Leute fragen mich dann nach dem Patentrezept, um Veränderungen durchzusetzen. Natürlich fragen sie nicht direkt nach einem Patentrezept, aber im Grunde ist es das, was sie gerne von mir haben möchten. Die Wahrheit ist: Es gibt kein Patentrezept! Es tut mir leid, dass ich deine stillen Hoffnungen enttäuscht habe.

Es gibt einen Grund, warum es Hunderte und Tausende von Büchern über die Umsetzung von Veränderungen gibt – und der Grund ist, dass Veränderungen schwierig sind. Wenn es ein Patentrezept gäbe und ich es kennen würde, hätte ich ein Buch darüber geschrieben und würde bequem von den Tantiemen leben.

Selbst bekannte Experten auf dem Gebiet des Wandels wie z. B. John Kotter (die – im Gegensatz zu mir – recht gut von ihren Buchtantiemen leben) haben noch kein Patentrezept gefunden. Sie bieten zwar viele gute und umsetzbare Ratschläge, aber die Umsetzung von Veränderungen ist nach wie vor schwierig und chaotisch.

Insgesamt ist das Veränderungsmanagement ein orthogonales Thema, das immer dann erforderlich ist, wenn man etwas verändern will, und daher nicht spezifisch für Resilienz. Da ich selbst kein Experte für Veränderungen bin, werde ich mich auf die erforderlichen Argumentationshilfen und Argumente beschränken, die du auf der rationalen Seite benötigst. Wenn du nach Ratschlägen suchst, wie du Veränderungen in deiner Organisation am besten umsetzen kannst, verweise ich auf die Bücher über Veränderungen, die es in Hülle und Fülle gibt. (1)

Neben der Implementierung der Veränderung gibt es noch einige weitere Hindernisse, die wir auf dem Weg dorthin überwinden müssen. Das Gute an dieser Geschichte ist, dass wir nicht den Mount Everest besteigen müssen. Wir müssen nicht in lebensfeindliche Höhen klettern und es kaum lebendig bis zum Gipfel schaffen. Wir wollen den Berg der Resilienz erklimmen. Das ist immer noch eine Herausforderung. Aber es ist machbar.

Das Tal der Feature-Vollständigkeit

Also gut, eine Bergbesteigung. Wir sind vorbereitet und bereit, unsere Reise anzutreten. Aber wo fangen wir an, und warum sollten wir den Ort, an dem wir uns gerade befinden, überhaupt verlassen? Schauen wir uns einmal um.

Ich neige dazu, den Ausgangspunkt das Tal der Feature-Vollständigkeit zu nennen. Die IT-Organisationen vieler Unternehmen, die ich kenne, befinden sich noch immer in diesem Tal. Die Kerneigenschaft einer solchen Organisation ist, dass

• die IT-Entwicklungsabteilung (Dev) für die Bereitstellung von Features zuständig ist, während
• die IT-Betriebsabteilung (Ops) für die Verfügbarkeit der laufenden IT-Systeme verantwortlich ist.

Das bedeutet auch, dass die Entwicklungs- und die Betriebsabteilung getrennte Abteilungen sind, deren Anreizsysteme auf unterschiedlichen Zielen basieren. Die Entwicklungsabteilung erhält Anreize auf der Grundlage der Anzahl der implementierten Funktionen, während die Betriebsabteilung Anreize auf der Grundlage der Produktionsstabilität und der Verfügbarkeit der von ihr betriebenen IT-Systeme erhält.

Verfügbarkeit und Zuverlässigkeit

Wenn wir uns mit Resilienz beschäftigen, müssen wir die Verfügbarkeit der Systeme betrachten. Eines der Hauptziele von Resilienz ist die Maximierung der Verfügbarkeit des jeweiligen Systems, d. h. den Zeitanteil zu maximieren, in dem das bezogene System entsprechend der Systemspezifikation agiert und auf externe Stimuli reagiert (oder zumindest sinnvolle gesetzte Erwartungen erfüllt, wenn es keine formale Spezifikation gibt). Dabei spielt es übrigens keine Rolle, ob es sich um ein technisches oder ein nichttechnisches System handelt.

Nur der Vollständigkeit halber: Im Zusammenhang mit sicherheitskritischen Systemen betrachten wir oft eher die Zuverlässigkeit (Qualitätsmerkmal Reliability) als die Verfügbarkeit (Qualitätsmerkmal Availability). Zuverlässigkeit beschreibt die Wahrscheinlichkeit, dass ein System innerhalb einer definierten Zeitspanne korrekt agiert und reagiert. Der Unterschied besteht darin, dass Verfügbarkeit den Prozentsatz der Gesamtzeit angibt, in der ein System gemäß seiner Spezifikation reagiert.

Bei einer Herz-Lungen-Maschine z. B. ist es wichtig, dass sie während einer Operation einwandfrei funktioniert. Es spielt keine Rolle, ob sie danach für drei Wochen zur Wartung geschickt wird. Es kommt nur darauf an, dass sie während der Operationen einwandfrei funktioniert, denn eine Fehlfunktion der Maschine während einer Operation würde das Leben des Patienten in Gefahr bringen.

Im Vergleich dazu sind gelegentliche Ausfälle z. B. in einem E-Commerce-System, unkritisch, solange sie relativ selten auftreten und nicht zu lange dauern. Daher betrachten wir in nicht sicherheitskritischen Kontexten – und das sind die meisten Kontexte im Zusammenhang mit Unternehmenssoftware – eher die Verfügbarkeit als die Zuverlässigkeit. Wir interessieren uns mehr für den Gesamtprozentsatz der Zeit, in der das System seine Aufgabe ordnungsgemäß erfüllt, als für die Wahrscheinlichkeit, dass ein System innerhalb eines bestimmten Zeitrahmens nicht ausfällt.

Da die meisten von uns in nicht sicherheitskritischen Umgebungen arbeiten, werde ich mich bei der Diskussion über den Weg zur Resilienz auf Verfügbarkeit beschränken. Bedenke jedoch, dass wir in sicherheitskritischen Umgebungen in der Regel eher an Zuverlässigkeit interessiert sind. (2)

Verfügbarkeit als P.A.L.

Kommen wir nach diesem kurzen Exkurs zurück zum Tal der Feature-Vollständigkeit: Wir können beobachten, dass das gesamte Entwicklungsbudget für die Implementierung von Geschäftsfunktionen reserviert ist. Verfügbarkeit wird an Ops „ausgelagert“. Aus Sicht der Entwicklungsabteilung ist Verfügbarkeit kein Thema, sondern ein P.A.L. (Problem Anderer Leute).

Evaluations-Schema

Bevor wir beurteilen, ob eine solche Trennung der Zuständigkeiten ein tragfähiges Konzept im Kontext von Resilienz ist, wollen wir zunächst eine strukturierte Bewertung des Tals der Feature-Vollständigkeit vornehmen, wobei wir uns besonders auf die Parteien jenseits von Ops konzentrieren (da Ops immer ein echtes Interesse an Resilienz – oder zumindest hoher Verfügbarkeit – haben wird). Wir werden das gleiche Bewertungsschema für alle Stationen unserer Reise verwenden und dabei die folgenden Aspekte betrachten:

• Haupttreiber – was ist das Hauptziel in Bezug auf Resilienz?
• Leitfragen – welche Fragen treiben die Maßnahmen an?
• Typische Maßnahmen – Beispiele für Maßnahmen, die zur Umsetzung des jeweiligen Resilienzniveaus verwendet werden
• Trade-offs – die Vor- und Nachteile der jeweiligen Station unserer Reise
• Wann ist es sinnvoll – wann ist es in Ordnung, einen solchen Ansatz in Bezug auf Resilienz zu verwenden
• Wann ist es zu vermeiden – wann wir unsere Reise nicht an der gegebenen Haltestelle stoppen dürfen
• Wirkungskreis – wer und was ist von den erforderlichen resilienzbezogenen Maßnahmen betroffen
• Blinder Fleck – was der Haupttreiber übersieht und die Reise zur nächsten Station auslöst, sobald es erkannt wird

Bewertung des Tals der Feature-Vollständigkeit

Mit Hilfe dieses Bewertungsschemas können wir das Tal der Feature-Vollständigkeit auf strukturierte Weise bewerten:

Haupttreiber

Der Haupttreiber ist die Maximierung des Durchsatzes an Geschäftsfunktionen (Business Features).

Die gesamte Organisation betrachtet die IT lediglich als Mittel zur Umsetzung der IT-Anteile ihrer Geschäftsideen, d. h. die IT wird in der Regel als Kostenstelle (Cost Center) betrachtet. Folglich geht es in der IT vor allem darum, so viele Funktionen wie möglich zu den geringstmöglichen Kosten zu implementieren.

Von Ops wird erwartet, dass sie eine hohe Laufzeitverfügbarkeit der IT-Systeme garantieren, aber niemanden interessiert, wie sie das tun. Verfügbarkeit wird als P.A.L. betrachtet – oder genauer gesagt: als ein Ops-Problem.

Leitfragen

Typische Leitfragen sind:

• Werden die Geschäftsanforderungen korrekt umgesetzt?
• Wie können wir Features schneller implementieren?

Es geht darum, die Kosten pro Feature zu minimieren und gleichzeitig die fachliche Korrektheit zu bewahren. Die Feature-Kosten werden innerhalb der Grenzen des umgebenden Projekts minimiert, was die typische Organisationsform der Softwareentwicklung ist. Diese lokalen Optimierungen

• berücksichtigen weder die Auswirkungen der Kostenoptimierung für andere Teile der Systemlandschaft, die nicht Teil des Projekts sind
• noch die Auswirkungen für die zukünftige Wartung und Evolution der geänderten Systemteile über das Projektende hinaus
• noch berücksichtigen sie irgendwelche laufzeitbezogenen Eigenschaften wie Verfügbarkeit (Availability) , Betreibbarkeit (Operability), Beobachtbarkeit (Observability), Sicherheit (Security), Skalierbarkeit (Scalability), Leistung (Performance), Wiederherstellbarkeit (Recoverability), Ressourcenverbrauch (Resource Usage) und so weiter, es sei denn, sie stehen in direktem Zusammenhang mit dem jeweiligen Geschäfts-Feature.

Typische Maßnahmen

Die Maßnahmen in Bezug auf Resilienz – oder genauer gesagt: die Maximierung der Verfügbarkeit – finden alle auf Ops-Seite statt, da der Rest der Organisation dieses Thema ignoriert und einfach erwartet, dass sich die Ops darum kümmern. Typische Maßnahmen sind:

• Bereitstellung redundanter Hardware und Infrastrukturkomponenten, einschließlich Hochverfügbarkeits-Hardware
• Redundanter Betrieb der Softwaresysteme hinter einem Load Balancer mit Failover oder innerhalb einer Clusterlösung mit Failover
• Strenge Übergaberegeln für Dev-Artefakte, da Ops (berechtigterweise) nicht darauf vertraut, was Dev „über die Mauer wirft“
• Lange Testphasen vor der Produktion, um potenzielle Produktionsprobleme zu prüfen – wiederum, weil Ops (berechtigterweise) nicht darauf vertraut, was Dev „über die Mauer wirft“
• ...

Insgesamt: Alles, was Ops beeinflussen kann.

Trade-offs

Die grundlegenden Kompromisse einer solchen Umgebung sind:

• Für Devs ist es vergleichsweise angenehm, weil sie sich um weniger kümmern müssen. Insbesondere können sie alle relevanten Laufzeiteigenschaften der Software ignorieren und sich ausschließlich auf die Implementierung der Geschäftslogik konzentrieren (was je nach Umgebung stressig genug sein kann).
• Für Ops ist das nicht so angenehm, denn von ihnen wird erwartet, dass sie Software zuverlässig ausführen, die ohne Rücksicht auf Verfügbarkeit oder andere relevante Laufzeiteigenschaften erstellt wurde.
• Resilienz ist ein Nicht-Thema. Die zugrunde liegende Annahme ist, dass alles immer unter Kontrolle ist.

Wann ist es sinnvoll

Ein solcher Ansatz ist in Ordnung, wenn du dich nicht in einem sicherheitskritischen Kontext befindest und deine IT-Systemlandschaft hauptsächlich aus monolithischen, isolierten Systemen besteht, die über Batch-Schnittstellen miteinander kommunizieren.

Ich werde diese Bewertung im nächsten Beitrag in Verbindung mit der Diskussion über den blinden Fleck dieses Ansatzes ausführlicher erörtern.

Wann ist es zu vermeiden

Ein solcher Ansatz sollte vermieden werden, wenn deine IT-Systemlandschaft aus vielen hochgradig vernetzten Systemen besteht, die über Online-Schnittstellen miteinander kommunizieren – was für heutige IT-Systemlandschaften üblich ist.

Er ist unzureichend für Umgebungen, die intern verteilte Systeme verwenden (Stichworte: servicebasierte Architekturen, Microservices) und völlig unzureichend für sicherheitskritische Kontexte.

Auch auf diese Bewertung werde ich im nächsten Beitrag im Zusammenhang mit der Diskussion des blinden Flecks dieses Setups näher eingehen.

Wirkungskreis

Der Wirkungskreis der resilienzbezogenen (oder besser: verfügbarkeitsbezogenen) Maßnahmen ist auf die Ops-Abteilung und den Teil der IT-Systemlandschaft beschränkt, den Ops beeinflussen kann.

Blinder Fleck

Kurz gesagt, aus einer Nicht-Ops-Perspektive ist der blinde Fleck dieses Aufbaus alles außer den Geschäftsfunktionen – was die Frage aufwirft, ob „blinder Fleck“ hier der richtige Begriff ist oder ob wir es eher als „blinde Fläche mit einem kleinen nicht-blinden Fleck“ bezeichnen sollten. Dieses Setup ignoriert insbesondere die Realität der heutigen Systemlandschaften. Es ignoriert auch die Resilienz und behandelt Verfügbarkeit als P.A.L. (oder besser gesagt: als Ops-Problem).

Zusammenfassung

Wenn wir uns die Bewertung des Tals der Feature-Vollständigkeit ansehen, erkennen wir, dass dieses Setup für fast alle heutigen IT-Systemlandschaften ungeeignet ist. Sie lässt Resilienz völlig außer Acht und macht Verfügbarkeit zu einem reinen Ops-Problem, während der Rest der Organisation sie völlig ignoriert. Schlimmer noch, das Verhalten der Nicht-Ops-Teile der Organisation ist in Bezug auf Verfügbarkeit oft kontraproduktiv.

Es stellt sich die Frage, warum ein solches Setup immer noch ziemlich häufig anzutreffen ist, obwohl es für die Anforderungen der heutigen IT-Systemlandschaften nicht mehr geeignet ist.

Wir werden diese Frage im nächsten Blog Post ausführlicher diskutieren. Wir werden auch erörtern, wie die Erkenntnis, dass dieser Ansatz nicht mehr ausreicht, uns zum ersten Plateau unserer Reise führt. Und wir werden besprechen, was wir auf dem ersten Plateau finden. Bleib dran ... ;)

(1) Persönlich kann ich neben den Veränderungsbüchern von dem bereits erwähnten John Kotter die Bücher „Fearless Change: Patterns for Introducing New Ideas„ und „More Fearless Change: Strategies for Making Your Ideas Happen" von Mary Lynn Manns und Linda Rising. Sie haben nützliche Veränderungspraktiken entlang eines Veränderungsprozesses mit Hilfe eines Musteransatzes schön gegliedert. ︎

(2) Wenn ein sicherheitskritisches System rund um die Uhr funktionieren muss, wie z. B. ein Kraftwerk, sind wir an beidem interessiert, an Zuverlässigkeit und Verfügbarkeit.

Dieser Blogpost ist ursprünglich auf Englisch in Uwe Friedrichsens Blog erschienen