System Dynamics Simulation

Systemzweck

In hochkomplexen Systemen bewirken Interventionen oft kurzfristig genau das Gegenteil ihres langfristigen Ziels ("Worse Before Better"). Wenn ein Architekt einen massiven Refactoring-Stopp anordnet, steigt die Feature-Velocity heute (Kurven-Hoch), aber in 18 Monaten explodieren die Support-Tickets, und die Feature-Velocity fällt auf Null (Kurven-Absturz). *System Dynamics Simulation* existiert, um dieses gefährliche "Delay" (Zeitverzögerung) sichtbar zu machen. Es bewahrt Architekten davor, Entscheidungen zu treffen, die zwar das aktuelle Quartal retten, aber das Unternehmen im übernächsten Quartal physikalisch ruinieren.

Mechanik der Simulation

Simulationen entziehen dem Bauchgefühl seine Macht. Du definierst das System als mathematisches Netzwerk und injizierst "Shocks" (Schocks):

1.Der Input-Schock: "Was passiert, wenn wir die Anzahl der Junioren im Team schlagartig verdoppeln?"

2.Die Non-Lineare Berechnung: Die Simulation berechnet das "Brook's Law" (Junioren binden Seniors für Training, Bugs steigen, Review-Zeiten steigen expotentiell).

3.Der Plot: Das Tool spuckt eine Kurve aus, in der die Team-Produktivität für die nächsten 9 Monate *sinkt*, bevor sie wieder das alte Level erreicht (Der "J-Curve" Effekt).

Architektur-Einsatz

Szenario: Das Management fordert den Bau eines gewaltigen "Enterprise Service Bus" (ESB), um alle Anwendungen zu integrieren. Der Lead Architect zweifelt ("Das wird ein zentraler Flaschenhals"). Er baut ein System Dynamics Modell: 100 autonome Microservices senden Anfragen an den ESB-Node. Die Simulation beweist sofort: Ab einer Systemgröße von N=30 erstickt das zentrale ESB-Team an Integrations-Tickets. Der Architekt geht nicht mit Meinungen zum CIO-Meeting, sondern mit einem harten mathematischen Beweisbild des unvermeidlichen Kausalkollapses aus der Simulation.

Grenzen und Gefahren

"Die Illusion der Allmächtigkeit". Wenn ein Architekt ein 400-Knoten-Modell baut, verwechselt er irgendwann das Modell mit der Realität (*The Map is not the Territory*). Ein exzellentes System Dynamics Modell enthält maximal 10 Kern-Variablen. Sobald du versuchst, den Kaffeekonsum der Mitarbeiter, die Wetterlage in Berlin und den Börsenkurs von AWS in die Formel der "Service-Stabilität" einzurechnen, entwertest du das Modell. Modelle sind nicht da, um Wahrsagerei (Präzision) zu betreiben. Sie sind da, um fatale Denkfehler (Trend-Aussagen) in Architekturentwürfen zu zerstören.

Diagramm

Abgrenzung

*Simulation Sandboxes* (z.B. Chaos Monkey) jagen physische Fehler in laufende, reale Server. *System Dynamics Simulation* ist Trockenübung auf abstrakter Ebene ("Badewannen-Mathematik"). Es findet vor der ersten Zeile Code statt und testet die Dynamik der Organisations- und Bauökonomie, nicht des Java-Codes.

Entscheidungs- und Praxisleitfaden

Simalution ist eine Waffe für hochriskante, multi-millionen-Euro "One-Way Door" Entscheidungen. (z.B: "Trennen wir den Monolithen auf oder nicht?"). Benutze Simulation niemals für triviale Entscheidungen ("Nutzen wir React oder Vue?"). Beauftrage keine externen Consultants, um dir ein Modell zu bauen, das du nicht selbst mathematisch durchdringen kannst. Wenn das Modell "Blackbox" für dich ist, kannst du deine Architektur damit nicht vor dem CEO verteidigen.

Quellen

John Sterman — Business Dynamics (McGraw-Hill, 2000)

Jay Forrester — Industrial Dynamics (MIT Press, 1961)

Wikipedia: System Dynamics