Our system architectures have changed as technology and development practices have evolved, but the way we practice architecture hasn’t kept up. According to Andrew Harmel-Law, architecture needs to be decentralized, similar to how we have decentralized our systems. At Goto Copenhagen, he presented the architecture advice process.
The biggest challenge in architecture is to be in all the right places at all the right times, Harmel-Law said. Architectural decisions are happening all over the place, and all the time. If there are only a named few who are responsible and accountable for all decisions, they need to be taking the best decisions for everyone based on all the right information and context. And they also need to be accountable for all of this:
They not only have to ensure their understanding of the architecture is clear to everyone; they also have to be constantly learning from the feedback and mistakes that arise from the implementation and running of those architectures.
Frankly, this is impossible to do – at least if you don’t want to become a flow-blocker.
The traditional approaches to the practice of architecture (the memes of “ivory tower” and “hands-on architect”) don’t scale – they create bottlenecks to flow, and don’t sufficiently factor in feedback loops from the running (tested) code, Harmel-Law said. The traditional role of the “architect” needs to change to one of a conversation starter and guide, driving just-enough shared understanding and the space for learning and fast feedback
The alternative to having an architect take and communicate the decisions is to “let anyone make the decisions”. The advice process makes space for this, Harmel-Law explained:
By stating “anyone can make any decision, as long as they seek advice (which is different from permission) from all affected parties and those with expertise” it transfers both responsibility and accountability for decisions to those who need it. While no one is then obliged to decide, it allows those who feel the need to do so.
What then happens is that the architecture conversations start happening wherever and whenever they are needed. Harmel-Law referred to case studies: the InfoQ article Empowering Teams: Decentralizing Architectural Decision-Making and the article Decentralizing the Practice of Architecture at Xapo Bank.
In these circumstances, the role of “architect” is spread across your organization, and those who traditionally played this role step back into the roles of advice-giver, context-provider, decision-coach, and conversation-curator, Harmel-Law said. The practice of architecture spreads to those who need to practice it, supported by those with relevant experience:
As someone who has played a traditional “architect” role in the past, it’s exhilarating to experience.
Using the architecture advice process, anyone can make any architectural decision, as long as they seek advice from:
- Those who are affected
- Those with expertise
Adopting the Architecture Advice Process is a revolution; It’s a return to the first principles of software system design, with the focus on the practice of architecture becoming the right conversations between the right people at the right time, Harmel-Law explained:
This practice will emerge in a way that is unique to you, your colleagues, your existing systems, your customers/clients, the overall evolution of technology, and your market, and more.
Harmel-Law mentioned that there are some major failure patterns to look out for:
- “Bad decisions” – specifically senior people stepping in to stop decisions from happening.
- “Old guard == new guard” – the same (senior architects) are still doing all the deciding.
- “Off the radar decisions” – decisions being taken in private or without following the process (e.g. not seeking the appropriate advice, or recording this all in an architecture decision report [ADR]).
- No trust – people not trusting each other to follow the process, and not being accountable for their decisions that result.
Initially, difficulties will likely arise when participants struggle to shed their older mental models, Harmel-Law said. Consensus is no longer required, and advice-offerers are not giving “permission” for the decision. That continues to lie with whoever initiates the process for the decision at hand. It is perfectly acceptable if the advice that is offered is not taken into account in the resulting decision.
Harmel-Law gave an example of a team that wants to decide on a new platform for a service they are writing. The options are a set of lambdas, a microservice running on a Kubernetes pod, or a collection of bespoke compute nodes:
A systems architect offers advice on the lambda-option, writing it as a comment on the ADR in question. They state that in their experience, lambdas will be slow to start and make state-management more difficult. While understanding these concerns, the team can still decide to pick the lambda-based option. They remain accountable for the decision. While they have hopefully understood the systems architect’s concerns, they are not bound to follow them.
This changes not just the practice of architecture, but also the mental models of those who practice it. It changes it from being an exercise in hierarchy, closed, semi-secret knowledge, and power-plays into one of knowledge sharing and shared experience, Harmel-Law said. It devalues personal knowledge stocks (“I know something valuable that no one else knows and therefore I have power”) into collective knowledge flows (“we all benefit from the right information being available to the right people at the right time”).
