The Architecture Advice Process: Decentralizing Decisions with Lightweight ADRs
Software architecture has a reputation problem. The "ivory tower" model reigned — senior architects designed systems in isolation, handed down specifications, and expected compliance. As teams scaled, this top-down approach became a bottleneck.
Enter the architecture advice process, championed by Andrew Harmel-Law at GOTO Copenhagen 2025. Combined with lightweight Architecture Decision Records (ADRs), this approach decentralizes architectural authority without losing rigor — gaining real traction across engineering organizations in 2026.
The Problem: Architects as Bottlenecks
In traditional practice, decisions flow top-down. A principal architect evaluates options, makes a call, and communicates it to implementation teams. This breaks down three ways:
- Speed kills. Every decision routes through one or two people, creating a queue longer than any sprint planning backlog.
- Knowledge concentration is fragile. When architectural knowledge lives in someone's head ("knowledge stock"), that person leaves and the organization loses institutional memory — no audit trail, no reasoning log, no way for new engineers to understand why a system was designed a certain way.
- Decisions grow too large. When architects design in isolation and hand over big decisions at once, there's no incremental feedback loop. Teams implement wrong assumptions, discover mismatches late, and spend months refactoring.
Harmel-Law calls this "knowledge stock" thinking — hoarding expertise rather than flowing it to where it's needed. Every organization that tried microservices and ended up with a distributed monolith feels the consequences.
The Advice Process: Decentralized by Design
The architecture advice process flips the model. Instead of architects making decisions, they advise. The person doing the work gets authority to decide — but must seek counsel from peers before committing:
- Decision ownership stays with the doer. Developers closest to the problem space make calls and own outcomes.
- Advice flows bidirectionally. Architects mentor while sharing reasoning through collaborative trade-off discussions.
- Decisions stay small and fast. Teams make incremental decisions with lightweight feedback, catching problems early.
The key insight: the advice process prevents adversarial dynamics. You don't need permission — just seek advice. The decider retains full responsibility, eliminating "the architect told me" excuses while preserving collective wisdom.
Lightweight ADRs: The Immutable Change Log
What makes this process durable is the lightweight Architecture Decision Record. Unlike traditional ADRs that become bloated documents no one reads, Harmel-Law advocates a stripped-down format with three sections:
- Context. What situation prompted this decision?
- Decision. What was chosen, and what alternatives were considered?
- Rationale. Why this choice over others, with honest acknowledgment of trade-offs and unknowns.
When every architectural decision gets recorded, the collection becomes an immutable change log for the entire system architecture. It tells the story of how the system evolved — including the gory context behind each choice. For onboarding engineers, this is worth more than any architecture diagram.
The "lightweight" qualifier matters. These aren't formal design documents requiring steering committee approval. A well-written lightweight ADR can be drafted in 30 minutes and reviewed asynchronously by two or three peers. The barrier to entry must stay low enough that the process doesn't become a new bottleneck itself.
The Weekly Architecture Advice Forum
ADRs alone aren't enough. Harmel-Law proposes a weekly architecture advice forum serving three functions:
First, it democratizes architecture. Anyone can observe decision-making in real time, shining light on practices older approaches kept behind closed doors.
Second, it builds trust in the process itself. When people see decisions made collaboratively and architects mentoring rather than dictating, others become willing to exercise their own authority. The forum makes the invisible visible.
Third, it creates a ritual for reflection. In the rush of delivery, architectural thinking gets deferred indefinitely. A recurring forum ensures someone pauses to ask: are we still building the right thing?
Why Organizations Fail at This
The advice process isn't a silver bullet. Harmel-Law is candid about failures — they almost always trace back to trust deficits. Senior architects unwilling to share power create cultures where junior engineers are afraid to decide anything independently, conditioned to expect a "no" from above.
The antidote is mentorship. Experienced architects must actively build colleagues' confidence, modeling good decision-making by showing their own reasoning and acknowledging uncertainties. "I don't know yet" should be a perfectly valid starting point for any architectural discussion.
Another common failure: decisions flying under the radar. People make choices without realizing they're making architectural decisions, or do so secretly out of fear of being challenged. The remedy: normalize advice-seeking by asking "did you get architecture advice on that?" with curiosity.
Making It Work in Practice
If your organization wants to adopt this approach, start small. Pick one team or project. Introduce lightweight ADRs as a simple three-section document stored alongside the codebase. Run a weekly 30-minute forum focused on real decisions happening right now, not retrospective documentation.
Measure success by faster decisions, new engineers understanding architectural context, and architecture matching the codebase. If yes to all three, you've built something that lasts — decided thoughtfully over time.
Based on Andrew Harmel-Law's work presented at GOTO Copenhagen and his subsequent InfoQ interview. The architecture advice process represents a shift from architecture as authority to architecture as craft — one that any engineering team can practice, regardless of size or seniority.
Comments