# Implicit Architecture

**In short:** Every system has an architecture, even if nobody planned, documented or understood it. An unplanned architecture tends to pile up technical debt and makes the system harder to maintain.

## 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

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

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

- 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.

## Related

- [Accidental Architecture](https://arc.fuet.ch/concepts/fundamentals/unsystematic-accidental-architecture.md)
- [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md)
- [Software Architecture](https://arc.fuet.ch/concepts/fundamentals/software-architecture.md)
- [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md)
- [Motivation for Architecture Documentation](https://arc.fuet.ch/concepts/documentation/motivation-for-architecture-documentation.md)
- [Architecturally Evident Coding Style](https://arc.fuet.ch/concepts/fundamentals/architecturally-evident-coding-style.md)

## Sources

- [Is your software architecture explicit? - Crisp’s Blog](https://blog.crisp.se/2012/12/18/mikaelbrodd/is-your-software-architecture-explicit) — blog.crisp.se, accessed 2026-11-09
- [Software Architecture Guide](https://martinfowler.com/architecture/) — martinfowler.com, accessed 2026-11-09
- [[2112.10934] Understanding Software Architecture Erosion: A Systematic Mapping Study](https://arxiv.org/abs/2112.10934) — arxiv.org, accessed 2026-11-09
- [[2311.04643] Software Architecture Recovery with Information Fusion](https://arxiv.org/abs/2311.04643) — arxiv.org, accessed 2026-11-09