Summary: Medicine and structural engineering each went through a reckoning that forced them to rate the evidence behind their recommendations. Technology architecture never has. IASA surveyed 222 patterns across software design, integration, cloud-native, data, and frontend, and found that 39 rest on a single canonical source — one person, one book, one blog post — yet circulate in ADRs and course curricula as though proven. The fix isn't to abandon patterns; it's to know what kind of claim you're making when you invoke one.

The reckoning other professions already had

Evidence-based medicine asked clinical practice a blunt question — where is the proof? — and the answer was uncomfortable: a surprising number of widely used treatments rested on Level 5 evidence (expert opinion reasoned from first principles), not controlled trials. The resulting hierarchy (systematic review of RCTs at Level 1, expert opinion at Level 5) didn't disqualify Level 5 recommendations — it required practitioners to know they were working from expert opinion and to calibrate confidence to the evidence behind the claim.

Structural engineering handles it through consensus standards updated when real-world failures force revision. Tacoma Narrows (1940) made aerodynamic analysis a required discipline. Ronan Point (1968) changed building codes. The FIU pedestrian bridge (2018) produced published findings shared across the profession. The ASCE requires a minimum 45-day public comment period on any new or revised standard. No individual practitioner unilaterally decides what counts as established practice.

Architecture never did this

Technology architecture has accumulated a pattern vocabulary running to hundreds of named solutions, and the evidence behind most of them has never been examined. IASA's survey looked for independent, verifiable evidence for each pattern — multiple sources, documented application across contexts, examined failure conditions, clear statements of where the pattern doesn't work. The results:

  • 39 of 222 patterns have a single canonical source. One practitioner's documented experience — which may be valuable, but is not the same thing as a tested claim — spread through the community and now appears in design reviews as generalized knowledge.
  • The integration domain is especially thin. Hohpe and Woolf's Enterprise Integration Patterns is foundational but dates to 2003, predates cloud-native infrastructure, and has never been systematically reviewed.
  • Cloud-native vocabulary lives in vendor docs and conference talks. Sidecar (renamed "Stamp" by Microsoft), Bulkhead, Database per Service, Transactional Outbox, many observability patterns — engineers at specific companies solving specific problems under specific constraints. Whether those constraints match yours is a question the pattern name does not answer.

What a credible pattern looks like

The GoF patterns (1994) are the counterexample that proves the point. Twenty-three patterns, each with a defined structure — problem context, solution, participants, consequences, documented trade-offs — plus multiple independent implementations across languages and decades, examined failure conditions, and known anti-patterns. You can reason from Observer because its claim is specific and its boundaries are described.

By contrast: the Saga pattern does not yet meet that standard across the profession (see What Senior Architects Know About SAGA That Juniors Don't). Event Sourcing is frequently recommended in contexts where its failure modes have not been examined. The Strangler Fig has a clear origin in one migration context, and the conditions under which it fails are poorly documented where architects find it.

The certainty program

IASA is adding experimentation and certainty analysis to all BTABoK pattern articles. Every entry will carry an explicit certainty rating: how many independent sources exist, how stable the pattern definition is across them, and what conditions have been tested versus assumed. Where a pattern has a single origin, that will be stated. Where there is documented evidence of poor outcomes under superficially similar conditions, that becomes part of the article. The structure adds practical observability guidance — what an architect should measure to confirm a pattern is working in their context, and what signals indicate the hypothesis isn't holding. The certainty factor is meant to be publicly debatable and challengeable.

Why it matters

Patterns carry authority in architectural conversation. When a named pattern enters a design discussion, it tends to close the question rather than sharpen it. That authority is appropriate when the pattern rests on solid evidence and dangerous when it's a hypothesis repeated often enough to feel established. A physician recommending a Level 5 treatment has an obligation to say so; a structural engineer applying an unvalidated design bears personal liability. Architecture has not yet built those accountability mechanisms around its knowledge claims. The argument is not against patterns — it's for knowing, every time, whether you're citing a tested claim or an untested hypothesis that happens to have a name.