Medicine went through its version of this reckoning. Clinical practice had accumulated decades of treatments that practitioners recommended with confidence, based on training, professional consensus, and the authority of senior clinicians. Then evidence-based medicine arrived and asked a straightforward question: where is the proof?
The answer was uncomfortable. A surprising number of widely used treatments rested on Level 5 evidence — expert opinion based on reasoning from first principles, not on controlled trials or systematic review. The hierarchy that emerged from that reckoning is now the foundation of clinical practice. A systematic review of randomized controlled trials sits at Level 1. Expert opinion sits at Level 5. Crucially, Level 5 evidence does not disqualify a recommendation — but it requires that practitioners know they are working from expert opinion and treat it accordingly. The claim is rated. The confidence is calibrated to the evidence behind it.
Structural engineering handles this differently but with the same underlying discipline. Building codes are not collections of ideas that engineers found useful. They are consensus standards developed through formal committee processes, updated when real-world failures force revision. When the Tacoma Narrows Bridge collapsed in 1940, the engineering community did not simply note it and move on. Investigation boards were convened. The Carmody Report was published. Suspension bridge design changed. Aerodynamic analysis became a required discipline. When Ronan Point partially collapsed in 1968 after a gas explosion, building codes changed. When the Florida International University pedestrian bridge failed in 2018, findings were published to share lessons across the profession. The ASCE’s standards development process requires a minimum 45-day public comment period on any new or revised standard. The knowledge is tested, contested, and updated through a defined process. Individual practitioners do not get to decide unilaterally what counts as established practice.Architecture — the technology architecture profession — has never done this. We have accumulated a pattern vocabulary that now runs to hundreds of named solutions, and the evidence behind most of them has never been examined.
We recently surveyed 222 patterns across the domains that architects work in daily: software design, integration, cloud-native infrastructure, data access, and frontend architecture. We were looking for independent, verifiable evidence for each — multiple sources, documented application across different contexts, examined failure conditions, and clear statements of where the pattern does not work.
Thirty-nine of the 222 patterns have a single canonical source. One person. One book. One post on a company engineering blog. The pattern name spread through the community and now appears in architecture decision records, design reviews, and course curricula as though it represents proven, generalized knowledge. It does not. It represents one practitioner’s documented experience, which may be valuable but which is not the same thing as a tested claim.
Across the integration domain alone — the patterns that govern how distributed systems exchange data — the independent evidence base is thin. The Enterprise Integration Patterns catalog from Hohpe and Woolf is genuinely foundational, but it dates to 2003, predates cloud-native infrastructure entirely, and has not been subjected to systematic review. The cloud-native patterns that have become standard vocabulary in the last decade — Sidecar (oddly renamed by Microsoft last year to Stamp which highlights the problem well), Bulkhead, Database per Service, Transactional Outbox, many of the observability patterns — exist primarily in vendor documentation, conference presentations, and practitioner blog series from engineers at specific companies solving specific problems under specific constraints. Whether those constraints match yours is a question the pattern name does not help you answer.
The GoF patterns from 1994 are the clearest counterexample in the software design space, and they demonstrate exactly what a credible pattern looks like. Twenty-three patterns. Each with a defined structure: problem context, solution description, participants, consequences, and documented trade-offs. Multiple independent implementations across languages and decades. Examined failure conditions. Known anti-patterns. You can reason from the Observer pattern because its claim is specific and its boundaries are described.
The Saga pattern does not yet meet that standard across the profession. Event Sourcing is frequently recommended in contexts where the failure modes of event sourcing have not been examined. The Strangler Fig pattern has a clear origin story in one specific migration context, and the conditions under which it fails are poorly documented in the places architects find it.
This is not an argument against using patterns. It is an argument for knowing what kind of claim you are making when you use one.
Iasa is adding experimentation and certainty analysis to all BTABoK pattern articles and knowledge items. Every pattern entry will carry an explicit certainty rating: a transparent statement of how many independent sources exist, how stable the pattern definition is across those sources, and what conditions have been tested versus assumed. Where a pattern has a single origin, that will be stated directly. Where there is documented evidence of the pattern producing poor outcomes under conditions that look superficially similar to its intended context, that will be part of the article.
Experimentation is being led by the Modern Architectures community and Mihaela Mazzenga.
The structure will also include practical observability guidance — what an architect should be able to measure or observe to confirm that a pattern is working in their specific context, and what signals indicate the hypothesis is not holding. This is the same discipline that evidence-based medicine brought to clinical treatment: the intervention has to be observable, the outcome has to be measurable, and the practitioner has to know when the evidence does not apply.
The certainty factor will be debatable in professionally accessible forums and channels to challenge the existing knowledge.
The reason this matters is that 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. It is dangerous when the pattern is a hypothesis that has been repeated often enough to feel established.
A physician who recommends a treatment based on Level 5 evidence has a professional obligation to know that is what they are doing and to tell the patient. A structural engineer who applies a design approach not validated through the code process bears personal professional liability for that choice. Architecture has not yet built those same accountability mechanisms around its knowledge claims. The BTABoK experimentation and certainty program is a step toward doing that.
The patterns we use shape the systems we build. The systems we build shape how businesses operate, how data moves, how people work. That is a significant chain of consequence to rest on undifferentiated authority, where a tested claim and an untested hypothesis look identical because they both have a name.
The profession can do better. Other professions show exactly how. Iasa architects are at the center of making excellence real.