Andrew Harmel-Law presents a revolutionary approach to software architecture that distributes decision-making authority while maintaining quality through an advice-seeking process.
The traditional model of software architecture, where a select few architects make all the critical decisions, is becoming increasingly unsustainable as systems grow more complex and development practices evolve. At GOTO Copenhagen, Andrew Harmel-Law presented a compelling alternative: the Architecture Advice Process, which fundamentally reimagines how architectural decisions are made and who makes them.
The Problem with Traditional Architecture
The core challenge in modern software architecture is being in all the right places at all the right times. Architectural decisions happen constantly across organizations, but when only a handful of people are responsible for all decisions, they face an impossible task. They must:
- Make optimal decisions for everyone based on complete information
- Be accountable for every architectural choice
- Ensure their understanding is clearly communicated to all stakeholders
- Continuously learn from feedback and mistakes across the entire system
Harmel-Law argues this traditional approach creates bottlenecks that block organizational flow. The "ivory tower" architect and the "hands-on architect" models don't scale—they prevent fast feedback loops and disconnect architectural decisions from the people implementing them.
The Architecture Advice Process
The solution is elegantly simple: anyone can make any architectural decision, provided they seek advice from two groups:
- Those who are affected by the decision
- Those with relevant expertise
This isn't about seeking permission—it's about gathering informed perspectives. The person making the decision retains full accountability, but they benefit from the collective wisdom of the organization.
This approach transforms the architect's role from decision-maker to conversation starter and guide. Architects become advice-givers, context-providers, decision-coaches, and conversation-curators rather than gatekeepers.
Real-World Implementation
Harmel-Law points to successful case studies like Xapo Bank's experience with decentralizing architectural practice. In these organizations, architecture becomes a distributed responsibility where decisions happen wherever and whenever they're needed.
Consider a practical example: a team deciding between lambdas, Kubernetes pods, or bespoke compute nodes for a new service. A systems architect might comment on an Architecture Decision Record (ADR) noting that lambdas can be slow to start and complicate state management. The team can still choose lambdas after understanding these concerns—they remain accountable for their decision without being bound to follow the advice.
Cultural Transformation
This shift represents more than a process change—it's a fundamental transformation of mental models. Architecture moves from being an exercise in hierarchy, closed knowledge, and power dynamics to one of knowledge sharing and collective experience.
Personal knowledge stocks ("I know something valuable that no one else knows") transform into collective knowledge flows ("we all benefit from the right information being available to the right people at the right time").
Common Failure Patterns
Organizations adopting this approach should watch for several failure modes:
- Bad decisions: Senior people stepping in to override decisions
- Old guard == new guard: The same senior architects continue making all decisions
- Off the radar decisions: Choices made privately without following the process
- No trust: Team members don't trust each other to follow the process or be accountable
Initial difficulties often arise as participants struggle to abandon older mental models. It's crucial to understand that consensus isn't required, and advice-offerers aren't granting permission—the decision-maker retains full authority even if they disregard the advice.
The Future of Architecture Practice
The Architecture Advice Process represents a return to first principles of software system design. It focuses on having the right conversations between the right people at the right time. This practice will evolve uniquely for each organization based on its people, systems, customers, technology evolution, and market context.
This approach aligns with broader trends in software development toward decentralization, autonomy, and fast feedback loops. As organizations continue to decentralize their systems, it's natural that the practice of architecture should follow suit.

About the Author
Ben Linders is an independent adviser, coach, and trainer specializing in Agile, Lean, Quality, and Continuous Improvement. He's the author of several books including Getting Value out of Agile Retrospectives and The Agile Self-assessment Game, and actively contributes to the Agile community through writing, speaking, and coaching.

Related Topics: Architecture & Design, Culture & Methods, Architecture Documentation, Process, Culture, Patterns and Practices, GOTO Conference, Architecture Decision Records
The Architecture Advice Process offers a practical path forward for organizations struggling with architectural bottlenecks. By distributing decision-making authority while maintaining quality through structured advice-seeking, teams can achieve both the autonomy needed for fast flow and the coordination necessary for coherent systems.

Comments
Please log in or register to join the discussion