Growth and Underinvestment

Beschreibung

Der Archetyp "Wachstum und Unterinvestition" (Growth and Underinvestment) ist der Firmen-Killer schlechthin im Cloud-Zeitalter. Ein Produkt oder System wächst rasend schnell. Irgendwann stößt dieses Wachstum an Kapazitätsgrenzen (System wird langsam, Bugs häufen sich). Die völlig logische kybernetische Antwort wäre: Massiv in die Systemkapazität investieren (Refactoring, bessere Server, tiefes Onboarding). Doch das Management scheut die Kosten, wartet "erstmal ab", oder investiert viel zu spät. Da die Leistung schlecht bleibt, springen Kunden ab, das Wachstum stoppt und sinkt. Das Management sieht die sinkenden Zahlen und fühlt sich im Nachhinein bestätigt: "Gut, dass wir nicht so viel investiert haben, das Wachstum ist ja zurückgegangen!". Ein selbstmörderischer Fehlschluss.

Feedback Loops

Die Engine besteht aus dem klassischen *Limits to Growth* Raster. Ein *Reinforcing Loop* befeuert den Erfolg. Dieser weckt aber zügig einen *Balancing Loop* (Performance-Limits drosseln den Erfolg ab). Die Besonderheit liegt im dritten Ast: Einem weiteren *Verzögerungs-Loop*, der eigentlich die physikalische Grenze erweitern sollte (Investitionen in Hardware/Architektur). Aber weil das Management Signale fehlinterpretiert oder das Delay in der Aufrüstung zu groß ist (es dauert 9 Monate, einen Monolithen zu zersägen), wirkt dieser dritte Loop nicht rechtzeitig. Die Leistungsabnahme tötet den Wachstums-Motor final ab.

Architekturbeispiel

Eine Firma baut ein riesiges Data-Warehouse für ML-Training. Die Architektur ist simpel gestrickt und wächst phänomenal (es läuft erfolgreich). Je mehr Abteilungen das DWH nutzen, desto schlechter werden die Latenzen der Queries (das Performance-Limit kickt ein). Anstatt ein massives Re-Architecture Budget freizugeben (Migration auf eine echte Streaming-Architektur oder Data Mesh), befiehlt das Management "erstmal nur das Nötigste zu patchen". Latenzen bleiben schlecht. Daraufhin migrieren die Fachabteilungen frustriert auf ihre eigenen Excel- und lokalen SQL-Spiegel (Nutzer wandern ab). Die Nutzung des DWH sinkt. Das DWH-Team verliert seine Budgets, weil "die Plattform ja eh weniger genutzt wird".

Organisationsbeispiel

Ein aufstrebendes Startup skaliert die Feature-Teams immens (mehr Devs = stärkere Feature-Factory). Was sie versäumen, ist die *Unterinvestition* in Developer-Experience (DX) und CI/CD-Pipelines (die unsichtbare Kapazität). Das Management will Budgets nur für "sichtbare Features", nicht für unsichtbare "Plattform-Hygiene" ausgeben. Irgendwann explodieren die Build-Zeiten, Pull-Requests liegen Wochen rum, Entwickler weichen frustriert aus oder kündigen (Das Wachstum kollabiert). Das Management schiebt den Misserfolg auf "schlechte Arbeitsmoral", Thesen wie "wir dürfen Plattform nicht vernachlässigen" werden lachend abgelehnt, weil die Metriken ja schon im Sturzflug sind.

Diagnosefragen

1.Deuten wir gerade einen Rückgang von Nutzungskennzahlen fälschlicherweise als "Weniger Nachfrage am Markt", obwohl wir eigentlich durch schlechte Performance und furchtbare Stabilität selbst die Kunden verjagt haben?

2.Haben wir eklatante Delays (Verzögerungen) beim Freigeben von Budget für Basis-Infrastruktur-Umbauten?

3.Reden wir uns ein, dass wir die Architektur erst refactoren "wenn wir groß und profitabel sind", ignorieren aber, dass wir ohne das Refactoring niemals groß und profitabel werden können?

Diagramm

Wie du das Muster im Alltag erkennst

Diese Dysfunktion zeigt schonungslos, dass "Visionen" allein ein System nicht retten. Wachstum erfordert vorausschauende Weichenstellung in fundamentale Kapazität (Architektur-Erweiterung), *lange bevor* das operative System qualmt. In IT-Projekten ist das klassische Under-Investment das Versäumnis, früh in Automatisierung, Observability und Entkopplung zu investieren. Wenn die Architektur-Hölle da ist, hast du nicht mehr die organisatorische Bandbreite (Kapazität), um den Hebel umzuwerfen.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

*Growth and Underinvestment* ist de facto die detailliertere, wirtschaftlich-schmerzhafte Erweiterung des reinen *Limits to Growth* Archetyps. Es beleuchtet vollauf den menschlichen "Ausweich-Reflex" (das Nicht-Erkennen, dass man sich aus dem Loch herausinvestieren müsste).

Wie du vom Muster zur Reaktion kommst

Wenn du die Warnzeichen liest (Qualität sinkt, Metriken brechen leicht ein, Frust steigt), existiert nur eine legitime Handlungsoption: Du musst exzellente Warn-Metriken etablieren und *auf Verdacht in die Struktur investieren*, auch wenn die Kurve schon stagniert. Für Architekten bedeutet das: Verteidige das "Plattform-Engineering-Budget" mit Zähnen und Klauen. Plattformarbeit ist kein Luxus-Abfallprodukt, sie ist die einzige physische Kapazitätserweiterung, die zukünftiges Wachstum überhaupt erst ermöglicht.

Erste nächste Schritte

Verbinde Kapazitätsindikatoren starr mit Geschäftssignalen. Wenn die Nutzerzahl M übersteigt, blockiert das Architekturboard im Master-Review automatisch jedes geplante Feature X, biss Architektur-Investment Y sichergestellt ist.

Woran du das Muster sicher erkennst

Tappen wir in die Falle, den Misserfolg eines schlecht gewarteten internen Tools darauf zu schieben, "dass es ja eh keiner haben wollte", anstatt zuzugeben, dass es durch unser Under-Investment schlichtweg unbenutzbar langsam wurde?

Quellen

The Systems Thinker: Growth and Underinvestment

Peter Senge — The Fifth Discipline, Kap. 6

Daniel Kim — Systems Archetypes at a Glance