System Dynamics Simulation

Systemzweck

In hochkomplexen Systemen bewirken Interventionen oft kurzfristig genau das Gegenteil ihres langfristigen Ziels ("Worse Before Better"). Wenn ein Architekt einen deutlichen Refactoring-Stopp anordnet, steigt die Feature-Velocity heute (Kurven-Hoch), aber in 18 Monaten stark ansteigen die Support-Tickets, und die Feature-Velocity fällt auf Null (Kurven-Ausfall). System Dynamics Simulation existiert, um dieses problematische "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 des Werkzeugs

Simulationen machen Bauchgefühl überprüfbar. Du definierst das System als mathematisches Netzwerk und modellierst Belastungen (Belastungen):

1.Der Input-Szenario: "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 klaren 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 beeinträchtigen.

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 nicht 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