Antifragilität und Software-Architektur

Ich bin ja seit längerem ein Anhänger von Nassim Nicholas Taleb. Seine Art, Risiken und Wahrscheinlichkeiten zu betrachten hat mich beeindruckt und geprägt. In meiner Arbeit als Agile Coach und Software-Architekt kann ich die Ideen zu Schwarzen Schwänen fast jeden Tag sinnvoll anwenden. Insofern wundert es mich nicht, dass Antifragilität als Konzept auch Einzug in die Welt der Softwarearchitektur hält.

Sein Buch Antifragilität führt als Untertitel „Eine Anleitung für eine Welt, die wir nicht verstehen“. Wenn man das Buch aufmerksam liest und auch mit dem Schwarzen Schwan und den Narren des Zufalls vertraut ist, versteht man aber schnell, dass dieses Buch keine Anleitung für die Welt ist. Es ist eine Anleitung, sich selbst Anleitungen zu erdenken. Also eine Meta-Anleitung.

Taleb definiert Antifragilität als das Gegenteil von Fragilität, als die Eigenschaft eines Etwas, im Falle des Eintritts eines Schwarzen Schwans, also eines unvorhersehbaren Ereignisses, besser zu werden. Üblicherweise werden Robustheit oder Resilienz als das Gegenteil von Fragilität betrachtet, aber beide gehen Taleb nicht weit genug, sorgen sie im besten Fall doch nur für die Erhaltung des Status Quo, wenn ein Schwarzer Schwan eintritt.

Russ Miles’ Idee, antifragile Software-Architekturen auf Microservices basieren zu lassen, wird in meinen Augen Talebs Ideen nicht gerecht. Was Taleb als Antifragilität beschreibt, ist eine Eigenschaft, die durch zwei Dinge ermöglicht wird: Zufall oder Lernen. Ein Beispiel für Antifragilität, die aus Zufall resultiert, ist die Natur. Taleb selbst verwendet dieses Beispiel in seinem Buch, um Antifragilität (Natur) von Resilienz (ein Wald) und Robustheit (ein einzelner Baum) zu unterscheiden. Antifragilität, die aus Lernen resultiert, lässt sich nicht so leicht in Metaphern kleiden und ist weniger offensichtlich.

Um sie zu verstehen, muss man zunächst die 5 Orders of Ignorance von Phillip G. Armour verstehen. Johann-Peter Hartmann hat sie in seinem Talk über Management Brainfucks sehr gut in deutscher Sprache zusammengefasst:
(0OI) Lack of Ignorance: Ich weiß etwas
(1OI) Lack of Knowledge: Ich weiß etwas bestimmtes nicht.
(2OI) Lack of Awareness: Ich weiß nicht, was ich nicht weiß.
(3OI) Lack of Process: Ich weiß nicht, wie ich herausfinde, was ich nicht weiß.
(4OI) Meta Ignorance: Ich weiß nicht, dass es unterschiedliche Arten von Nichtwissen gibt.

Antifragilität durch Lernen bedingt, dass man um die Existenz der Meta Ignoranz weiß. Nur dann kann man sich mit der Ignoranz zweiter und dritter Ordnung beschäftigen. Diese beiden Stufen des Nichtwissens sind nämlich genau die, denen ein Schwarzer Schwan zu verdanken ist. Dinge, die ich weiß oder Dinge, von denen ich weiß, dass ich sie nicht weiß, sind harmlos, denn sie können mich nicht überraschen. Es ist möglich, sich auf sie vorzubereiten – also entweder die Fähigkeit zur Robustheit oder zur Resilienz in Bezug auf sie zu entwickeln.

Genau in diese Kategorie fallen alle Konzepte von Software-Architekturen, wie z.B. Komponentenbasierte Architekturen, Serviceorientierte Architektur und auch Paradigmen wie Verteilung, ReST, BigData – und eben die Microservices. (Hint: Als alter Unixer sind die für mich absolut nichts Neues – SCNR)

Was ich an Russ Miles’ Ideen kritisiere, ist die Verbindung von Antifragilität mit einem konkreten Architekturkonzept. Keine Architektur, die wir als Softwerker heute umsetzen können, bewahrt uns von Schwarzen Schwänen oder wird bei ihrem Eintreten besser. Das kann Software-Architektur heute nicht leisten und das wird sie auch in Zukunft nicht leisten können. Denn die Software-Architektur selbst kann nur die Ignoranz nullter und im besten Fall erster Ordnung adressieren.

Um Antifragilität in die Software-Achitektur zu bringen, darf man sich nicht auf die Technik, Konzepte oder Paradigmen konzentrieren. Diese sind per se nicht Antifragil, da sie sich weder zufällig weiterentwickeln noch selbst lernen können. Man muss sich also auf die Menschen konzentrieren, die solche Architekturen konstruieren. Diese Menschen, wir Software-Architekten, können lernen und erfüllen somit eine der Vorbedingungen für Antifragilität. Und was wir lernen müssen, um Software-Achitektur antifragil zu machen, zeigen die zweite und dritte Stufe des Nichtwissen. Wir müssen lernen, mit Dingen umzugehen, von deren Existenz man nichts weiß und wir müssen lernen, solche Dinge systematisch zu erkennen.

Dieses systematische Erkennen geht mit etwas einher, das in der Welt der Software-Entwicklung nur ungern akzeptiert wird: der Akzeptanz des Unvorhersehbaren, des nicht Planbaren, jenen Dingen, die Software-Entwicklung vermeintlich kompliziert und teuer machen. Diese Akzeptanz ist aber notwendig, um Antifragilität in die Welt der Software-Architektur zu bringen. Es ist unabdingbar, die Existenz von Ignoranz zweiter und dritter Ordnung akzeptieren und damit auch die Unmöglichkeit, Architekturen, ja noch nicht einmal Meta-Architekturen, zu konstruieren, die per se antifragil sind. Antifragile Software-Architektur bedeutet bewussten Umgang mit Nichtwissen und Akzeptanz von Emergenz durch den Software-Architekten.

Antifragilität, die Verbesserung durch den Eintritt eines Schwarzen Schwans, ist dann nicht mehr eine Eigenschaft der Architektur, sondern vielmehr des Architekten.

8 Kommentare bei „Antifragilität und Software-Architektur

  1. Schöner Artikel, der angesicht meiner kommenden Keynote (https://entwicklertag.de/frankfurt/2015/keynote-antifragile-software-f%C3%BCr-die-welt-des-21-jahrhunderts) für mich sehr spannend ist.

    Ich glaube, du gehst zu scharf mit Russ ins Gericht. Dass keine Architektur auf alle Unbekannten vorbereitet sein kann, stimmt. Aber alles, was antifragil ist, ist das nur bis zu einer gewissen Stärke der Stressoren. Selbst die Evolution, als Prototyp des antifragilen Systems, könnte durch eine entsprechende Katastrophe, z.B. einen erdzerstörenden Meteoriten, komplett zum Stillstand kommen.

    Meine Folgerung aus deinen Argumenten ist daher, dass wir die Ideen der Antifragilität auf den unterschiedlichen Ebenen unterschiedlich umsetzen müssen. Eine Architektur kann auf manche Stressoren durch Selbststärkung reagieren, auf andere nur durch Zusammenbruch. Das gilt aber für die Lernfähigkeit des Menschen genau so.

    1. Hallo Johannes,

      danke für Deinen Kommentar!
      Mag sein, dass ich mit Russ zu hart ins Gericht gehe. Wenn man aber Taleb aufmerksam zuhört, dann kommt man nicht umhin, zu erkennen, dass Antifragilität eine Eigenschaft von Verhalten ist und nicht von Struktur. Insbesondere kann sie eine Eigenschaft des Verhaltes komplexer Systeme sein.

      Insofern ist es gar nicht möglich, eine antifragile Software-Architektur zu erschaffen. Lediglich der Weg ihrer Entstehung kann antifragil sein.

      1. Die Architektur selbst kann nicht antifragil sein, sie kann aber ein antifragiles Verhalten des darauf aufbauenden Softwaresystems erleichtern. Insofern beschränkt sich Antiifragilität für mich nicht auf die Entstehung von Systemen, sondern hat auch für deren Ausführung eine Bedeutung.

        1. Die letzte Aussage sehe ich genau anders. Antifragilität ist eine Verhaltenseigenschaft, keine Struktureigenschaft – aber kann Software zur Ausführungszeit, wenn sie mit nicht vorhersehbaren Ereignissen konfrontiert wird, besser werden?

          Nach meinem Verständnis kann sie das nicht. Sie kann auf Ausnahmen nur im Rahmen dessen reagieren, das ihr Schöpfer vorgesehen hat. Und das ist notwendigerweise unvollständig.

          Anders ausgedrückt: Um Antifragil zu sein, benötigt ein komplexes System die Fähigkeit zu einem Verhalten, das seine Struktur nachhaltig ändert.
          Und das sehe ich bei Software derzeit nicht.

          1. Genau das ist für mich eine der interessanten Fragen: Wie können wir Software so bauen, dass sie auch zur Laufzeit sich ausreichend ändern kann, um auf Stressoren zu reagieren. Die meiste SW tut das heutzutage sicherlich nicht. Ein relativ naives scale-up/down in der Cloud würde ich bereits als einen kleinen Schritt in diese Richtung betrachten. Dem noch viele folgen müssen.

          2. Ein Scale-up/down wäre allenfalls resilient, keinesfalls antifragil.

            Warum? Die Notwendigkeit eines Scale-up/down ist nicht unvorhersehbar.
            Die Software ist nach dem Scale-up/down nicht besser geworden, ihre Struktur hat sich nicht an eine veränderte Situation nach dem Auftreten des Ereignisses angepasst.
            Grundlage von Antifragilität sind nicht vorhersehbare Ereignisse und die Verbesserung eines komplexen Systems durch die Störung.
            Antifragilität befindet sich also – aus Perspektive eines Modellierers – auf der Ebene des Metamodells, während jede Implementierung immer nur auf der Ebene des Modells existieren kann oder sogar noch konkreter ist.

            Ich nehme dazu eine andere Perspektive auf Software ein. Die Ausführung von Software ist hinsichtlich Schwarzer Schwäne uninteressant, ebenso ihre Struktur.
            Das was Software als komplexes System ausmacht, ist ihr Entstehung. Wenn während dieser das Prinzip der Antifragilität verstanden ist, ist der Rest trivial.

          3. > Ein Scale-up/down wäre allenfalls resilient, keinesfalls antifragil.
            > Warum? Die Notwendigkeit eines Scale-up/down ist nicht unvorhersehbar.
            > Die Software ist nach dem Scale-up/down nicht besser geworden, ihre Struktur hat
            > sich nicht an eine veränderte Situation nach dem Auftreten des Ereignisses
            > angepasst.

            Das gilt für den nach dem Training gestärkten Muskel ebenfalls. Er ist nicht besser geworden und hat auch nicht seine grundlegende Struktur verändert. Er kann einfach auf den nächst stärkeren Reiz mit stärkerer Gegenkraft reagieren.

            Vermutlich werden wir uns nicht einigen. Ich versuche, aus der Idee der Antifragilität nützliche Aspekte für die SW-Entwicklung rauszuziehen. Ob das immer der Definition vollständig gerecht wird, ist dabei nur theoretisch interessant (und damit eine fragile Diskussion ;-). Als Praktiker möchte ich herausfinden, ob sich die von mir abgeleiteten Ideen in der Praxis auszahlen oder nicht. Also keine teleologische Argumentation, sondern eher die eines Tüftlers.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.