Seven Architectural Decision Making Fallacies (and Ways Around Them)

When making Architectural Decisions (ADs), things can go wrong. Biases and misconceptions are common. As a result, answers to “why this design?” questions, captured in AD Records (ADRs), may have little to do with the actual product requirements and project context. Project/product success is at risk in that case.

Let’s review some common fallacies and find ways to counter them.

Motivating example

You might have come across an AD whose ADR reads as this:

“We will build our online shop as a set of microservices because our cloud provider does that too in its infrastructure. They also provide a reference architecture for this variant and sub-style of SOA, a de-facto standard for modern enterprise applications.”

Sounds great, right? Well, there are at least three fallacies in action in it. Let’s find out which ones, and why avoiding them matters.

How to get it wrong: seven decision making fallacies

The following seven recipes for making ADs form a definite “not-to-do-list” (I moved examples and details to footnotes¹ to keep the list short and concise; countermeasures follow in a subsequent list):

1. Blind flight. Skip context modeling and requirements analysis. Do not bother to elicit Non-Functional Requirements (NFRs), do not waste time to make informal quality goals specific and measurable. Who wants to find out whether a particular NFR (“-ility”) is achieved anyway?²
2. Following the crowd. Rest assured that what works for others will work for you too, no matter what the requirements might be. Numbers matter, big is beautiful! This fallacy of relevance is also known as lemming effect or argumentum ad populum.³
3. Anecdotal evidence to justify a design choice. Find a positive or a negative example in tribal knowledge and base your entire argumentation on it. Success or failure on one single project in the past, for instance reported in a blog post with a clickbait title, certainly implies that future usages will have the same outcome (good or bad).⁴
4. Blending whole and part, or class and instance. Everything is related. If one concept in an architectural style has a bad reputation, the entire style must be bad and ought to be neglected. If one pattern from a pattern language does not fit, the entire language cannot be eligible. This reasoning works in the other direction too: if one concept fits, everything else a style or pattern language have to offer must be good too.⁵
5. Abstraction aversion. Do not ask which concrete instance of a more general problem you are facing; abstractions bring indirections with them that waste resources. Decide for concepts, technologies and products/services at the same time and create a single mashup ADR.⁶
6. Golden hammer and hope for a silver bullet. One size fits all. Searching for alternatives is wasteful; relevant candidate solutions find their problems, they do not have to be searched for. Eventually, breakthrough innovations will improve productivity, reliability and simplicity so much that AD making becomes trivial or obsolete.⁷
7. Time dimension deemed irrelevant. Once some evidence about a design option has been found, keep on using it to justify future ADs; Information Technology (IT) is a stable domain with few if any innovations after all. Hence, application architectures do not drift and designs do not erode over the years.⁸

🤔 Which of these fallacies shine through in the shop example from the start of the post?

Bonus fallacy: AI über-confidence

A new contestant has entered the playing field — blind faith or über-confidence in Artificial Intelligence (AI). The AI hype train rides at full speed at present, with destination unknown:

• While AI assistants have their place and promising use cases (here: “vibe architecting”), usage of generated design advice without quality assurance is an element of risk, and accountability is an issue.
• Prompts have their role to play — if you bake one or more of the above fallacies into your prompt, what do you expect a stochastic parrot to reply that has been trained on trustworthy sources but also on known uses of the fallacies?
• “More Resources about AI You Might Want to Review” and Ten “Resources about AI in Software Engineering You Do Not Want to Miss” point at articles and presentations that contribute to the discussion.

Would Sorcerer’s Apprentice be an appropriate alias name for this new fallacy? 🤔 ⁹

How to get it right: from poor to proper ADs and ADRs

Now that we have seen what not to do, what should we do instead?

Let’s revisit and counter the seven fallacies one by one.

1. Agree on landing zones for the operating range of the software under construction. Never forget that requirements and context matter; make the context explicit and compare it with that on previous projects. Use it to elicit specific and measurable NFRs.¹⁰
2. Beat the street (when needed). Reusing the solution to a different problem without checking whether the requirements are compatible is a decision making smell, and market or technology community trends alone are bad scouts. Apply a recognized method or your own heuristics when transitioning from analysis to design.¹¹
3. Provide balanced, fair judgments. Use SMART NFRs, elicited when following advice item 1, as criteria justifying your ADs in ADRs. Make tradeoffs and confidence levels explicit. It is ok to blend in gutfeel; some bias is unavoidable in “big” decisions. However, Résumé-Driven Development is an anti-pattern.
4. Divide and conquer. Be clear about the scope you operate on; do not mix system-wide arguments with local ones in a single ADR. Once an evolvable overall structure is in place (system-wide, “big” decision), follow-on decisions can address more local, component-specific concerns. Practice divide-and-conquer both in the problem space and in the solution space; when deciding for a style or pattern language, it is perfectly fine to leave out certain parts or pick only one part or pattern.
5. Navigate between abstract and concrete. To get abstraction levels right, look for is-a relationships in data, but also in features/capabilities. Going back and forth (or up and down) often is required when establishing is-a relationships. When evaluating AD options, make sure you are not comparing carrots with parrots (or carrots with animals and vehicles). This might sound obvious (and it might be initially); however, over time abstraction-refinement violations do creep in. Distinguish abstract, conceptual arguments from concrete, technological ones; both types have their place but should fit the type of decision made. Pattern sections and technology or product/service choices, for instance, should to go separate (but related) ADRs.
6. Continue to grow toolbox. They say that every problem looks like a nail if the only tool you know is the golden hammer. Stay curious and open minded, and try new tools. Reflect, research, and discuss them. Interact with and learn from other architects and developers.¹²
7. Look back and think ahead. Make the expected lifecycle of the architecture and the system under construction explicit, e.g., disposable or durable. For durable systems, add a time dimension to your consequences discussion in the ADR. Repeat and update older technical evaluations such as performance measurements to reproduce their results before using them as arguments. Specify a review due date for early ADs.¹³

Look for instances of the not-to-do-list entries in architecture, design and code reviews.¹⁴ Find ways around them; avoiding big mistakes will pay off in the long run.

Fallacies and biases beyond IT and software architecture

My “How to get it wrong” collection contains software design domain-specific versions of more general fallacies and biases, as investigated by psychologists and economists. Some examples are:

• Stereotyping Fallacy
• Confirmation Bias
• Law of the Instrument
• Not-Invented-Here syndrome

The Logically Fallacious website has more. General advice about these fallacies and biases is applicable to AD making too, with adequate abstraction-refinement navigation in place.

Here is some additional, more general advice:

• Don’t let the circumstances or loudmouths push you around. Invest in analysis time.
• Identify ADs proactively, make them consciously, document them as ADRs durably. Acknowledge those who contributed to the AD making.
• Be aware of the cognitive load of chosen options, assess the cost of building, owning, changing and be aware of the risk of over-architecting.¹⁵
• Apply technology for its intended and recommended use, generative AI in particular.
• Talk to peers about all of this; AD making is a team sport. Group decision making mitigates the risk of falling for a fallacy. For instance, a well-organized architecture board can unleash collective genius.

Nobody is perfect; biases are human. Still, your architecture and its stakeholders will appreciate that you catch and fix as many fallacies as possible — or avoid them in the first place.

Further reading

Online resources helpful for fallacy spotting (and/or avoiding them in the first place) include:

• Learn about the importance of context from Eltjo Poort in “Architecture is Context”.
• Check out good decision making and software architecture design practices collected by Ruth Malan in “Architecture Clues: Heuristics, Part ii. Decisions and Change”.
• Ride the IT Architect Elevator with Gregor Hohpe.
• Listen to “Controlling Your Architecture with Philippe Kruchten”, The Azure DevOps Podcast, ep.195
• Get an academic view in “Decision-Making Techniques for Software Architecture Design: A Comparative Survey”.

Which fallacies and cognitive biases have you come across when making architecture decisions?

– Olaf¹⁶

Editorial information: No AI was used to write this post.

End notes: examples and background information