Skip to content
Software Architecture Guide

Implicit Architecture

Explanation

Section titled “Explanation”

Every software system has an architecture. This is true whether or not the team thinks about it. Architecture is not something you add by writing a document. It is already in the system.

When a team does not choose its architecture on purpose, the result is an implicit architecture. It exists, but nobody planned it or wrote it down. Such a system tends to collect heavy technical debt. Technical debt means shortcuts and flaws that make later changes harder. See the article Technical Debt.

Why it matters

One common view treats architecture as “the important stuff”, whatever that turns out to be in a given system. A poor architecture adds to cruft. Cruft is messy, hard-to-follow code. It makes software harder to understand and change. High internal quality, in turn, helps a team deliver faster.

Intended versus implemented

The architecture a team intends can differ from the one in the code. This gap is called architecture erosion. It happens when the implementation deviates from the intended design and harms quality and evolution.

Such drift is hard to avoid, because architectures change as systems evolve. Keeping documentation in step with the code is slow and error-prone.

Finding the architecture again

Understanding the architecture is vital for maintaining large systems. When no up-to-date description exists, people must work it out from the implementation. Many automated recovery techniques exist to ease this work. They reduce the manual effort of tracking changes in the code.

Example

Section titled “Example”

A small team builds an online shop quickly. Nobody draws a design. Over two years, features are added wherever they fit.

A new developer asks how the parts fit together. No document answers it, and the original design was never written down. The shop still has an architecture, but it is implicit. The developer must read the code to find it. Each change is slow because its effects are unclear.

Trade-offs

Section titled “Trade-offs”

Writing down the architecture costs effort. Documentation also goes stale, because keeping it in step with a changing system is slow and error-prone. Automatic recovery from code can help, but it does not replace a deliberate design.

Checks

Section titled “Checks”
  • The document states the intended architecture, so it can be compared with the implemented one.
  • The document records known gaps between intended and implemented architecture as risks or technical debt.
  • There is a process or tool to keep the architecture description in step with code changes.
Section titled “Related”

Sources

Section titled “Sources”