Skip to content
Software Architecture Guide

Architecture Decay

Explanation

Section titled “Explanation”

Every system has an intended architecture: the structure its designers decided on. Over time, the code that actually gets built can differ from that plan. This gap is called architecture erosion. It is the divergence between the intended and the implemented architecture.

Even systems that start with a well-defined architecture erode. The paper on the Big Ball of Mud (see Big Ball of Mud) describes this. It notes that the effect was named architectural erosion, or “midlife generality loss.”

Why it happens

  • Piecemeal growth means a system grows in small steps. Its biggest risk is that it gradually wears down the overall structure.
  • Technical debt is a major cause. Technical debt means shortcuts taken now that must be paid back later (see Technical Debt). The more debt piles up, the more the architecture erodes.
  • Software tends toward disorder, which the source calls entropy. Fighting it takes invested effort.

How to counter it

  • Refactoring is the way to arrest entropy in software. Refactoring means improving the internal structure of code without changing what it does (see Refactoring).
  • Fine-grained iteration, meaning many small steps, helps avoid catastrophic upheaval.
  • Architecture restructuring is a drastic but effective way to control erosion.

How to detect it

Teams find erosion by looking for architectural violations in the implementation. Comparing the code against the intended design in this way is often called conformance checking.

Example

Section titled “Example”

A team designs a system in three layers. Over two years, developers add quick fixes. Some of them reach around a layer to save time. Each shortcut works, but the code now differs from the design. A conformance check finds these violations. The team then refactors them away in small steps.

Trade-offs

Section titled “Trade-offs”

Refactoring costs effort, because countering entropy needs invested energy. Restructuring the architecture works well but is drastic. Small, frequent steps avoid the need for upheaval, but they demand steady effort.

Checks

Section titled “Checks”
  • The document states how divergence between the intended and implemented architecture is detected, for example through conformance checking.
  • Known technical debt that may erode the architecture is listed.
  • The document names refactoring as the way the team counters structural decay.
Section titled “Related”

Sources

Section titled “Sources”