Scaling the Practice of Architecture, Conversationally

Andrew Harmel-Law · article · 2021-11-30 source ↗ Reader 🖥️

Architecture Decision Records Feedback Loops Hierarchy & Org Charts Psychological Safety Sociotechnical Architecture Team Autonomy

Architecture should be practiced as a decentralized, conversational discipline — anyone can make an architectural decision as long as they first seek out and record advice from those meaningfully affected and those with relevant expertise (the 'Advice Process') — supported by four lightweight tools (Architecture Decision Records, a recurring Architecture Advisory Forum, team-sourced architectural principles, and a technology radar) that let architecture scale with team autonomy instead of being bottlenecked on a small group of designated architects.

practical · argumentative — Harmel-Law argues for abandoning the traditional centralized-architect role in favor of a decentralized decision model, then prescribes the specific supporting practices (ADRs, a recurring forum, team-sourced principles) needed to make that model coherent rather than chaotic.

Structure

Part	Role
Problem statement: traditional centralized architecture breaks down under team autonomy because a small group of architects cannot be everywhere, tolerate contextual variance, and avoid blocking anyone	motivation
The Advice Process (Rule: anyone can decide; Qualifier: must consult the affected and the expert first) as the core, decentralizing mechanism	core claim
The centrality of conversation as what actually propagates shared architectural understanding (citing Brandolini and Malan) rather than diagrams or a lead architect's head	theoretical grounding
Four supporting elements: (1) Architectural Decision Records, (2) the Architecture Advisory Forum, (3) team-sourced architectural principles, (4) a technology radar (deferred to a future installment)	practical mechanism — makes the Advice Process scale and stay coherent
Explicit scoping-out of technical strategy and cross-functional requirements as separate, necessary inputs this approach doesn't itself cover	boundary condition

Key terms

The Advice Process
A decision-rights protocol with one rule (anyone can make an architectural decision) and one qualifier (before deciding, the decision-taker must seek out and listen to advice from everyone meaningfully affected and anyone with relevant expertise — without being obliged to follow it).
Architecture Advisory Forum (AAF)
A weekly, hour-long, openly-invited recurring meeting whose only power is to give advice (never to approve/reject) on proposed decisions already captured as draft ADRs — distinguished from a traditional Architecture Review Board by the fact that decision ownership never transfers to the forum.
Architectural principle
A SMART (specific, measurable, achievable, realistic, testable), strategy-aligned statement with explicit implications, used to evaluate architectural decisions — explicitly NOT a practice (e.g. TDD, trunk-based delivery) and NOT a generic principle (e.g. 'keep it simple', 'DRY'); sourced from and owned by the teams themselves, not handed down.

Propositions

explicitAs teams become more autonomous and continuously deliver, a small central group of architects cannot keep up with the number of decisions needed without becoming either an availability bottleneck or a rubber stamp.conf: high
explicitAnyone should be allowed to make an architectural decision, provided they first seek out advice from everyone meaningfully affected and from people with relevant expertise.conf: high
explicitDecision-takers are never obliged to follow the advice they receive, but they are obliged to seek it, listen to it, and record it — the Advice Process optimizes for breadth of input, not for consensus.conf: high
explicitDeliberately seeking out people who will disagree with a decision, rather than people who will rubber-stamp it, produces deeper and more useful advice and does not measurably hurt decision quality or learning.conf: high
implicitDecentralizing decision-taking (via the Advice Process) grows the pool of people willing to identify and drive decisions, because accountability for one's own decisions combined with a felt sense of psychological safety produces more bias-to-action than a model where only designated architects may decide.conf: medium
explicitA system's real architecture is the one living in the heads (and code) of the engineers building it, not the one in diagrams or in a lead architect's head — so distributing architectural decision-making actually closes, rather than widens, the gap between intended and implemented architecture.conf: high
explicitDecentralizing who decides creates a new coherence problem — ensuring many independent decisions still add up to one coherent architecture — and this problem is solved not by central control but by ensuring the right conversations happen (Malan's framing), operationalized through the Advice Process's consultation requirement plus the AAF's shared visibility.conf: high
explicitLightweight Architectural Decision Records with a fixed set of fields (title, status, decision, context, options considered, consequences, advice) function as a thinking checklist that teaches less-experienced practitioners how to make architectural decisions, not just as a record of decisions already made.conf: high
supportsThe Intent Debt · p25 — Harmel-Law's ADR-as-thinking-checklist, with a mandatory recorded advice field, is an early, concrete answer to the later claim that ADRs (alongside AGENTS.md and specs) are the right substrate for externalized intent.
explicitRequiring ADR authors to record and directly engage with the advice they received (even advice they reject) produces more rigorous decisions than simply seeking advice informally and discarding it.conf: high
explicitA recurring, open-invitation forum where Advice-Process conversations happen in front of an audience (rather than 1-to-1) spreads organizational, domain, and architectural knowledge far more broadly than the same conversations held privately, making it a significant driver of organizational learning.conf: high
explicitA forum that only offers advice, and never approval/rejection authority — unlike a traditional Architecture Review Board — preserves decision ownership with the original decider while still gaining group-review benefits.conf: high
supportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p6 — Harmel-Law's worked architectural-principle example is explicitly built on Team Topologies' Stream-Aligned Team as the default team shape, applying that model concretely to how an org writes its own governing principles.
explicitGood architectural principles must be SMART, must support business strategy, must state their own implications, and must number few enough (roughly 8-15) that teams can actually remember and apply them — generic principles ('keep it simple') and process practices (TDD, trunk-based delivery) don't count as architectural principles.conf: high
explicitArchitectural principles need to be sourced from and owned by the teams that must apply them, not handed down, because a felt sense of ownership is what makes teams actually follow a principle rather than merely acknowledge it.conf: high
explicitWhen a decision conflicts with an existing architectural principle, that conflict itself should be explicitly flagged in the ADR and routed through the Advice Process and AAF, rather than silently overridden or silently deferred to.conf: high
supportsTBM 390: Governance by Principle, Not by Template · p12 — Both insist governance artifacts (principles, team shapes) must stay revisable rather than fixed installations — Harmel-Law's 'supersede via a new ADR' mechanism is a concrete implementation of the general claim that governance should periodically re-check fit.
explicitArchitectural principles should themselves be revisable via the same ADR mechanism (a new ADR superseding the old one) rather than treated as a fixed constitution, so that the governance system can evolve as understanding and context change.conf: high
explicitTechnical strategy and cross-functional requirements are necessary inputs to good architectural decisions but are deliberately out of scope for this particular governance approach — the approach assumes, rather than produces, those inputs.conf: high

Arguments

Replacing a small group of central architects with a decentralized Advice Process produces better, faster, more accountable, and better-understood architectural decisions than the traditional model. strength: medium

Explicit premises:

The decision-taker is the person with the need and the one accountable for the outcome
Seeking disagreement deliberately deepens the advice received without harming decision quality
The pool of willing decision-takers grows because accountability plus psychological safety increases bias-to-action
The real architecture lives in developers' heads/code, not in a central architect's diagrams, so distributing decisions narrows (not widens) the intent-implementation gap

Implicit premises:

Most architectural knowledge needed for a good decision is already distributed among the people closest to the problem, not concentrated in a central architect
The main risk of decentralization (incoherence) is adequately mitigated by mandatory consultation plus shared forums, without needing a central approver

Inferences:

If the coherence risk is mitigated primarily through conversation and principle, then the quality of decisions degrades in proportion to how diluted or poorly structured those conversations become — e.g. an AAF that loses attendance or an ADR template that gets skipped would predictably reintroduce the incoherence problem this model is designed to solve.

A lightweight, structured ADR template (with a mandatory advice field) functions simultaneously as a decision record, a teaching tool, and a reinforcement mechanism for the Advice Process itself.

Explicit premises:

The template's fields act as a thinking checklist prompting what to consider and whom to talk to
Requiring the advice field to be filled in makes capturing advice a structural requirement, not an optional nicety
A history of ADRs lets less experienced practitioners learn from precedent, including past mistakes and reversals

Implicit premises:

Forcing engagement with advice (via a required field) changes behavior more reliably than simply encouraging good practice without a structural nudge

Narratives

Harmel-Law describes personally abandoning the practice of taking architectural decisions himself entirely, after repeatedly finding the traditional centralized-architect role impossible to sustain under team autonomy.
→ Grounds the entire decentralization argument in first-person practitioner failure-then-pivot, rather than presenting it as pure theory — this is the narrative seed the whole article elaborates into a method.
The worked example of a 'Value independence of teams most highly' architectural principle, built on Team Topologies' Stream-Aligned Team concept, with explicit stated implications (duplication accepted, higher combined licensing costs accepted, teams self-support their own third-party choices).
→ Demonstrates concretely what a well-formed architectural principle looks like, implicitly supporting the claim that good principles must state their trade-offs explicitly rather than asserting a value without its costs.

Questions addressed

✅ How can architectural decision-making keep pace with highly autonomous, continuously-delivering teams without either becoming a bottleneck or descending into incoherent chaos?
Decentralize who may decide (the Advice Process), but require consultation of the affected and the expert, and support it with four lightweight conversational tools (ADRs, AAF, team-sourced principles, tech radar).
✅ What happens to the traditional 'Software Architect' role once anyone can take architectural decisions?
The role changes rather than disappears — the article promises (in the remaining sections) a 'rejuvenated' set of practices and tools that the former architects now own, though it doesn't fully specify the new role's boundaries in this installment.
⭕ At what organizational scale, or under what conditions, does the Advice Process itself break down (e.g. too many consultees, too few informed people to consult, cross-team political resistance)?

Gaps

incompleteThe article asserts the Advice Process produces 'better, faster, more accountable' decisions purely from the author's own practitioner experience, with no named organization, no comparison against the traditional model it replaces, and no outcome data (defect rates, lead time, decision reversal rates).
Read next: Look for empirical studies of decentralized decision-rights models (e.g. DORA/Accelerate-style research) that measure outcomes rather than practitioner testimony.
incompleteThe coherence-risk mitigation (consultation + AAF + principles) is never stress-tested against a scenario where the number of autonomous teams is very large, or where teams are geographically/organizationally siloed enough that the 'everyone meaningfully affected' consultee list becomes unknowable rather than just long.
Read next: See Team Topologies for how team-shape and interaction-mode choices interact with this kind of decentralized governance at larger scale.
uninformedWritten in 2021, the article has no occasion to consider what happens to the Advice Process and ADR discipline once a large share of code is authored by AI coding agents rather than humans — specifically, whether an agent can be a legitimate decision-taker under the Rule, whether an agent can meaningfully 'seek advice,' and whether agent-authored ADRs would carry the same teaching/learning value for human teams that Harmel-Law attributes to human-authored ones.
Read next: See the corpus's AI-era ADR and architecture-governance material (e.g. extract-ai-agents-own-initial-code-draft, extract-osmani-intent-debt) for how this question starts to get addressed once agents are in the authoring loop.

Closes gaps elsewhere

Accelerating Delivery: How AI Agents Can Own the Initial Code Draft · g2 — Harmel-Law's Advice Process plus the mandatory ADR template (with a required 'advice' field, status lifecycle, and supersession-based updates) is a concrete, already-practiced method for producing and continuously maintaining well-structured ADRs — directly answering the gap's call for 'practical guides to making architecture decisions machine-readable,' though written before AI agents were the consumer in mind.