Eroding Goals

Beschreibung

Der Archetyp "Eroding Goals" (Erodierende Ziele, oft deckungsgleich mit *Drifting Goals*) legt den Fokus massiv auf das Wegschmelzen langfristiger Visionen. Er tritt meistens dann auf, wenn die harte Arbeit, ein fundamentale Problem in der IT-Landschaft zu fixen (wie das Zerschlagen eines Legacy Monolithen), zu viele Jahre dauern würde. Das Management oder die Architektur-Truppe hält diese Daueranspannung psychologisch nicht aus. Statt das Mammut-Projekt weiter voranzutreiben, lässt man die Vision des "Golden State" still und leise zu einem "Good Enough State" verwässern, der die kaputte Realität de facto zementiert.

Feedback Loops

Das Verhalten entsteht in einem *Balancing Loop* (Lücke zwischen Ideal und Realität versuchen zu schließen). Die korrigierende Maßnahme (Refactoring der Struktur) hat allerdings ein so brutales *Delay* (es zieht sich über Monate) oder wird durch akuten Budgetdruck behindert, dass die Lücke ewig offen bleibt. Diese kognitive Dissonanz – das Gefühl, permanent zu versagen – ist für Entwickler toxisch. Die menschliche Psyche schließt die Lücke sofort (Zero Delay), indem der *zweite Balancing Loop* ausgelöst wird: Wir erklären die dreckige Realität einfach zum neuen offiziellen Architekturstandard.

Architekturbeispiel

Eine Bank startet eine zweijährige, ehrgeizige Initiative zur Einführung einer strikten hexagonalen Architektur in allen Backend-Diensten ("Ports & Adapters"). Nach sechs Monaten stellen die Feature-Teams fest, das diese extrem harte Trennung für ihre simplen CRUD-Befehle massiv Zeit frisst. Der Architektur-Ausschuss weicht leicht ab: "Okay, für Lese-Zugriffe dürft ihr direkt auf die DB greifen." (Das Ziel erodiert das erste Mal). Im 12. Monat stoppt ein Team komplett: "Das ist eine kritische, hoch-komplexe Logik, hier umgehen wir das komplett." Der Architektur-Ausschuss segnet ab (Zweite Erosion). Am Ende der zwei Jahre ist die Architektur zersplitterter und kaputter als zuvor, aber die Präsentation feiert die "erfolgreiche Flexibilisierung des Systems".

Organisationsbeispiel

Ein DevOps-Transformation-Programm beginnt mit dem hehren Ziel: "You build it, you run it." Teams sollen autonom 24/7 Rufbereitschaft machen. Die Teams protestieren laut, dass sie noch keine echten CI/CD Automatisierungen haben. Anstatt den harten Weg zu gehen und in monatelange CI/CD Optimierung zu investieren (Ursachenbekämpfung), bröckelt das Management ein (Symptom-Befreiung): "Okay, wir behalten ein zentrales, dediziertes Ops-Nachtschicht-Team, das nur im Notfall eingreift." Das Ziel der Entwickler-Responsibility wurde weg-erodiert, und DevOps verkommt zu einem reinen Buzzword, unter dem das furchtbare alte Verhalten einfach weiterläuft.

Diagnosefragen

1.Haben wir großartige Architekturziele als pompöse Leuchtturm-Projekte gestartet, die nun schweigend im Sand verlaufen und als "Teilerfolg" verkauft werden sollen?

2.Wurden klare Ausnahmeregeln (Exception handling für Standards) zu den eigentlichen, neuen Architekturstandards (Neue Baseline) in unserem Unternehmen?

3.Lässt unser C-Level / Tech-Lead zu, dass Teams die Messlatte immer dann tiefer hängen, wenn das Team "zu laut meckert", anstatt ihnen wirklich beim Aufräumen zu helfen?

Diagramm

Wie du das Muster im Alltag erkennst

Eroding Goals entsteht nie aus schlechtem Willen; es entsteht aus reiner Erschöpfung. Technologische Transformationen fordern einen unfassbaren Tribut von Agenten, die oft parallel ihr Tagesgeschäft (Features) bedienen müssen. Das Verwaschen der Vision ist reiner Überlebensinstinkt. Wirkliche Architekten müssen hierbei als unangenehmer Nord-Stern agieren ("Die Bad Cops der Vision"). Man darf Taktiken ändern (wie wir dahin kommen), aber man darf niemals zulassen, dass die Strategie / das Qualitätsziel durch Bequemlichkeit verwässert wird.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

*Eroding Goals* fungiert in der Systemik oft engmaschig gekoppelt mit *Fixes that Fail*: Weil das anspruchsvolle Qualitätsziel erodiert, wirft man kurzfristige Pflaster (Workarounds) in die Landschaft, die das eigentliche Problem über die Zeit katastrophal verschlimmern.

Wie du vom Muster zur Reaktion kommst

Verknüpfe architektonische Visionen mit externen Imperativen (Kundenschmerz-Fokus) statt internen Eitelkeiten. Wenn die Uptime-Ziele erodieren, beende die internen Metrik-Meetings und schleife Entwickler in die externen Call-Center zu den extrem wütenden Kunden. Der externe Reality-Check wirkt wie ein harter Reset auf das System und sorgt dafür, dass das "eingelullte" weiche Ziel brutal zerrissen wird, und das korrekte, harte Ziel wieder seine Berechtigung erfährt.

Erste nächste Schritte

"Hold the Line". Architekturprinzipien sind keine reinen Leitfäden, sie müssen weh tun, ansonsten verändern sie keine Systeme ("A principle isn’t a principle until it costs you money." - Bill Bernbach).

Woran du das Muster sicher erkennst

Übersteht unsere Architektur-Vision den Lackmus-Test, dass wir notfalls das Go-Live eines Riesen-Features verschieben, wenn es diesen Kern-Standard reißt?

Quellen

The Systems Thinker: Drifting Goals

Peter Senge — The Fifth Discipline, Kap. 6

Daniel Kim — Systems Archetypes at a Glance