Core Idea
Architecture by Archaeology is an anti-pattern where all decisions are justified through historical precedent—“we’ve always done it this way”—rather than current context and trade-off analysis. The original reasoning is lost; only the artifact remains.
Core Problem
When Architecture-Decision-Records are absent, systems accumulate decisions whose rationale has been forgotten. New architects and developers inherit a system they must reverse-engineer to understand why it was built a particular way. They’re forced to “archaeologically” infer intent from code and structure rather than documented reasoning.
This creates four compounding problems:
- Loss of original reasoning - Without documented ADRs, the “why” disappears; only “what” remains
- Ignoring contextual change - Decisions made under different constraints (small team, different tech landscape, lower traffic) persist unchanged even when conditions have shifted
- Resistance to evolution - New architectural approaches are rejected simply because they differ from historical practice
- Accumulating technical debt - Rather than evolving the architecture, teams layer workarounds over aging foundations
How It Manifests
Common symptoms:
- Answers to “why does this work this way?” are: “no one knows” or “that’s how it’s always been”
- Refactoring attempts are blocked with “if it ain’t broke, don’t fix it” without examining whether the current approach still fits
- Design reviews spend more time interpreting existing code than evaluating the new decision
- Teams are afraid to change components because they don’t understand the hidden dependencies
Connection to Related Anti-Patterns
Architecture by Archaeology frequently co-occurs with the Frozen Caveman Anti-pattern and the Ivory Tower Architect:
- Ivory Tower + Archaeology - An isolated architect doesn’t document decisions, leaving future teams to infer intent
- Frozen Caveman + Archaeology - An architect frozen in the past naturally justifies current decisions through that historical lens
- All three represent failure to evolve - in isolation, in knowledge, and in architectural reasoning
The antidote is collaborative, iterative architecture with transparent decision-making and continuous re-evaluation of assumptions, formalized through ADRs.
Related Concepts
- Architecture-Decision-Records - The primary tool that prevents Architecture by Archaeology by capturing the “why”
- Why is more important than how. - Archaeology occurs precisely because the “why” was never documented
- Frozen Caveman Anti-pattern - Co-occurs with Archaeology; stale expertise leads to defending undocumented decisions
- Ivory Tower Architect - Isolation produces undocumented decisions that future teams must archaeologically decode
Sources
-
Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 19: Architecture Decisions — anti-patterns including Architecture by Archaeology
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
-
Nygard, Michael T. (2007). Release It!: Design and Deploy Production-Ready Software. Pragmatic Bookshelf. ISBN: 978-0-9787392-1-8.
- Chapter 1: Living in Production — how undocumented decisions become invisible constraints
- Available: https://pragprog.com/titles/mnee2/release-it-second-edition/
-
Fowler, Martin (2003). “Who Needs an Architect?” IEEE Software, Vol. 20, No. 5, pp. 11–13.
- How architecture decisions and their rationale must be preserved for effective evolution
- Available: https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Note
This note was researched and drafted with AI. How these notes are written →