Residualitätstheorie: Architektur, die Stress überlebt

Die meisten Architektur-Methoden versuchen, die Zukunft zu erraten: Requirements sammeln, Risiken auflisten, Massnahmen planen. Die Residualitätstheorie von Barry O’Reilly dreht das um. Ihre kontraintuitive Kernaussage: Wer eine Architektur zufällig stresst, bekommt ein System, das unerwartete Ereignisse besser überlebt als eines, das sorgfältig nach Anforderungen entworfen wurde. Dieser Post fasst die Idee in eigenen Worten zusammen. Die Originalquelle ist als Quellen-Knoten abgelegt.

1. 🧩 Komplexität ist nicht Logik und nicht Struktur

O’Reilly erzählt die Geschichte der Softwarearchitektur als drei Phasen, je nachdem, wie man Komplexität auffasst. Zuerst die logische Phase (ab Turing, 1936): Die Welt sei auf Logik reduzierbar, daraus entstehen formale Methoden und Spezifikationen. Dann die strukturelle Phase (ab den NATO-Konferenzen 1968): Software soll modular sein, und auch das Umfeld wird in Strukturen gepresst, in Prozesse, Value Streams, Org-Charts. Daraus wird die Enterprise-Architektur.

Beide Phasen machen denselben Fehler: Sie nehmen an, das Geschäftsumfeld sei stabil. Ab 1979 (Lehmans Gesetze) wird klar, dass die Realität weder logisch noch strukturiert ist, sondern fliessend und komplex. Genau hier setzt die Residualitätstheorie an. Sie behandelt das Umfeld ehrlich als komplexes System und leiht sich ihr Werkzeug aus den Komplexitätswissenschaften.

flowchart LR
    A["1936 Logik<br/>formale Methoden, Spezifikation"] --> B["1968 Struktur<br/>Module, Prozesse, Enterprise-Architektur"]
    B --> C["1979 adaptiv<br/>Umfeld ist fliessend"]
    C --> D["heute Komplexitaet<br/>Residualitaetstheorie"]

2. 🌀 Attraktoren: die Zustände, die ein System erreichen kann

Der Schlüsselbegriff stammt von Stuart Kauffman und seiner Arbeit zu Netzwerken (sogenannte NK-Netzwerke). Ein komplexes System aus vielen verbundenen Elementen kann theoretisch unzählige Zustände annehmen, pendelt sich in der Praxis aber nur in einer begrenzten Zahl stabiler Zustände ein. Diese stabilen Zustände heissen Attraktoren.

Die natürliche Reaktion eines westlich geschulten Ingenieurs ist, das ganze System verstehen zu wollen. Das ist bei echter Komplexität aussichtslos. Der Trick: Man arbeitet nicht gegen die Komplexität, sondern interagiert mit den Attraktoren. Sie sind die handhabbare Schnittstelle zu einem sonst unbegreiflichen Geschäftsumfeld.

Der typische Architektur-Fehler ist, nur für einen Attraktor zu bauen, den «Happy Path», den glücklichen Normalfall. Sobald das Umfeld in einen anderen Attraktor springt, bricht die Architektur.

3. 🔨 Naive Architektur, Stress, Residuum

Wie findet man die Attraktoren, wenn man sie vorher nicht kennt? Indem man das System stresst. Der Ablauf:

  1. Man startet mit einer naiven Architektur, dem ersten naheliegenden Entwurf für den Happy Path.
  2. Man wirft einen Stressor darauf, ein «Was, wenn …». Das verschiebt das System in einen neuen Attraktor.
  3. Man fragt: Überlebt meine Architektur diesen Attraktor? Meist nicht. Die kaputten Reststücke, das, was man ergänzen muss, um zu überleben, nennt O’Reilly das Residuum (englisch residue).
  4. Man parkt dieses Residuum und stresst weiter.
flowchart TD
    A["Naive Architektur<br/>(Happy Path)"] --> B["Stressor anwenden<br/>(Was, wenn ...)"]
    B --> C["Neuer Attraktor"]
    C --> D{"Architektur<br/>ueberlebt?"}
    D -->|Nein| E["Residuum bauen<br/>(fehlende Teile ergaenzen)"]
    E --> F["Residuum parken"]
    F --> B
    D -->|Ja| F
    F --> G["Residuale Architektur<br/>(Stapel von Residuen)"]

Am Ende ist die Architektur ein Stapel von Residuen auf einer naiven Grundarchitektur. Residuen werden so zur eigentlichen Einheit der Softwarearchitektur. Nicht jedes muss umgesetzt werden, aber jedes deckt einen blinden Fleck auf.

Der mathematische Hebel dahinter: Es gibt viel mehr mögliche Auslöser (die «X») als Attraktoren. Viele verschiedene Ereignisse drücken das System in denselben Attraktor. Identifiziert man ein einziges X, findet man den Attraktor, baut das passende Residuum und überlebt damit automatisch alle anderen X, die in denselben Attraktor führen. Daher die scheinbar magische Robustheit.

flowchart LR
    X1["X1"] --> AT["Attraktor"]
    X2["X2"] --> AT
    X3["X3"] --> AT
    X4["X4 (unbekannt)"] --> AT
    AT --> R["1 Residuum"]
    R --> S["ueberlebt alle X<br/>dieses Attraktors"]

4. 🔌 Beispiel: Ladestationen für E-Autos

O’Reilly illustriert das an einem System für E-Auto-Schnellladestationen. Kunden fahren vor, halten einen Schlüssel-Fob an die Säule, das System prüft das Abo in der Cloud und gibt das Laden frei. Das ist die naive Architektur. Jetzt wird gestresst:

  • Was, wenn der Login ausfällt? Ein Kunde mit leerem Akku steht fest, dahinter staut sich Frust. Residuum: automatische Nummernschild-Erkennung, der Kunde lädt trotzdem und bekommt die Rechnung per Post. Nebeneffekt: ein effizienterer Weg, neue Kunden zu gewinnen.
  • Was, wenn die Säule beschädigt wird? (Leute fahren erstaunlich oft in Zapfsäulen.) Residuum: Sicherheitskameras für Versicherungsfälle plus Redundanz, weil immer eine Säule ausfällt.
  • Was, wenn jemand sechs Stunden zum Golfen stehen lässt? Das Geschäftsmodell lebt von 25-Minuten-Ladungen. Residuum: Abrechnung pro Minute auf einer Staffel, der Parkplatz wird teuer.

Später taucht ein Phänomen auf, das in keinem Requirement stand: «Icing», bei dem Leute aus politischen Motiven mit Verbrennern die Ladesäulen blockieren. Das System überlebt es mühelos, weil die Residuen aus den absurden Stressoren schon alles Nötige geliefert haben: Nummernschild-Erkennung, Kamera, Redundanz, teure Staffelabrechnung. O’Reilly nennt das Off-Spec-Survival: Das System überlebt Dinge, die nie spezifiziert wurden.

Wichtig ist die Qualität der Stressoren. Menschen sind schlecht im Zufälligsein (der «Fluch der Dimensionalität»). Wir werfen unsere Darts in die Mitte, auf das Wahrscheinliche. Darum braucht es absurde Fragen wie «Was, wenn feuerspeiende Echsen Kopenhagen zerstören?». Gerade das Lächerliche legt oft einen echten Riss in der Architektur frei. Die alten Architektur-Werkzeuge aus der logischen und strukturellen Phase sind hier eher Hindernis als Hilfe.

5. ⚖️ Kritikalität: der Rand des Chaos

Warum funktioniert das? Kauffman beschreibt Kritikalität. Jedes komplexe System hat eine Zahl n von Knoten und k von Verbindungen. Sind beide zu klein, ist das System extrem verletzlich: Fällt ein Teil aus, stirbt das Ganze. In der Softwarewelt heisst das Monolith. Die übliche Reaktion ist, n und k massiv zu erhöhen, das nennen wir dann Microservices. Aber zu hohe n und k bringen unerwartete Attraktoren (Kauffmans Bild: Krebs) und irgendwann kollabiert das System unter dem Aufwand, sich selbst zu verwalten.

Dazwischen liegt eine magische Zone: gross genug, um sich mit dem Umfeld zu verändern, aber nicht so gross, dass es zusammenbricht. Das ist die Kritikalität, später populär als «edge of chaos». Stressen heisst nichts anderes, als die naive Architektur Schritt für Schritt in diese Zone zu schieben. Dort beginnt sie, Dinge zu überleben, die nicht in der Spezifikation standen.

Daraus folgt eine fundamentale Verschiebung: Das Ziel eines Programmierers ist Korrektheit, der Code muss stimmen, die Tests müssen grün sein. Das Ziel eines Architekten kann nicht Korrektheit sein, weil er mit einer offenen, komplexen Zukunft arbeitet. Das Ziel der Architektur ist Kritikalität. Genau dieser Sprung von Korrektheit zu Kritikalität ist es, an dem viele Entwickler auf dem Weg zum Architekten scheitern.

6. 🕸️ Contagion-Analyse: versteckte Kopplung sichtbar machen

Wenn man viele Residuen zusammenfügt, droht eine neue Gefahr: Sie beeinflussen sich gegenseitig. Ein Stressor trifft zwei Teile des Systems, die man für unabhängig hielt. In der Netzwerkwissenschaft impliziert eine solche Dreiecksbeziehung, dass diese beiden Teile gekoppelt sind. In Software heisst das Kopplung, und zwar meist die unsichtbare, nicht-funktionale Kopplung, über die Ansteckung («Contagion») durch das System läuft.

flowchart TD
    S(["Stressor"]) --> C["Komponente C"]
    S --> G["Komponente G"]
    C -. "implizierte, versteckte<br/>Kopplung" .- G

Das Werkzeug dagegen ist eine Inzidenzmatrix: Stressoren in den Zeilen, Komponenten in den Spalten. Trifft ein Stressor eine Komponente, gibt es eine 1, sonst eine 0. Daraus liest man mehrere Dinge ab:

  • Zeilensumme grösser als zwei deutet auf versteckte Kopplung hin, die man untersuchen sollte.
  • Welche Stressoren am härtesten treffen, ergibt klare Argumente für Redundanz.
  • Welche Komponente am häufigsten getroffen wird, ist ein Hinweis auf Verletzung des Single-Responsibility-Prinzips: Sie macht zu viel und sollte geschützt oder aufgeteilt werden.
  • Komponenten mit identischem Stress-Muster leben und sterben gemeinsam und gehören in dieselbe Komponentengrenze.

Die Idee stammt aus der Design Structure Matrix, mit der das MIT Flugzeuge und Raumfahrzeuge entwirft. Sie beantwortet endlich nachvollziehbar die Frage, warum es genau drei Komponenten sein sollen und nicht zwei oder vier.

Übertragen auf das laufende Webshop-Beispiel: Stresst man «Zahlungsanbieter ist offline», «Lagerbestand stimmt nicht», «Versanddienst streikt» gegen einen Monolithen, zeigt die Matrix schnell, welche scheinbar getrennten Module in Wahrheit zusammenhängen, und wo man trennen oder absichern muss.

7. 🔬 Trainiert, nicht entworfen

Was die Residualitätstheorie von blossen Vibes unterscheidet, ist ihr wissenschaftlicher Anspruch. O’Reilly hat sie in einem PhD-Programm geprüft. Der Aufbau erinnert an Machine Learning: Es gibt ein Trainings-Set und ein Test-Set von Stressoren.

Man nimmt eine naive Architektur, wendet die Trainings-Stressoren an und erhält die residuale Architektur. Dann wirft man ein zweites, unbekanntes Set von Stressoren auf beide. Die naive Architektur überlebt X davon, die residuale Y. Der Residual-Index ist (Y − X) / S (mit S als Gesamtzahl der Stressoren), ein Wert zwischen minus eins und eins. Ist er grösser als null, überlebt die residuale Architektur unbekannten Stress besser. Zum ersten Mal hat ein Architekt einen Beleg, dass seine Arbeit etwas gebracht hat.

Daraus folgt der schönste Satz der ganzen Theorie: Architekturen in komplexen Umgebungen müssen trainiert, nicht entworfen werden. Das Experiment wurde mit mehreren Teams über dasselbe Projekt wiederholt und zeigt das Ergebnis statistisch signifikant.

8. ✅ Fazit

Residualitätstheorie ist kein Ersatz für bestehende Methoden, sondern eine andere Brille. Sie nimmt ernst, dass das Geschäftsumfeld komplex ist, nutzt Attraktoren als Schnittstelle, stresst die Architektur in Richtung Kritikalität und macht versteckte Kopplung über Inzidenzmatrizen sichtbar. Das Resultat ist Off-Spec-Survival: Robustheit gegen Dinge, die niemand kommen sah. Für mein eigenes Denken ist das ein gutes Gegengift gegen die Illusion, man könne die Zukunft per Requirements-Liste einfangen.

📚 Weiterführende Links & Quellen