Chapter 02 Flashcards — Architectural Thinking
flashcards fsa architectural-thinking technical-breadth trade-offs
What is the core thesis of “architectural thinking” as defined in Chapter 2?
?
Architectural thinking is a learnable, distinct cognitive skill — not just senior developer thinking applied to bigger problems. It differs from developer thinking in four specific ways: (1) how architects relate to design and collaborate with developers, (2) the emphasis on technical breadth over depth, (3) the ability to rigorously analyze and reconcile trade-offs, and (4) understanding business drivers that shape structural decisions.
What is the problem with the traditional “wall” model of architect-developer collaboration?
?
The traditional model has architects making decisions and throwing them over a wall to developers. This fails because: architects make decisions without understanding implementation constraints; developers cannot give feedback on architectural problems they discover; architecture and implementation drift apart; knowledge flows only downward; and architects lose touch with technical reality. The result is architectures that are theoretically sound but practically unimplementable.
What is the bidirectional architect-developer collaboration model?
?
Architects define boundaries and constraints within which developers have full autonomy. Developers provide implementation feedback — emerging technical concerns, feasibility issues, code-level knowledge — back to the architect. The architect must remain technically engaged enough to understand and respond to this feedback. This bidirectional flow keeps architecture grounded in implementation reality.
What is the difference between technical breadth and technical depth?
?
Technical depth is deep expertise in a specific technology, stack, or domain — the developer’s core value. Technical breadth is broad awareness of many technologies, patterns, and approaches without necessarily mastering each. Architects need breadth to evaluate options across many domains and reduce unknown unknowns. The ratio shifts from developer to architect: breadth becomes proportionally more valuable than depth.
Describe the knowledge pyramid and how it differs between developers and architects.
?
The knowledge pyramid has three levels: “stuff you know” (expertise), “stuff you know you don’t know” (aware of but not expert in), and “stuff you don’t know you don’t know” (unknown unknowns — the most dangerous zone). Developers have a tall, narrow pyramid — deep expertise at the top, large unknown-unknowns base. Architects should have a wide, shorter pyramid — broad awareness at the top, small unknown-unknowns base — because active breadth investment shrinks the dangerous bottom layer.
What is the “Frozen Caveman” antipattern?
?
The Frozen Caveman is an architect who defaults to the same outdated solution regardless of the problem, because it is the only approach they know deeply — like a prehistoric human frozen and thawed into the present with past-era solutions. It occurs when an architect’s pattern library is frozen at the point where they stopped investing in technical breadth. The antidote is active breadth investment, explicit consideration of unfamiliar alternatives, and rigorous trade-off analysis before defaulting to the familiar.
Why is “stuff you don’t know you don’t know” the most dangerous knowledge zone for architects?
?
Because an architect unaware of a relevant technology, pattern, or approach cannot consider it as a solution and cannot recognize when a team’s solution is inferior to an unknown alternative. This leads to suboptimal architectural decisions made with confidence — the architect doesn’t know they’re missing a better option. Technical breadth directly targets this risk by shrinking the unknown-unknowns zone.
What is the recommended knowledge transition when moving from developer to architect?
?
Deliberately shift the ratio from depth-focused to breadth-focused learning: survey many technologies sufficiently rather than mastering one more deeply; measure success by decision quality rather than personal technical output; invest in patterns and trade-offs rather than specific library versions; and attend to business context rather than purely technical concerns. Retain at least one or two deep areas, but breadth becomes the proportionally higher priority.
What are the six steps of the trade-off analysis framework?
?
- Identify the decision — what structural or technological choice is being made?
- Enumerate the options — what are the realistic alternatives? (At least three)
- Identify trade-offs for each option — what does each gain and give up?
- Evaluate against architecture characteristics — which option best satisfies the prioritized “-ilities”?
- Consider context — team size, timeline, budget, organizational constraints, existing infrastructure
- Decide and document rationale — an ADR captures the decision, alternatives considered, trade-offs, and context
Why must architects resist “best practice” dogmatism?
?
A “best practice” is a solution that was right in some context — that context may not match the current situation. Applying best practices without analyzing the current context is recipe-following, not architectural thinking. Architects must ask: “Given our specific quality attribute priorities, team constraints, and business context, which option makes the best trade-offs for us right now?” — not “what do the industry experts recommend in the abstract?”
What are the key business drivers that shape architectural decisions?
?
- Time to market / agility — speed pressure favors simpler architectures and independent deployability
- Reliability / uptime requirements — SLA commitments drive redundancy and circuit breaker patterns
- Cost constraints — distributed systems are expensive to operate; budget limits viable complexity
- Team structure and capability — Conway’s Law means the achievable architecture is constrained by the available team
- Regulatory/compliance requirements — GDPR, HIPAA, PCI-DSS impose specific data handling and audit constraints
- Growth trajectory — design for the 12-month horizon, not theoretical infinite scale
What is the “20-minute rule” for developing technical breadth?
?
Spend 20 minutes per day reading about technology outside your current stack — conference talk summaries, technical blog posts, architecture case studies. The goal is awareness, not depth. Over a year, this compounds into significant breadth. Combined with reviewing resources like the ThoughtWorks Technology Radar quarterly, it keeps an architect’s unknown-unknowns zone actively shrinking.
What is the ThoughtWorks Technology Radar, and why is it valuable for architects?
?
The ThoughtWorks Technology Radar is a quarterly publication that categorizes technologies into four rings: Adopt (proven, use widely), Trial (ready for pilot projects), Assess (promising, worth exploring), and Hold (caution or avoid). Reviewing it regularly keeps architects aware of what is emerging, maturing, and declining — providing a structured way to maintain breadth without having to discover every technology organically.
What is an architecture kata, and what skill does it develop?
?
An architecture kata (from martial arts practice) is a structured problem presenting a business context, user scale, and requirements that an architect must use to: (1) identify driving architecture characteristics, (2) propose a structural approach, and (3) defend trade-offs. Katas develop the trade-off analysis instinct — the muscle memory of architectural reasoning — through repeated, varied practice. Examples used in the book include Silicon Sandwiches, Farmacy Foods, and GoldStar Video.
What are three practices for improving trade-off analysis skills?
?
- Always enumerate at least three options — two-way comparisons constrain thinking; three options force broader exploration and often reveal better hybrids
- Write the trade-off, not just the recommendation — the analysis is more valuable than the conclusion for future readers making related decisions
- Argue the opposing case — before committing, make the best argument for the alternative to distinguish rigorous analysis from post-hoc rationalization
What are the key differences between developer thinking and architectural thinking?
?
| Dimension | Developer | Architect |
|---|---|---|
| Primary question | ”How do I implement this?" | "What structure best enables this?” |
| Success metric | Working code | Sound trade-offs with justified constraints |
| Knowledge investment | Depth | Breadth |
| Decision horizon | Sprint/feature | Months to years |
| Business awareness | Nice-to-have | Required |
| Political awareness | Optional | Required |
How does growth trajectory affect architectural decisions?
?
Growth trajectory determines the time horizon to design for and the scalability headroom required. A startup expecting 10x growth in 12 months needs architectural headroom (modular design, potential for extraction) that a stable enterprise does not. However, over-engineering for infinite scale from day one wastes resources and adds complexity that slows early development. The principle: design for the 12-month horizon — not for theoretical future scale that may never materialize.
What makes trade-off documentation more valuable than the trade-off recommendation itself?
?
Future team members who read only the recommendation cannot determine: whether the constraints that led to it still apply; what alternatives were seriously considered; what was given up; or whether the decision should be revisited as context changes. The documented trade-off analysis enables future decision-makers to either preserve a still-valid decision (knowing why it was made) or confidently replace an outdated one (knowing what constraints no longer apply).
What is “Trade-off Avoidance” and why is it an antipattern?
?
Trade-off Avoidance is making architectural decisions without explicitly stating the trade-offs accepted — often because acknowledging trade-offs feels like admitting weakness or uncertainty. It is an antipattern because: hidden trade-offs accumulate as invisible technical debt; future teams make decisions without knowing what was already consciously given up; and the architect appears to be claiming a cost-free solution, which violates the First Law. Clear trade-off documentation is a sign of architectural maturity.
Why is business domain vocabulary important for architects?
?
Architects who can describe the business domain in the business’s own terms (not technical abstractions) build stakeholder trust, make better trade-off decisions by understanding what actually matters to the business, and can accurately translate business requirements into architectural constraints. The alternative — architects who speak only in technical terms — creates a translation gap where architectural decisions miss business intent, however technically sophisticated they may be.
What is the key insight about “best practices” and context-dependence?
?
A best practice is a context-specific solution that worked well in a particular situation. That situation may or may not match your current context. Architects must evaluate whether the context in which a best practice emerged matches their situation before applying it. Factors that change context: team size, scale requirements, organizational maturity, regulatory environment, existing infrastructure, time horizon. Applying a best practice without context evaluation is recipe-following, not architectural thinking.
Priority: HIGH — architectural thinking is the foundational skill required to apply all subsequent content in the book