Architecture Review Boards

I can imagine someone waking up one day and thinking: "The sun is too old! We need to find a more innovative way of supplying the earth with heat and light". That would indeed be a profound venture. The point is, not every ancient phenomenon is due for replacement. Bringing it home, we do not replace ways of working simply because a smart guy in an ivy league school did an award winning study. Context is key. Many modern practices may turn out impracticable in certain organizations or industries. Thinking through before you take up your next best practice is great practice.

As a rule, humans do not like rules. Well, except when they are the rule-maker or when the rule gives them more time to get prepared for the inevitable change - stalling strategy. In today's musing, we will explore the ancient architecture review boards and how they fit into today's enterprise architecture practice or otherwise. This is a good place to mention that amidst the global agitataion for faster ways of working, TOGAF 10 maintains the need for an Architecture Review Board (otherwise called an Architecture Board).

According to The Open Group ,

A key element in a successful Architecture Governance strategy (see 3. Architecture Governance ) is a cross-organization Architecture Board to oversee the implementation of the strategy. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.

I think the key expression here is Architecture Governance.

Architecture Review FAQs

What is an Architecture Review Board?

An architecture review board is a governing body that is responsible for ensuring that the development of architecture within an organization aligns with the overall enterprise goals, principles, and standards. The TOGAF Standard places Architecture Boards very close to executive leader because the tilt in the Standard is alignment of architecture with strategy. For this to work, leadership has to be committed.

TOGAF also emphasizes governance of both enterprise architecture and sub-architectures e.g., solution and system architectures. It becomes obvious in practice that the development of solution architectures must be governed to ensure alignment since each solution (initiative) contributes to architecture change overall.

Why Do We Need a Review Board?

One of the most advertised outcomes of an enterprise architecture practice is business and IT alignment. It is also a well know fact that enterprise architects are more likely to provide options to decision-makers than to make game-changing decisions by themselves. This of course depends on the kind of organization in question.

Business and/or technology strategy can be defined in the absense of enterprise architects or long before they are hired. For the sake of argument, we can assume that once a business is ready for digital transformation or the signs of chaos due to expansion are showing up, they hire an enterprise architect or consulting firm to help shape transformation. Once that initial strategy is aligned and the technology roadmap is defined, what happens next? We must go into operational mode.

Governing architecture is one way enterprise architects, working with other architects and stakeholders, try to ensure that with each new initiative, we are moving towards the target state enterprise architecture we agreed on in the strategy, blueprint, technolgy roadmap and all that. Chances are that Architecture Boards are more operational in some organizations than others but in my experience, we were deeply involved in almost every major technology initiative.

What Exactly Are We Reviewing?

One interesting question that typically shows up when we tell people we are doing architecture reviews is what constitutes an architecture change in the enterprise. Can we not handle such changes in a Change Advisory Board (CAB) defined in ITSM. In my opinion one needs to stick with what really needs architecting and can be done in an efficient way without causing undue delays. The scope may be determined by the degree of involvement the enterprise architecture practice within the organization is willing to embrace.

One architect might consider updating a line of code an architecture change while another may forget software all together in favour of infrastructure. Most developers are not very happy to be "stalled" anyway. Questions we would typically ask to determine whether an item needs to pass through an ARB are:

• Are we introducing a new component?
• Are removing any component(s)?
• Are we opening up new communication through network ports?
• Are we enabling new software funtionality?
• Are we dramatically changing business processes?

The rational driving these questions us the fact that at its core, architecture is about components and relationships. While solution and system architects are mostly concerned with technical components and projects, enteprrise architects try to stretch the thought to the people, process and technology dimensions - a broader scope of relationships across solutions and a long term view. At the end of the day, the key questions that may need to be answered are:

• What is the impact of this?
• Is there any other way to do this?
• Are we following our rules?
• Are we breaking any rules?
• Is this sustainable?
• What might be the next iteration?
• Do we need to break some rules? [dispensation]

"Governance is essentially about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives." - The Open Group

How are We Doing These Reviews?

The question of process for more operational architecture reviews typically starts with what the entry point should be for initiatives? When a new initiative is birthed, should the business go through the CIO, Business Analysts or the IT Service Desk. Well, as with many things in technology, it depends. The key aspects that must be catered for in any process are likely to be:

• Understand the requirements
• Document the requirments
• Design the solution
• Build the solution
• Deploy the solution

The exact translation of these to steps to formal processes will be determined by your scenario in the organization, whether you have an agile or waterfall tilt and which industry framework you might want to adopt among others.

This is good place to mention the difference between enterprise architects and business architects with reapect to understanding and capturing business requirements. Enterprise architects (and business architects) are concerned with requirements at a strategic level. They use tools such as Business Capability Maps to understand WHAT the business does and then deduce the mechanisms that need to be rolled out through initiatives to help the business do WHAT better.

Business analysts are more likely to be focused on specific solutions - mapping exact business requirements to the immediate project. Enterprise architects anticipate the ask in context while business analysts stay with the present need. That said (written), if you have worked in any complex organization, you will agree with me that the definitions of these similar functions are often not as clear as we put them in writing.

In the process flow that leads up to the ARB, a business analyst is more likely to to be an entry point because we are dealing with specific initiatives. It is likely that an initial list of such initiatives are the result of strategic planning, business capability mapping, technology roadmapping and all that depending on the maturity of the organization. These strategic stuff may have been developed by enterprise architects in consultation with leadership and/or consultants.

When Do We Do These Reviews

Maintaining a cadence is typical of ARBs. Weekly, bi-weekly, monthly? It could depend on whether your ARB has a more strategic tilt as opposed to an operational one. It could also depend on the volume of initiatives you are dealing with the and rate of change. In my case we had a weekly cadence in my previous organization. Leading up to the weekly cadence were private reviews with the Enterprise Architecture Core Team and another review with technology subject matter experts.

Multiple reviews of solution architectures leading up to the equivalent of an ARB were necessary because it was an unspoken assumption that if the initiative got turned down at the ARB or equivalent then the architects had not done a good job. The Enterprise Architecture Core Team was partly responsible for ensuring that the architecture was aligned with architecture principles, component choices were consistent with technology standards, due diligence had been done and so forth. It wasn't merely about pushing paper, a lot of thinking had to precede the presentation. If initiatives weren't ready, the meeting was rescheduled.

Who Should Be in an ARB?

TOGAF recommends five members of an ARB with some mechanism for rotation and good leadership representation. In my experience the CIO was essentially the Chief Architect. There has to be enough political power backing the ARB for it to be a useful governance mechanism. At the minimum, senior leaders from the technology team should be involved along with enterprise architects. Attempting to skip reviews was considered a serious enough offence for an appearance at the Disciplinary Committee.

This view drove us in my time to collaborate with the Change Advisory Board (CAB) handlers to help ensure an ARB review was part of the checklist for presentation at CAB. We also had to be at CAB to raise concerns where necessary and enforce the rule that architecture-impacting changes were not ready for CAB if they hadn't passed through ARB.

Review Boards in the Age of Agile

Agile proponents generally have mixed views on traditional Architecture Review Boards (ARBs) because ARBs are often seen as formal, structured, and process-heavy, which can seem to conflict with the Agile methodology's emphasis on flexibility, speed, and decentralized decision-making. However, this doesn't mean Agile and ARBs are inherently incompatible—there are ways to align the principles of both.

Modern Enterprise Architecture conversations often highlight embedding architects within solution conversations rather than waiting for a formal review at an ARB. There is also the practice of avoiding strict governance and rather providing guidelines in order to make room for more creativity and avoid the "ivory tower" feel of Enteprise Architecture Management. But then, some schools of thought do realize that for large organizations, some kind of order is inevitable.

Wrapping it Up

The thirst for innovation does not erase the need for appropriate governance. This is particularly true in industries like banking where governance is essentially part of the culture. No matter how fast you want your money to move across banks, it must be checked for Anti-Money Laundering compliance and so forth.

In the world of traditional Enterprise Architecture Management, Review Boards are a fundamental mechanism for governance. If the intent is to journey towards the target state, someone must be making sure that each initiative is contributing to that journey rather than creating more chaos.

How is it at your firm? Do you run Architecture Review Boards?