Eroding Goals

Beschreibung

Der Archetyp "Eroding Goals" (Erodierende Ziele, eng verwandt mit Drifting Goals) beschreibt das schrittweise Aufgeben langfristiger Zielbilder. Er tritt typischerweise auf, wenn die strukturelle Lösung eines grundlegenden Problems — etwa die Ablösung eines Legacy-Monolithen — mehrere Jahre dauern würde. Diese Daueranspannung ist für Management und Architekturverantwortliche schwer auszuhalten. Statt das langfristige Vorhaben weiter voranzutreiben, wird das ursprüngliche Zielbild still zu einem "Good Enough"-Zustand verwässert, der die bestehende Struktur faktisch 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 deutliches 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 schädlich. Die menschliche Psyche schließt die Lücke sofort (Zero Delay), indem der zweite Balancing Loop ausgelöst wird: Wir erklären die unbefriedigende Realität einfach zum neuen offiziellen Architekturstandard.

Architekturbeispiel

Eine Bank startet eine zweijährige Initiative zur Einführung einer strikten hexagonalen Architektur in allen Backend-Diensten ("Ports & Adapters"). Nach sechs Monaten stellen die Feature-Teams fest, dass die strenge Trennung für einfache CRUD-Operationen spürbar Zeit kostet. Der Architektur-Ausschuss weicht die Regel leicht auf: "Für Lesezugriffe dürft ihr direkt auf die Datenbank zugreifen." Das Ziel erodiert das erste Mal. Im zwölften Monat steigt ein Team komplett aus: "Das ist kritische, hochkomplexe Logik — hier umgehen wir das Modell ganz." Der Architektur-Ausschuss segnet es ab, die zweite Erosion. Am Ende der zwei Jahre ist die Architektur fragmentierter als zuvor, aber die Abschlusspräsentation feiert die "erfolgreiche Flexibilisierung des Systems".

Organisationsbeispiel

Ein DevOps-Transformationsprogramm beginnt mit dem Ziel: "You build it, you run it." Teams sollen autonom die 24/7-Rufbereitschaft übernehmen. Die Teams wenden ein, dass ihnen dafür noch echte CI/CD-Automatisierung fehlt. Anstatt monatelang in CI/CD-Verbesserungen zu investieren (Ursachenbekämpfung), gibt das Management nach (Symptombehandlung): "Wir behalten ein zentrales Ops-Nachtschicht-Team, das im Notfall eingreift." Das Ziel der Entwicklerverantwortung erodiert, und DevOps verkommt zum Buzzword, unter dem das alte Verhalten weiterläuft.

Diagnosefragen

1.Haben wir Architekturziele als Leuchtturm-Projekte gestartet, die inzwischen still versanden 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 selten aus schlechtem Willen, sondern aus Erschöpfung. Technologische Transformationen fordern viel von Beteiligten, die parallel ihr Tagesgeschäft bedienen müssen. Das Verwässern des Zielbilds ist dann eine verständliche Entlastungsreaktion. Architekten kommt hier eine unbequeme Rolle zu: Sie halten das langfristige Qualitätsziel sichtbar, auch wenn das kurzfristig unpopulär ist. Taktiken dürfen sich ändern — der Weg zum Ziel ist verhandelbar. Das Ziel selbst darf aber nur durch eine explizite, verantwortete Entscheidung abgesenkt werden, nicht durch Bequemlichkeit.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Eroding Goals und Drifting Goals beschreiben dieselbe Grundmechanik des Zielabsenkens, setzen aber unterschiedliche Schwerpunkte: Drifting Goals fokussiert auf operative Standards, die sich schleichend an die aktuelle Leistung anpassen. Eroding Goals fokussiert auf langfristige Zielbilder und Strategien, die unter Daueranspannung Stück für Stück aufgegeben werden. Außerdem ist Eroding Goals oft eng mit Fixes that Fail gekoppelt: Weil das anspruchsvolle Qualitätsziel erodiert, werden kurzfristige Workarounds eingesetzt, die das eigentliche Problem über die Zeit verschlimmern.

Wie du vom Muster zur Reaktion kommst

Verknüpfe architektonische Zielbilder mit externer Wirkung (Kundennutzen) statt mit internen Kennzahlen. Wenn Uptime-Ziele erodieren, ersetze interne Metrik-Meetings durch direkten Kontakt der Entwickler mit betroffenen Kunden. Dieser externe Reality-Check wirkt wie ein Reset: Das schleichend abgesenkte Ziel wird sichtbar, und das ursprüngliche Ziel erhält seine Berechtigung zurück.

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