Scaling Software Architecture Through Conversations: The Consulting Process
Andrew Harmel-Law recently published an article describing a decentralized and scalable software architecture process based on the “Advice Process”. The consulting process promotes software architecture by encouraging a series of conversations guided by an empowering, almost anarchic decision-making technique.
According to Harmel-Law, CTO at Thoughtworks, the consulting process is simple. It includes a rule and a qualifier.
Rule: anyone can make an architectural decision.
The qualifier: before making a decision, the decision maker must consult two groups. The first concerns all those who will be significantly affected by the decision. The second is made up of people with expertise in the area where the decision is made.
It is important to note that while decision-makers should actively seek advice, they are not obligated to accept and implement it. They have full latitude to make the decision they deem appropriate. As a result, decision makers fully own and commit to their architecture decision and implementation.
Harmel-Law’s primary motivation in implementing the consulting process is to scale architectural decision-making. As organizations grow and adopt a mindset of multiple autonomous teams working independently to achieve a common goal, it has become apparent that these teams have to make architectural decisions, and “traditional” approaches do not. are not scalable.
[…] using them [traditional software architecture approaches] In the world of continuous delivery of autonomous teams, I have repeatedly found myself faced with an impossible task: to be everywhere, tolerating large contextual deviations and not blocking anyone.
It made me wonder. Was there an alternative?
There was: I stopped making 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, architects are now responsible for initiating the right conversations with the relevant decision makers, providing trusted advice, and guiding developers towards an optimal overall solution.
Harmel-Law then rounds out the advisory process with four essential techniques that guide developers toward a cohesive whole that incorporates a longer-term perspective into those same decisions. The first tool is a reflection and recording tool – the Architecture decision file (ADR). They are lightweight documents, often stored in source code repositories along with the artifacts they describe. A lightweight ADR model structure not only helps in recording architectural decisions. It also helps teams learn how to make architectural decisions. The model works like a thinking checklist and prompts the decision maker to think about and, more importantly, have conversations.
The second tool is allocating a time and place for conversations – the Architecture Advisory Forum (AAF). The AAF is a place and a regular and recurring moment of conversations. Attendees include delegates from each team and key representatives from the counseling process checklist. According to Harmel-Law, “if the architecture is ‘made’ here, and the lessons are shared and learned, then you are a winner.” When conversations happen in an AAF, there is an audience, many people can listen, and everyone can learn. “The amount of organizational, domain, legacy and experiential information and architectural skill deployment shared in these sessions is unlike anything I have ever seen, and although this is a meeting potentially dry, this is the busiest and most widely attended hour of our week.”
The third tool is a light to illuminate a unified goal – the architectural principles that emerged from the team. In a world of highly autonomous teams, they become essential because they allow architects to achieve aligned delivery direction without control.
The fourth tool is a personalized technology radar based on the ThoughtWorks Technology Radar. However, it is tailor-made for the specific languages, tools, and landscape in which the organization operates. Radar helps decision makers navigate the available technologies at their disposal and make better decisions. One way to create such a radar is ThoughtWorks build your own radar.
InfoQ spoke with Harmel-Law regarding the advice process and its implementation following their article.
InfoQ: The heart of the article is the “Counseling Process”. How was it created?
Andrew Harmel-Law: The book “Reinvent organizationsdefines the counseling process in the context of decision-making in trust-based organizations. And in a trust-based organization, how do you make decisions? You trust people to make decisions. liked this approach from a scale perspective. It scales better because a lot of people can make decisions that way. Before joining Thoughtworks, I was leading a team of 36 developers, which later grew to 98 developers. We had to evolve, and I couldn’t micromanage them all, so I thought that instead of making all the decisions, I can trust others to make them, so we started implementing the process of advice for the little things, and it worked. When I joined Thoughtworks and became responsible for various projects on architecture and governance, I thought that the advice process could also be I worked there, and I started implementing it with clients.
InfoQ: What types of organizations would you recommend implementing the counseling process in?
Harmel-Law: We have already implemented the counseling process in various places. We’ve implemented it in startups with super-distributed cultures and old-school organizations with a more centralized culture and centralized processes, and the advisory process seems to work in both. The counseling process itself is central to the idea. However, the other tools and practices such as ADR, AAF, etc., help the process run successfully in these varied environments without deteriorating into chaos or undirected anarchy.
InfoQ: Is the consulting process suitable for working with developers of all experience levels?
Harmel-Law: I saw that the concerns that concern us, the architects, also come from the developers. Not only the team leaders, but also the developers themselves. Once they had the responsibility and sought guidance from others, they quickly learned and reflected on these concerns. The best ADRs I’ve ever seen come from developers who own the decisions and implement them because they care.
In the past, architects asked developers to adhere to architectural principles, and developers either ignored them or reluctantly implemented them. With the consulting process, the principles of architecture are not something that some architects told them to do, but something that they actually apply and find value in, since they are the ones who make the decision. . As a result, all the principles that architects Recount developers to care about – developers do worry because they could see the reason why.
InfoQ: In the article, you mention that you “stopped making architectural decisions. Completely “. What about architects who find it hard to “let go”?
Harmel-Law: The experience of letting go and taking responsibility by teams is new. Nobody gives people that opportunity. Most of my consulting work these days involves getting architects and technical managers to let go. The way it works is to convince the architects to let go for a little while and let them make sure everything goes smoothly.
Architects usually start out fearing it will be chaos. However, you usually see that developers are scared because they’re not used to autonomy, so teams don’t move forward. Architects then end up encouraging teams, actively looking for decisions to be made and helping the team to make those decisions, but only by giving advice, without making the decision for them.
Therefore, you get fantastic conversations because there is collaboration between the architect who knows the big picture and the developers who understand the intricacies of a specific codebase.
Teams running code now have a tool to help them solve problems only they know about and solve them at the scale they want. Architects then realize that they are not giving up control, but can instead spread their thinking and knowledge further. Within about a month, the architects find that others have brought up the issues that they thought only they cared about, and that everyone else cared about.
InfoQ: What about cross-functional requirements (CFRs)? Who can replace them? How to overcome “localized optima” that do not correspond to the global strategy?
Harmel-Law: Everywhere I go there are CFRs defined, but many developers don’t know about them or, worse, don’t care. With the Advisory Process, architects let decisions that assume the existence of CFR come from the field and address them when they arise. For example, at a customer, the developers had realized that the observability was poor and wanted to add a trace ID. The architects could then direct them to a CFR that already existed for this. For other CFRs, a targeted questioning and offering of advice may bring to light the existence of a CFR (for example, around performance or scalability), and the conversation picks up in the context of a need for a developer.
The fact that it comes from the field allows less friction in the implementation itself. Architects need not insist so much. It’s the architect’s job to start the conversation.