Shifting the Burden

Beschreibung

Der Archetyp "Verlagerung der Last" (Shifting the Burden) ist die klassische Metapher der Sucht (Addiction Model) in der Architektur. Ein System leidet. Die Akteure haben die Wahl zwischen einer extrem schmerzhaften, langwierigen Wurzelbehandlung (Fundamental Solution) und einer sofort wirkenden, bequemen Schmerztablette (Symptomatic Solution). Die Akteure entscheiden sich fast immer für die Tablette, weil sie sofortiges Feedback schenkt. Das teuflische an der Tablette: Je öfter man sie schluckt, desto tiefer sinkt die Motivation und Kapazität für die echte, fundamentale Lösung in den Keller.

Feedback Loops

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

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

Unterschleife (Fundamentale Lösung): Symptom da, langes Architekturstudium (Verzögerung / Delay), Problem gelöst. Ein harter, bestrafender Loop.

Tötungsschleife (Nebenwirkung): Ein verdeckter *Reinforcing Loop*, der von der Symptombehandlung abgeht. Jeder Quick-Fix baut die Kapazität für die fundamentale Lösung weiter ab. Man verlernt das Handwerkszeug. Das System wird süchtig nach dem Symptom-Fix.

Architekturbeispiel

Eine monolithische Datenbank verhält sich bei komplexen JOINs miserabel langsam (Symptom). Die fundamentale Lösung wäre ein Refactoring der read/write-Modelle (z.B. CQRS Theoreme) - das dauert Monate und erfordert abstraktes Denken. Stattdessen nutzt man den Quickfix: "Wir stellen einfach mehr CPU und RAM, sowie einen massiven Redis-Cache davor." Die Latenz ist sofort besser. Ein halbes Jahr später knallt es wieder. Anstatt nun endlich an das Design zu gehen, skaliert das Team die Hardware ins Astronomische (Suchtverhalten), weil sie mittlerweile vollkommen verlernt haben, wie ihr eigenes Legacy-Datenbank Modell überhaupt strukturell funktioniert.

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 Kern-Intelligenz des Systems (Business Logik) in undurchsichtige Third-Party "Low Code" Plug&Play SaaS Lösungen aus, deren Ausfall ein totales Blackbox-Desaster für uns wäre?

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 fatale Eigenschaft dieses Netzwerks ist das Ausbluten der Resilienz. Die Schmerzgrenze des Systems wird durch die Tabletten desensibilisiert. Wenn der Quick-Fix nach Jahren irgendwann ausfällt (weil Redis keine Terabytes mehr halten kann), dann schlägt die Fundamentallast mit einer solchen Wucht auf die Akteure auf, dass die Firma daran scheitern kann. Architekten müssen lernen, dass eine "perfekt verschminkte Applikation" kein Qualitätsmerkmal ist, sondern eine versteckte Atombombe (Toxic Debt).

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Gegensatz zu *Fixes That Fail* – wo der Fix eine aktive, giftige Nebenwirkung erzeugt, die das Kernproblem direkt viel schlimmer triggert – arbeitet *Shifting the Burden* passiv. Der Fix selbst rezeugt keinen Fehler. Er macht das System lediglich blind und taub für die Realität, indem er die einzige Chance auf echtes Umdenken abtötet (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 dir klar, dass das Entwöhnen einer "Sucht" unfassbar wehtut. Wenn Teams gewohnt sind, bei Stress alles an Quality Assurance, Refactoring oder Testing aus dem Fenster zu werfen (Symptom-Fix "Stressabbau durch Tempo"), musst du sie mit eiserner Hand durch das Delay der Unbequemlichkeit führen ("Nein, ihr deployt nicht ohne Tests, auch wenn wir die Deadline reißen").

Woran du das Muster sicher erkennst

Trennen wir in unseren IT-Budgets und Ticket-Systemen glasklar zwischen Ausgaben für Ops/Tape (Pflaster) und Engineering (Fundamentales Refactoring), um sehen zu können, wie stark unsere Schmerzmittel-Sucht bereits ist?

Quellen

The Systems Thinker: Shifting the Burden

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

Wikipedia: System Archetypes — Shifting the Burden