# Architectural Decision Making Fallacies

**In short:** Architectural decisions often fail through familiar flawed reasoning, such as copying the crowd or leaning on one story. Each fallacy has a countermeasure. Naming them helps teams decide consciously and record decisions durably.

## Explanation

A fallacy is a flawed line of reasoning that feels convincing. The facts here describe several that weaken architectural decisions. Each comes with a countermeasure. Bias is partly unavoidable in big decisions. So the advice is to find decisions early, make them consciously, and record them durably as Architectural Decision Records (see "Architectural Decision Record").

**Blind flight.** The team decides without checking whether quality requirements are met. The countermeasure is to make the context and requirements explicit. Then compare them with earlier projects.

**Following the crowd.** The team assumes that what works for others will work for them. The countermeasure is to apply a recognized method or your own heuristics (rules of thumb) when moving from analysis to design. Use these instead of trends. Beat the street when needed.

**Anecdotal evidence.** One positive or negative example from tribal knowledge carries the whole argument. The countermeasure is to use SMART quality requirements as criteria that justify decisions in the records. This gives balanced judgments. See "SMART Requirements".

**Blending whole and part.** Someone judges a whole architectural style by one concept with a bad reputation. The countermeasure is divide and conquer. Be clear about the scope of each decision. Keep system-wide and local arguments in separate records.

**Abstraction aversion.** The team decides concepts, technologies, and products at the same time in one "mashup" record. The countermeasure is to move between abstract and concrete levels. Use separate but related records. A pattern choice and a product choice each get their own record.

**Golden hammer.** The countermeasure is to keep growing the architecture toolbox. Stay curious and try new practices, patterns, and tools.

**Ignoring the time dimension.** This fallacy assumes architectures do not drift or erode. The countermeasure is to make the expected lifecycle explicit, for example disposable or durable. Look back and think ahead.

## Example

A team must pick a messaging approach for a new order system. One member says, "A well-known company uses it, so we should too." That is following the crowd. Another recalls one failed project with a similar tool. That is anecdotal evidence. The architect instead writes down the context and the measurable quality targets, and states whether the system is disposable or durable. She then records the pattern choice in one decision record and the product choice in a second, related record.

## Trade-offs

Writing separate, related records and making context explicit takes effort. The facts also accept that some bias cannot be removed. The goal is conscious, documented decisions, not perfectly neutral ones.



## Checks

- Context and requirements are stated explicitly, so decisions can be compared with earlier projects.
- Decision records justify choices with SMART quality criteria, not single anecdotes.
- Each decision record states its scope and does not mix system-wide and local arguments.
- Pattern choices and technology or product choices are in separate but related records.
- The expected lifecycle of the system, such as disposable or durable, is stated.

## Related

- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)
- [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md)
- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md)
- [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)
- [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md)

## Sources

- [Seven Architectural Decision Making Fallacies (and Ways Around Them)](https://ozimmer.ch/practices/2025/09/01/ADMFallacies.html) — ozimmer.ch, accessed 2026-11-09