Causal Loop Diagrams

Zweck

"Kausal-Schleifen-Diagramme" (Causal Loop Diagrams, CLD) sind die Landkarten der Systemtheorie. Anstatt Architektur-Dokumentation in langen, linearen Texten herunterzuschreiben, zwingen uns CLDs, die Welt in Nodes (Variablen) und Edges (Rückkopplungen) zu visualisieren. Sie entlarven den größten Fehler im Management: Das lineare Denken (A verursacht B). In der echten IT-Welt gibt es keine Linien, es gibt nur geschlossene Kreise: A verursacht B, B verstärkt C, und C wirkt zeitverzögert tödlich zurück auf A.

Einsatzkontext

Verwende Causal Loop Diagrams immer dann, wenn das "Pflaster" (ein Architektur-Fix) nicht mehr funktioniert. Jedes Mal, wenn ein Team meldet: "Wir optimieren diese Schnittstelle seit sechs Monaten, aber das Kernsystem wird einfach immer langsamer", holst du das CLD-Whiteboard raus. Das Problem ist nicht die Schnittstelle – das Problem ist das unsichtbare Netzwerk herum.

Schritt für Schritt

1.Das Thema benennen: Worüber reden wir? (z.B. "Die sinkende Code-Qualität").

2.Knoten (Nodes) sammeln: Finde die kritischen Variablen. Sie müssen messbar sein, auch weiche! (z.B. Test Coverage, Kognitive Last, Feature-Druck vom Management).

3.Pfeile (Links) ziehen: Verbinde die Knoten. Wenn A steigt, steigt dann auch B ("+" oder "S" für Same)? Oder sinkt B ("-" oder "O" für Opposite)?

4.Schleifen (Loops) identifizieren: Finde die geschlossenen Kreise. Sind sie sich selbst verstärkend (Reinforcing - "R") oder versuchen sie ein Limit zu halten (Balancing - "B")?

5.Delays markieren: Zeichne zwei parallele Striche (//) auf Kanten, wo Ursache und Wirkung zeitlich auseinanderklaffen. Dort verbergen sich 90% aller Krisen.

Beispiel

Ein Tribe will "Velocity" erhöhen. Das Management erhöht den Ticket-Druck (+). Das erzeugt bei den Entwicklern Zeit-Druck (+). Zeitdruck verringert die Zeit für Refactoring (-). Weniger Refactoring bedeutet mehr Technische Schulden (+). Mehr Technische Schulden bedeuten *zeitverzögert* (//) wesentlich mehr Bugs (+). Mehr Bugs zwingen die Entwickler in Kontext-Wechsel (+), was am Ende die reale Velocity im Team massiv zerstört (-). Das CLD beweist auf einem Blick: Das Management hat durch blindes Erhöhen von Ticket-Druck eine verstärkende Drossel-Schleife gestartet, die das genaue Gegenteil der Absicht erreicht.

Diagramm

Wie aus Diagnose Handlung wird

Die Magie eines CLD liegt nicht in der Analyse des Ist-Zustandes, sondern im Auffinden der sogenannten "Leverage Points" (Hebelpunkte). Eine 100-Knoten-Map ist wertlos. Ein gutes CLD reduziert die extreme Komplexität eines Microservice-Clusters auf 5-7 entscheidende Rückkopplungskreise. In der Architektur-Sitzung sucht das Team dann *den einen Pfeil*, den man im System künstlich kappen, umpolen oder im Delay verkürzen muss, um den gesamten Teufelskreis (wie eine Burnout-Spirale) umzukehren.

Wann diese Methode die richtige ist

CLDs sind eine *Diagnose-Technik*, mit der man *System-Archetypen* (die immer als fertige CLDs gezeichnet werden) am Whiteboard selbst zusammenpuzzelt. Sie enden exakt dort, wo *System Dynamics / Stock and Flow* Simulationen anfangen (CLDs sind nur qualitativ, sie rechnen nicht).

Wie du die Diagnose im Alltag einsetzt

Zwinge Product Owner und Stakeholder an das Whiteboard, *bevor* Architektur-Entscheidungen getroffen werden. Wenn der Produktchef sagt "Lasst uns die CI-Pipeline-Sicherheits-Checks abschalten, um schneller in Produktion zu kommen", lasse ihn die Konsequenzen selbst als CLD malen. Wenn er beim Malen durch den Pfeil für "Security Incident Wahrscheinlichkeit" und "Börsenkurs-Absturz-Delay" muss, löst sich die dumme initiale Idee oft in Sekundenbruchteilen von selbst in Luft auf. CLDs erzeugen Konsens durch radikale Visualisierung von Konsequenzen.

Erste Analyse-Schritte

Verwende strikte Benennungsregeln für Knoten: Variablen dürfen niemals Verben ("Testen" oder "Bauen") sein, sondern müssen Zustände ("Anzahl der Tests", "Höhe des Build-Staus") sein, die wachsen oder schrumpfen können. Ansonsten geht die Kybernetik der Links kaputt.

Woran du eine brauchbare Diagnose erkennst

Wird in der Post-Mortem Analyse eines großen Systemausfalls standardmäßig verlangt, den Fehler nicht im linearen "5-Whys" Format, sondern als kleines Causal-Loop Diagramm an die Wand zu zeichnen?

Quellen

The Systems Thinker: Causal Loop Construction — The Basics

Donella Meadows — Thinking in Systems, Kap. 1: Feedback Loops

John Sterman — Business Dynamics, Kap. 5–6 (McGraw-Hill, 2000)