How to Build and Run a Decision-Making Architecture Board

This guest post is about collaborative architectural decision making, by way of a cross-organization software architecture board. My former colleague Hans-Peter Hoidn reports on motivation, setup and value of such a board. He provides an exemplary success story too. Enjoy the read!

Motivation and Background

An architecture board of a software engineering project or an IT organization helps making sound Architecture Decisions (ADs). Getting key ADs right is critical for the success of projects and initiatives. Drawing from experiences from many years in projects and workshops with customers, I firmly believe that they must be emphasized even more. For each AD, stakeholders want to know its motivation, the reasons for choosing a particular design option, the discarded alternatives and the related implications including financial consequences.

It is important that there is a sound process in place to identify, discuss and decide on important ADs. I like the mantra “Doing the right things right”. Mainly for “doing the right things”, which include key decisions like choosing a reference architecture, a framework, an integration style or a software product, a solid base is required.¹

Establishing an architecture board helped me and my clients in various situations to drive the discussions and finally agree upon important ADs.

Problem Statement: AD Making Process Required

Overcoming the lack of transparency concerning decisions within software development can be addressed by documenting systematically decisions with Architectural Decision Records (ADRs). For instance, the Markdown Any/Architectural Decision Records (MADR) Template is suitable for the description of ADs with details such as chosen alternative and its consequences; many other templates are available.²

The question that I want to address here is:

What is a good process to obtain the content for the ADR documents?

This has to do with people and how they work together.

It is a good practice is that decisions are not taken by accident, but discussed, reviewed and communicated. Usually there is no single truth for a problem to be solved; therefore, an adequate practice is required for evaluating possible solutions and selecting the most suitable one for the given context. In addition, implications like costs and risks must be assessed. We must keep in mind that final approvals are often not given by IT experts alone, but also involve higher-level management.

The Architecture Board

According to my experience, an architecture board formed by architects as well as developers can play a key role within a project or an initiative (that may be a program with multiple projects, an organization within IT, or something similar). Let me elaborate.

Why an architecture board, what is its mission?

The mission of an architecture board is to decide on architectural issues (no surprises here). Many ADs must be taken when a project starts — defining system boundaries, introducing logical and physical structures, establishing design principles and policies for development. ADs are also necessary when pain points must be resolved, often related to system qualities such as performance targets.

An architecture board is the group of architects and senior developers of a project, a program, or an organization that are empowered to take decisions or to prepare decisions concerning the architecture of IT solutions. The board must not only discuss the technical aspects but also the impact of the decision, including costs and risks as well as impact on the schedule of directly involved or indirectly affected projects. The key point is that there must be an agreement that an architecture board is established and that architecture board meetings will make ADs. It requires a large amount of trust from the management.

An architecture board comes together when a decision must be taken, or a pain point must be resolved. When a project starts, this might be quite often, for instance weekly; when development is going on, the board meets on demand only when pain points are faced. Usually, the lead architect calls for architecture board meetings, possibly on request by one of her/his colleagues.

An EuroPLoP 2018 paper describes the motivation for a board as this: “[…] the overview of what is going on has to be kept in sight to derive suitable architectural and technical decisions. In an environment without a proper decision-making process in several development teams, or without a clear definition of roles and responsibilities a centralized architecture board makes no sense. There is need of dedicated maturity steps to traverse through to reach the goal of a distributed realization environment with as few as possible bottlenecks due to mutual discussions with a centralized responsibility to gather knowledge about on goings even considering existing technical debts.”³

How does an architecture board work?

In order to take a valuable decision, the task of an architecture board is to discuss the various possible solutions for a given problem situation so that all opinions come to the table and finally a decision can be taken. This implies that members of the board prepare themselves by thinking through the opinions and, if necessary, prepare an appropriate presentation of their thinking. A final decision is much better accepted when all members of the board had brought their opinions forward and consensus is found sitting together in one room. Experiences show that an architecture board meeting should be a face-to-face-meeting whenever possible.

Decisions must be communicated appropriately such that stakeholders are able to support them. A document that communicates a decision should not only describe the decision outcome but also the alternatives discussed and the reasons why they were discarded. Moreover, consequences for the project, program or the organization must be highlighted in order to get support and approval from management. A template such as MADR or Y-statement (see above) can help documenting. Critical aspects like risks and costs must be made transparent such that management is able and willing to approve the decision.

What is the value that an architecture board provides?

An architecture board provides the “involvement of the community in the decision making” and thus for “longer lasting designs” as mentioned in the post “How to review Architectural Decision Records (ADRs) — and how not to”.

Moreover, establishing an architecture board can improve the quality of the decisions made by following a broad set of good practices that its members bring in and share with their colleagues.

Example

Here is an example. Four years ago, Microsoft unveiled plans for the evolution of the .NET framework and announced that WCF (Windows Communication Foundation) will no longer be supported in the new framework releases. Therefore, it had to be decided if the development of an IT system should move to another communication framework or go on as planned with the current release, replacing WCF later. The critical AD was whether the new framework should be based on RESTful HTTP or gRPC. Microsoft recommended to move to gRPC, see this excerpt from the eBook “gRPC for WCF developers”.

The board of architects and developers came together as a group of eight people experienced with various technologies and architectures. Every person had enough time to present his opinion. The decision outcome was RESTful HTTP, with one reason being that it was already used in other parts of the system. The goal of the architecture board was to obtain a description of the AD with motivation, reasons for not using gRPC, and implications (mainly time and costs for replacing WCF) that could be presented to the project manager and the stakeholders.

The process worked as follows: As soon as the problem had been recognized, members of the development team had informal discussions, which then the lead architect consolidated in a document that was an early draft of the final ADR. The lead developers and technical architects were invited to the board meeting and asked to prepare and provide a short statement of their opinion, including consequences they faced, risks and opportunities. The board meeting was not limited in time in order to obtain a well-founded decision and an agreement of the board for the decision. Although there were different opinions at the beginning, the architecture board achieved the decision unanimously within one afternoon.

The lead architect was able to finalize the ADR, to work out appropriate presentation decks with which the decision could be presented to various stakeholders. Obviously, the decision had costs and impact on the project schedule but mitigated risks. Careful preparation of the AD and a transparent description in an ADR helped to get management approval for the decision.

Supporting Consultancy

There are situations where an architecture board needs some consultancy for its decision. Experiences suggests that this should be done in a two-step process, which may include a workshop involving external consultants first and an internal meeting after that. In such situations it is important that the results from the consultancy step can be used as input for the internal decision step.

As a consultant and technical sales specialist, I organized and held numerous such workshops. The setup was such that the as-is situation was discussed, and possible to-be situations addressed. When consulting, I provided both findings and recommendations, formulated in a constructive way so that it helped with the final decision. A final presentation of such a workshop included the arguments for the decision, and some of the impacts. I recomment to work out an early execution plan with the customer providing next actions and steps on a timeline for the upcoming weeks and months.

Conclusion

Well-described and grounded ADs are key for the success of IT development projects. An architecture board and a suited decision process are key for well-founded ADs.

In addition, well-described ADRs are key for a good communication between architects including IT development and management. Well-described and agreed upon ADRs that highlight impact such as cost and risk make it easier for stakeholders to understand reasons and implications.

This post complements previous ones on good practices and anti-patterns for AD capturing and reviewing.

Hans-Peter Hoidn (LinkedIn profile)
May 11, 2023

Notes.