By Nick Malik, Digital Transformation Strategist, Chief Architect, former CIO, Servant Leader, Infosys
My colleague Gideon Slifkin posted recently on LinkedIn, listing many of the responsibilities that he attributes to the Architecture Review Board (ARB). The concept of an ARB is widely implemented by Enterprise Architecture teams and his post represents a fairly common view.
In a traditional approach, often cited as being the mechanism promoted via the TOGAF model, a single body of senior leaders are responsible for making key architectural technology decisions across an enterprise. Engineering and Project teams seeking to make changes to the infrastructure would submit architectural reasons and information to the ARB, and the body owns the decisions. Gideon’s post is linked here.
I responded to Gideon’s post that his description is an anti-pattern. I wasn’t being fair by providing a limited amount of information to back up my opinion. Instead of listing out a long reply to Gideon’s post, I thought it would be better to simply post my opinion as a separate article. I don’t want to sidetrack his post or discussion.
Hear more from Nick Malk at the Enterprise Architecture and Business Process Management Conference, Europe, 10 – 13 October 2022, London. View the agenda and find out more here
The Traditional Architecture Review Board
The most traditional approach to Architecture Review Board occurs as a meeting. The meeting may be focused around a single system being reviewed, or it may be a standing meeting that any engineering or product team can present to. There are a couple of inherent inputs to the ARB process. Here are the inputs:
- A motivated team. That team has a change that they have been asked to make. That request came from one or more business stakeholders, and hopefully there’s a good business reason for making that request. (every company has a different way of framing the idea of a “good” business reason).
- A list of one or more architectural models, typically demanded in advance by the ARB itself, for the ARB to review. This could be a system context model, and data flow diagram, one or more sequence diagrams, integration models, deployment diagrams, and data models. Some may be at the conceptual level and others at a more detailed level of abstraction. I’ve seen ARB packages with as few as three and as many as a dozen different models.
- A list of one or more architectural decisions that are being promoted by the team. The team often has an opinion about what the decision should be. Some companies require the team to produce a list of pros and cons for each potential decision point.
- Central architects. This is a group of architects who are responsible for improving specific aspects of the Information Technology ecosystem. These often appear as an infrastructure architect, an information architect, one or more business and solution architects, and frequently a security architect.
In the traditional approach, the team presents their ideas, the central architects question it, and the central architects discuss whether to approve it. In reality, no one wants the risk of these meetings breaking down into an argument so the project team will float their presentation materials to each of the individual central architects in advance. The goal is to get everyone’s feedback in a private setting.
The real-life ARB process can take multiple weeks, during which time the project team creates the large ARB review package, circulates them among the individual architects, takes feedback, submits the final package for review, waits for the meeting, presents the package at the meeting, and then waits for one or more important architectural decisions to be “blessed” by the board.
This approach is not dissimilar to the approach often used by zoning boards and city planning departments. A building architect comes to the city with a complete set of architectural diagrams and presents them to the zoning board for approval. The relationship between the architect and the board is fundamentally an adversarial one.
The output of the traditional ARB is a set of “approved” architectural decisions.
What’s so bad about that?
There are some serious drawbacks with the description of an Architecture Review process as described above. The two largest drawbacks are:
- The process removes decision authority for any of the architectural choices from the engineering teams and shifts it to a central team of architects. This has a seriously demotivating impact on the engineering team. Innovation goes to the ARB to die. The assumption that the engineering team has less to say about architecture is a flawed one. Unlike the building trades, there is not a vast chasm of education and credentials between a software architect and a software developer. And unlike building architecture, we don’t build software with the expectation that there will be no architectural change to the end product throughout its life. The exact opposite is true.
- There can be a very large gap in time between the point where the team asks an architecturally relevant question and when the team receives an answer to that question. This can delay the project by weeks. If this happens more than once in the lifecycle of a project, it could have serious consequences for the timely delivery of the overall program. The cost impact on the program may exceed the total benefit to the business provided by architectural consistency.
Maintaining control while reducing cost
While this article presents an alternative approach to architectural governance, this should not be construed to mean that an organization would benefit from removing the architectural review board completely. There is still a role for the ARB as a “last resort” for resolving disputes and creating policy. However we are suggesting that a major shift in power and control should occur.
Instead of the architecture review board being the arbiter of all decisions, it should become the point where 95% of all architectural decisions are brought for visibility and awareness. The ARB itself demands nothing except that the project architect and a single trusted central architect agree on the design decisions for the project.
Let’s look at what a more collaborative process looks like.
- As the IT project portfolio is being created, most of the programs can be divided easily into “design changes,” “architectural changes,” or “both”. Those that are design changes (typically system maintenance projects) require no architectural governance. They are automatically approved to proceed. This determination is made by a member of the Enterprise Architecture team, preferably the lead architect for the area of the business impacted most significantly by the suggested change.
- Early in the planning for a project involving architectural changes, a project architect is assigned to it. This is a member of the engineering team that will do the work, and is directly assigned to the project. They have a stake in the successful delivery of a quality system.
- That project architect spends a week creating a sketch for how the system could be developed and shares it with a working group of architects (unsurprisingly, I call this the “architecture working group” or AWG). The AWG group is made up of the central architects described above as well as other project architects. A member of that group is assigned to oversee the new initiative (or not, if the AWG decides not to oversee it). The sketch can be any reasonable model that communicates what is changing and gives a hint about the architectural decisions that may need to be made.
- The first assumption is that the project architect is honest, and is not trying to “squeeze” an architectural change past the governance process. In my decades of experience in Information Technology, I’ve found this to be true in nearly every example. A dishonest architect is truly rare, especially since they know that any significant architectural change will be noticed eventually. However, this decision to trust the project architect is one of the most significant changes in the overall governance process.
- At this point, the assigned member of the Architecture Working Group is responsible for creating a conversation with the project architect. The two of them may meet weekly or even more frequently if the need arises. The overseeing architect may create models for the project to follow, and would certainly be required to recommend any standard technologies that have been adopted elsewhere in the organization. They are accountable to the project for getting decisions made quickly.
- Here is where the second major change occurs. We trust the assigned architect to represent the needs of the enterprise. They must be aware of any standard technologies as well as architectural decisions made in other programs. They have to be involved with creating the technical strategy of their division or the enterprise as a whole, and they agree to deliver that strategy through their assigned programs. The Architectural Working Group has to maintain a high level of trust with both the project architect and their own team member, the assigned oversight architect.
- The oversight architect may bring multiple discussions to the working group to get insight and, if needed, consensus. However, most of the time, the decision for what technology is used, and how it is used, is suggested by the project architect and approved by the oversight architect.
That’s it. That’s the governance part. The oversight architect is accountable for creating the package of models for the ARB, even though the responsibility may often fall to the project architect to create the models. At no time can they make the excuse that “the project team is ignoring me.” The project team moves forward with the decision agreed to by the project architect and their assigned oversight architect. For the vast majority of architectural decisions, that level of review is sufficient.
By the time the Architecture Review Board meets to review their package of information, the engineering team may have already implemented the agreed change.
Of course, the Architecture Review Board still exists. It still meets periodically. It still provides the “stamp of approval” on architectural decisions, but the decision itself is made by the project architect and the overseeing architect: two people in a room, negotiating. For 95% of all architectural decisions, the ARB will take a look and sign off on it.
In Gideon’s post, the ARB demands many things of a project. In our model, the Architecture Working Group creates the templates for the different types of models. The AWG decides what standards to adopt and suggests them to the ARB for final approval while immediately implementing any needed changes with an engineering team.
Patterns and Anti-patterns
These two approaches may seem similar and in many ways, they are. Each has architects reviewing the work of other architects, in an effort to reinforce good decisions and ensure that no one is left doing design without any guidance or support. That said, there are some specific indicators to pay attention to, that will help you decide if your governance process is sufficiently clear to achieve this goal of faster and more scalable architecture:
- Who creates the project-level architecture and high level design? Traditionally: the project architect. New model: either the Project architect or the oversight architect as skills and timing allow.
- Who is accountable for knowing all the technology and practice standards? Traditionally: the project architect. New model: the oversight architect. She or he is responsible and accountable for educating and guiding the project architect on what the standards are, why they matter, and how to use them on a project.
- Who makes the decisions that the engineering team can proceed with? Traditionally: the team has to wait for an ARB review (sometimes weeks later). New model: as soon as the oversight architect and project architect agree on a direction. (can be an hour).
- Who is responsible for bringing innovative ideas to the design process? Traditionally only the oversight team or the ARB is allowed to truly innovate. New model: everyone. Engineering, project architects, solution owners, delivery managers, oversight architects, or Uncle Martin. Design is collaborative and open. No good ideas are off the table. Find an agreement that works within the standards and you are off to the races.
- Who grants an exception to the standards? Depends on what we mean by “standards?” The decision to use a non-standard technology still requires sign off from the ARB, because of financial constraints. However, the decision to use new designs, new patterns, new practices, and new approaches can be made by the project architect and the oversight architect working together to deliver an excellent project.
Wait, this is a lot of change!
Yes. It is. That’s why my employer, Infosys, can help you through it. We are not the only top-tier consulting company promoting a more agile approach to Enterprise Architecture. But we have years of experience with this model and some of the bruises to show for it. We can help.