Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Scaling Software Architecture via Conversations: the Advice Process

Scaling Software Architecture via Conversations: the Advice Process

This item in japanese

Andrew Harmel-Law recently published an article describing a decentralised, scalable software architecture process based on the "Advice Process". The Advice Process promotes software architecture by encouraging a series of conversations driven by an empowering, almost anarchistic, decision-making technique.

According to Harmel-Law, a technology principal at Thoughtworks, the Advice Process is simple. It comprises one rule and one qualifier.

The rule: anyone can make an architectural decision.

The qualifier: before making the decision, the decision-taker must consult two groups. The first is everyone who will be meaningfully affected by the decision. The second is people with expertise in the area the decision is being taken.

It's important to note that while decision-takers must actively seek advice, they are not obliged to agree with and implement it. They have complete freedom to make the decision they see fit. As a result, decision-takers completely own their architecture decision and implementation and are committed to it.

Harmel-Law's primary motivation in implementing the Advice Process is scaling architecture decision-making. As organisations grow and adopt a mindset of multiple autonomous teams working independently to achieve a shared goal, it became apparent that these teams need to make architecture decisions, and the "traditional" approaches do not scale.

[...] while using them [traditional software architecture approaches] in the world of continuously delivering autonomous teams, I've repeatedly found myself faced with an impossible task: to be everywhere, tolerating significant contextual variance, and blocking no one.

It made me wonder. Was there an alternative?

There was: I stopped taking architectural decisions. Completely.

According to Harmel-Law, traditional architects are not redundant in this process. Instead, their role has changed. Instead of making the decisions themselves, the architects are now tasked with starting the correct conversations with relevant decision-takers, providing reliable advice, and guiding developers towards an optimum overall solution.

Harmel-Law then complements the Advice Process with four essential techniques that guide developers to a coherent whole that incorporates a longer-term perspective into those same decisions. The first tool is a thinking and recording tool - the Architecture Decision Record (ADR). These are lightweight documents, frequently stored in source code repositories alongside the artefacts they describe. A lightweight ADR template structure helps not only to record architectural decisions. It also helps teams learn to make architectural decisions. The template operates like a thinking checklist and prompts the decide-ee regarding what they need to think about, and more importantly, have conversations about.

The second tool is allocating a time and place for conversations - the Architecture Advisory Forum (AAF). The AAF is a regular and recurring place and time for conversations. Attendees include delegates from each team and key representatives from the Advice Process checklist. According to Harmel-Law, "if architecture is being "done" here, and lessons shared and learned, then you're winning." When conversations occur in an AAF, there is an audience, many people can listen, and everyone can learn. "The amount of organisational, domain, legacy, and experiential information and architectural skill-deployment shared at these sessions is unlike anything I have ever seen, and despite being a potentially dry meeting, it is the most well-attended and most broadly participated hour of our week."

The third tool is a light to illuminate a unified goal - team-sourced Architectural Principles. In a world of highly autonomous teams, they become essential because they are how architects achieve an aligned delivery direction without control.

The fourth tool is a customised tech radar based on the ThoughtWorks technology radar. However, it is tailor-made for the specific languages, tools, and landscape the organisation operates in. The radar helps decision-takers navigate the available technologies at their disposal and reach better decisions. One of the ways to create such a radar is ThoughtWorks' build your own radar.

InfoQ spoke with Harmel-Law regarding the Advice Process and its implementation following his article.

InfoQ: The article's core is the "Advice Process". How was it created?

Andrew Harmel-Law: The book "Reinventing Organisations" defines the Advice Process in the context of decision-making in trust-based organisations. And in a trust-based organisation, how do you make decisions? You trust people to make decisions. I liked this approach from the scale perspective. It scales better because many people can make decisions this way. Before I joined Thoughtworks, I ran a team of 36 developers, which later became 98 developers. We had to scale, and I couldn't micromanage all of them. And so I thought - instead of taking all the decisions, I can trust others to make them. So we started implementing the Advice Process for small things, and it worked. When I joined Thoughtworks and became responsible for various projects on architecture and governance, I thought the Advice Process might also work there, and I started implementing it with customers.

InfoQ: In what kinds of organisations would you recommend implementing the Advice Process?

Harmel-Law: We have implemented the Advice Process in various places by now. We implemented it at startups with super distributed cultures and old-school organisations with a more centralised culture and centralised processes, and the Advice Process seems to work in both. The Advice Process itself is the core of the idea. However, the other tools and practices such as ADRs, AAF, Etc., help the process successfully execute in these varied environments without deteriorating into chaos or undirected anarchy.

InfoQ: Is the Advice Process suitable for working with developers of all experience levels?

Harmel-Law: I saw that the concerns that we architects are concerned with were also coming from the developers. Not just the team leads but also the developers themselves. Once they had the responsibility and asked for advice from others, they quickly learned and thought about these concerns. The best ADRs I've ever seen are from developers who own the decisions and implement them because they care about them.

In the past, architecture principles were something that the architects told the developers to adhere to, and the developers either ignored them or implemented them reluctantly. With the Advice Process, the architecture principles are not something that some architects told them to do, but something they actually apply and find value in, since they are the ones making the decision. Suddenly, all of the principles that the architects told developers to care about - the developers did care about because they could see the reason why.

InfoQ: In the article, you mention that you "stopped taking architectural decisions. Completely." What about architects who have a hard time "letting go"?

Harmel-Law: The experience of letting go and teams taking on responsibility is new. No one gives people this opportunity. Most of my consulting work these days is to get the architects and tech leads to let go. The way it works is to convince the architects to let go for a little while and let them make sure that everything runs smoothly.

The architects typically start out fearing it's going to be chaos. However, you typically see that developers are scared because they're not used to autonomy, so the teams don't step forward. The architects then end up encouraging the teams, actively looking for decisions to be made, and helping the team make those decisions, but only with giving advice, not taking the decision for them.

Consequently, you get fantastic conversations because there is a collaboration between the architect who knows the bigger picture and the developers who understand the intricacies of a specific codebase.

The teams that run the code now suddenly have a tool that allows them to solve their problems that only they know about and fix them at the scale they want to. The architects then realise that they are not giving up control, but instead, they can spread their thinking and knowledge around more. Within a month or so, the architects see that others brought up the issues they thought only they worried about, and everyone cared about them.

InfoQ: What about cross-functional requirements (CFRs)? Who can override these? How do you overcome "localised optimums" which do not align with the overall strategy?

Harmel-Law: Everywhere I go, there are CFRs defined, but many developers don't know or, worse, don't care about them. With the Advice Process, the architects let the decisions which assume the existence of CFRs come from the field and address them when they arise. For example, at one customer, the devs had realised observability was poor and wanted to add a trace ID. The architects could then point them to a CFR that already existed for it. For other CFRs, targeted questioning and advice-offering can bring the existence of a CFR (for example, around performance or scalability) to the surface, and the conversation picks up again in the context of a need from a developer.

The fact that it comes from the field allows for less friction in the implementation itself. The architects don't need to push it so much. It's the architect's job to start the conversation.

About the Author

Rate this Article