What problem does this system address?
Architecture reviews typically fail because they are presentations, not inquiries. The architect explains the design. The reviewers nod. No one challenges assumptions because the format does not invite challenge. The Socratic method provides a format that makes inquiry the default.
Socrates did not lecture. He asked questions. His questions followed a pattern: begin with what the person claims to know, find the assumptions beneath the claim, test whether those assumptions are consistent, and discover what the person does not know that they thought they did. Applied to architecture review, this means starting with what the architect claims the system does, finding the assumptions beneath the design, testing those assumptions for consistency, and discovering the risks that the design has not addressed.
How is the system structured?
The Socratic architecture review uses 4 questioning phases, each designed to expose a different category of design risk. The phases progress from the surface (what the system does) to the foundation (why the system is designed this way) to the gaps (what the design does not address).
Phase 1: Clarification questions
These questions ensure the review team understands what the system actually does, not what the architect assumes everyone knows. “What does this system do?” “For whom?” “What happens if it stops working?” I have found that 30% of architecture reviews proceed without shared understanding of the system’s purpose. These questions eliminate that gap. Socrates called this elenchus: the process of cross-examination that reveals whether the speaker’s knowledge is genuine or assumed.
Phase 2: Assumption questions
Every design rests on assumptions. Assumption questions make them explicit. “What would have to be true for this design to succeed?” “What are you assuming about user behavior, traffic patterns, data quality?” “Which of these assumptions have you tested?” In my experience, the average architectural design rests on 8-12 untested assumptions. Naming them does not make them safe, but it makes them visible. This connects to the practice of premeditatio malorum: anticipating what could go wrong by examining what must go right.
Phase 3: Contradiction questions
These questions test whether the design’s stated goals align with its actual structure. “You say the system prioritizes reliability, but I see no retry logic and no circuit breaker. How do you reconcile that?” “You say this is designed for extensibility, but the data model is tightly coupled to the current use case. What would extension actually require?” Contradictions between stated values and implemented patterns are the most common design risks I encounter. They are also the most invisible without direct questioning.
Phase 4: Implication questions
These questions explore consequences the design has not addressed. “If this service fails, what happens to the 3 downstream services that depend on it?” “If traffic doubles, which component fails first?” “In 2 years, when this team has turned over, how will the next team understand why these decisions were made?” These questions reveal the gap between the system as designed and the system as it will be lived with.
How do you validate it works?
By tracking design risks identified per review and comparing Socratic reviews to traditional presentation reviews. In my practice, Socratic reviews identify 2.7x more design risks, surface assumptions that would otherwise remain invisible, and produce architecture decisions that the team has genuinely examined rather than passively received.
I track 3 metrics. First, the number of untested assumptions identified per review (target: 5 or more). Second, the number of contradictions between stated goals and implemented patterns (any number above 0 indicates value). Third, the architect’s self-reported confidence after the review. Counterintuitively, the best reviews reduce the architect’s confidence, because they reveal what the architect did not know. A review that leaves the architect more confident is either very good (genuine validation) or very bad (insufficient questioning). The examined workflow applies the same principle: scrutiny produces clarity, not comfort.
“The unexamined system, like the unexamined life, is not worth deploying.”