Eroding Goals

Description

The archetype "Eroding Goals", closely related to Drifting Goals, describes the gradual abandonment of long-term target states. It typically appears when the structural solution to a fundamental problem — such as replacing a legacy monolith — would take several years. That sustained tension is hard for management and architecture leads to endure. Instead of pushing the long-term effort forward, the original target state is quietly watered down to a "good enough" state that effectively cements the existing structure.

Feedback Loops

The behavior emerges from a balancing loop that tries to close the gap between ideal and reality. But the corrective action, structural refactoring, has such a deliberate delay, or is blocked by budget pressure, that the gap remains open for a long time. That cognitive dissonance, the feeling of always failing, is harmful for developers. Human psychology closes the gap instantly through a second balancing loop: we simply declare the messy reality to be the new official architecture standard.

Architecture Example

A bank launches a two-year initiative to introduce strict hexagonal architecture in all backend services. After six months, feature teams notice that the hard separation costs too much time for simple CRUD flows. The architecture committee softens the rule slightly: for read access, direct database calls are allowed. The goal erodes for the first time. By month twelve one team opts out completely: this critical, highly complex logic will bypass the model entirely. The architecture committee approves it. At the end of the two years the architecture is more fragmented and broken than before, but the presentation still celebrates the successful flexibilization of the system.

Organizational Example

A DevOps transformation program starts with the noble goal: you build it, you run it. Teams should own twenty-four-seven on-call responsibility. The teams protest that they still lack real CI/CD automation. Instead of investing for months in CI/CD improvements, the painful root-cause path, management gives way. It keeps a central dedicated night-shift Ops team that will step in during emergencies. The goal of developer responsibility erodes away, and DevOps degrades into a buzzword under which the old behavior simply continues.

Diagnostic Questions

1.Have we launched grand architecture goals as lighthouse projects that are now quietly fading into the sand and getting sold as partial successes?

2.Have clear exception rules become the real new architecture standard in our company?

3.Does our C-level or tech leadership allow teams to lower the bar whenever they complain loudly enough instead of actually helping them clean things up?

Diagram

How to Recognize the Pattern in Daily Work

Eroding Goals rarely comes from bad intent — it grows out of exhaustion. Technological transformations demand a lot from people who still have to deliver day-to-day work in parallel. Watering down the target state is then an understandable relief reaction. Architects play an uncomfortable role here: they keep the long-term quality goal visible even when that is unpopular in the short term. Tactics may change — the path to the goal is negotiable. The goal itself, however, should only be lowered through an explicit, accountable decision, not out of convenience.

What Distinguishes the Pattern from Similar Dynamics

Eroding Goals and Drifting Goals describe the same basic mechanism of lowering targets, but with different emphasis: Drifting Goals focuses on operational standards that gradually adapt to current performance. Eroding Goals focuses on long-term target states and strategies that are given up piece by piece under sustained tension. In addition, Eroding Goals is often tightly coupled with Fixes That Fail: because the ambitious quality target erodes, short-term workarounds get deployed that make the real problem worse over time.

How to Move from Pattern to Response

Tie architecture target states to external impact (customer value) rather than internal metrics. If uptime goals erode, replace internal metric meetings with direct contact between developers and affected customers. This external reality check acts like a reset: the quietly lowered goal becomes visible, and the original target regains its legitimacy.

First Next Steps

Hold the line. Architecture principles are not mere guidelines. They must cost something, otherwise they do not change systems.

How to Recognize the Pattern with Confidence

Would our architecture vision survive the litmus test of delaying the go-live of a major feature if that feature violates the core standard?

Sources

The Systems Thinker: Drifting Goals

Peter Senge - The Fifth Discipline, ch. 6

Daniel Kim - Systems Archetypes at a Glance