Shifting the Burden

Beschreibung

Der Archetyp "Verlagerung der Last" (Shifting the Burden) beschreibt eine Dynamik, in der ein System wiederholt symptomatisch entlastet wird, während die grundlegende Lösung vernachlässigt wird. Die schnelle Maßnahme liefert sofort sichtbare Wirkung, zum Beispiel mehr Hardware, ein Workaround oder ein externes Tool. Die strukturelle Lösung ist dagegen langsamer, aufwendiger und oft organisatorisch schwieriger. Je häufiger die Symptombehandlung genutzt wird, desto weniger Motivation und Fähigkeit bleibt für die grundlegende Lösung.

Feedback Loops

Das System ist in drei Schleifen gespalten. Die beiden oberen sind konkurrierende Balancing Loops.

Oberschleife (Symptombehandlung): Symptom taucht auf, Quick Fix drauf, Symptom weg. Ein sofortiger Belohnungs-Loop.

Unterschleife (Fundamentale Lösung): Symptom vorhanden, strukturelle Analyse durchführen (Verzögerung / Delay), Problem dauerhaft lösen. Diese Schleife wirkt langsamer, baut aber echte Problemlösungsfähigkeit auf.

Nebenwirkungsschleife (Nebenwirkung): Ein verdeckter Reinforcing Loop, der von der Symptombehandlung abgeht. Jeder Quick-Fix baut die Kapazität für die grundlegende Lösung weiter ab. Man verlernt das Handwerkszeug. Das System wird abhängig von dem Symptom-Fix.

Architekturbeispiel

Eine monolithische Datenbank wird bei komplexen JOINs langsam. Die grundlegende Lösung wäre ein Refactoring der Read-/Write-Modelle, zum Beispiel in Richtung CQRS. Das dauert Monate und erfordert tieferes Architekturverständnis. Stattdessen wird zunächst mehr CPU, RAM und ein Redis-Cache ergänzt. Die Latenz sinkt kurzfristig. Wenn das Problem später wieder auftritt, wird erneut Hardware ergänzt, während das Verständnis für das eigentliche Legacy-Datenmodell weiter abnimmt.

Organisationsbeispiel

Ein Projektmanager erkennt, dass Feature-Vorgaben viel zu ungenau an die Entwickler fließen (fehlende Domänen-Expertise). Dies verursacht hunderte Rework-Schleifen. Anstatt die Entwickler tiefgreifend in Domain-Driven-Design zu schulen (Fundamentale Lösung), baut das PM-Team den Quick-Fix auf: Sie stellen eine Armada von "Business Analysts", "Proxys" und "Translators" (Symptom-Fix) zwischen das Business und die Entwickler. Die Kommunikation läuft nun kurzfristig glatter. Langfristig koppeln sich die Entwickler emotional völlig vom Business ab (Kapazitätsverlust). Ohne die Übersetzer kann in dieser Organisation kein Feature mehr gebaut werden.

Diagnosefragen

1.Wo lösen wir Skalierungsprobleme nur noch reflexartig mit exzessiven Cloud-Geld-Ausgaben durch Autoscaler und Hardware-Over-Provisioning, weil sich niemand traut, den Code anzufassen?

2.Wo lagern wir zentrale Geschäftslogik in undurchsichtige Third-Party- oder Low-Code-Lösungen aus, deren Ausfall wir kaum selbst diagnostizieren könnten?

3.Welche "Provisorien und Workarounds" (z.B. manuelle Cronjob DB-Bereinigungen) laufen jetzt schon länger als 2 Jahre klaglos im Hintergrund, und niemand weiß mehr, wie man sie abschafft?

Diagramm

Wie du das Muster im Alltag erkennst

Die problematische Eigenschaft dieses Musters ist der Verlust von Resilienz. Die Symptombehandlung verdeckt, wie groß die eigentliche strukturelle Last geworden ist. Wenn der Quick Fix später nicht mehr ausreicht, tritt das ursprüngliche Problem mit deutlich größerem Umfang wieder auf. Eine Anwendung, die nur durch Workarounds stabil wirkt, ist deshalb kein Qualitätsmerkmal, sondern ein Hinweis auf verdeckte Folgelasten.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Gegensatz zu Fixes That Fail – wo der Fix eine aktive, problematische Nebenwirkung erzeugt, die das Kernproblem direkt deutlich schlechter triggert – arbeitet Shifting the Burden passiv. Der Fix selbst erzeugt keinen Fehler. Er macht das System lediglich unempfindlich für die Realität, indem er die einzige Chance auf echtes Umdenken reduziert (Das Sterben der Fundamentalkapazität).

Wie du vom Muster zur Reaktion kommst

Anerkenne die Menschlichkeit: Organisationen brauchen kurzfristige Fixes, um zu atmen. Das Entscheidende ist aber nicht die Abschaffung des Fix, sondern die Zwangskopplung: Jegliche Erlaubnis, einen Symptom-Fix im System zu deployen, muss budgetär sofort unlöslich an eine parallele Umsetzung der Fundamentallösung verknüpft werden. Du schaltest den Auto-Scaler der Datenbank erst ein paar Stufen hoch (Symptom) mit dem expliziten OK des CTOs, der im selben Meeting dem Team 4 Wochen Kapazitätsabbau genehmigt, um die Query-Optimierung auszuliefern.

Erste nächste Schritte

Mache klar, dass die Rückkehr zur grundlegenden Lösung zunächst langsamer wirken kann. Wenn Teams gewohnt sind, bei Druck Quality Assurance, Refactoring oder Testing zu reduzieren, braucht es verbindliche Leitplanken: nicht ohne Tests deployen, technische Folgelasten sichtbar machen und strukturelle Arbeit fest einplanen.

Woran du das Muster sicher erkennst

Trennen wir in Budgets und Ticketsystemen klar zwischen Symptombehandlung und strukturellem Engineering, damit sichtbar wird, wie viel Kapazität in echte Problemlösung fließt?

Quellen

The Systems Thinker: Shifting the Burden

Peter Senge — The Fifth Discipline, Kap. 6: Shifting the Burden

Wikipedia: System Archetypes — Shifting the Burden