Architecture Review Boards

While going through the process of establishing the Office for Enterprise Architecture at Blue Cross and Blue Shield of LA there was a clear gap in architecture reviews and the validation of decision making in a consistent manner. This  was a problem that was occurring across the company.

After careful consideration and an analysis of the company’s maturity, culture and organizational appetite it was clear that an Architecture Review Board (ARB) needed to be established. This is one of many governance functions that will be rolling out over the course of the next year or so. Timing was right for this based on a variety of factors.

Below are the specific drivers that support the creation of an ARB:

• Better management of budget and overall spend on solutions
• Transparency in decision making
• Fully qualified and informed decision making
• Reduction and management of complexity
• Greater understanding of the solution portfolio
• Greater ability to proactively eliminate problem solutions
• Solution reusability through standardization, topologies and reference models
• Opportunities for solution consolidation through the greater visibility
• Awareness and education of architecture thought processes will organically occur and will ultimately lead to behavior of proactive solution rationalization

This inspired me to share my experiences with the creation of an ARB. This post will go into the details of answering the questions surrounding the purpose and goals of an ARB. I will write subsequent posts on other aspects such as; establishment of ARBs, Key Metrics, proven practices, supporting processes, etc.

Let’s start out with the several sources out there that have defined ARB’s for us:

1. TOGAF ARB – One of the more comprehensive definitions of an ARB. However, the ARB descriptors here will only define an ARB at a high level and will require work to go to the next layer of detail to make it a fit for your organization.
2. FEA Enterprise Architecture Review Board (EARB) – This document shows a case study with highlights on the FEA model for an ARB. It is important to note the separation of the ARB from what they call a Technical Review Committee (TRC). There is separation between the road maps, strategies, policies and standards creation from the validation of architecture compliance.
3. Network World – Do You have an ARB? – This post has a data communications slant (given the source) and focuses on more of the tactical issues. There are some good recommendations here. For example, be careful of the individuals you select for your ARB. If incorrect ones are selected it could mean a bad reputation for your board.
4. EA Wiki – Architecture Review Board – This site has a very high-level definition that blends a few functions together into one. While I disagree with the approach others may find it useful.
5. National Institutes for Health EA Portal – ARB Desc. and Charter – Here is an example of an implementation of an ARB.

ARB Definition

Above are a few references to ARB’s that are publicly available. Surprisingly enough there wasn’t much out there in the form of a definition except for TOGAF. But even TOGAF wasn’t very explicit in one definition.

Here is my definition:

An Architecture Review Board (ARB) is responsible for validating, recommending, and approving solutions supporting the business that meet a defined criteria, executed through a set of processes to manage outcomes, exceptions and all decisions that will be in turn cataloged to support future decision making. Realized through the ARB, is the alignment to the strategic goals of the company. Adherence to the company’s principles, policies, standards, and the defined industry proven practices are followed ensures this alignment.

As specified in the definition, the purpose of the ARB is to ensure that new and existing solutions and changes to existing systems are consistent in supporting the strategic and financial objectives of the company.

ARB Goals

The goals of an ARB include:

1. Mitigate risks and impacts to the business through due diligence and more informed technology decision making processes.
2. Optimize and control costs through informed decision making, technology reuse and consolidation.
3. Establish Enterprise Architecture and Technology Compliance to manage complexity in the enterprise.

These goals are rationalized through a series of activities:

• Validation, identification and communication of significant architectural gaps and risks that a solution may posses.
• Enable visibility and cross-organizational transparency in decision making.
• Streamlined process for the analysis for Build vs. Buy vs. Externally Managed solutions
• Communication vehicle across and up the organization that will illustrate the overall health of solutions architecture.
• Ensuring that solutions leverage the organizations and the industry proven practices to architecture work.
• Quantitative and Quantifiable decision memos that will allow senior decision makers to make informed decisions.
• Provide an overview of the compliance of architecture to mandated enterprise standards.
• Identify where the standards themselves may require modification and propose these modifications to an Architecture Guidance Team.
• Identify point solutions that may qualify as reusable enterprise services.
• Identification of emerging technologies and how they are applicable to the company.

Please note, for organizations that wish to setup a board you should proceed with caution. If there isn’t a clear definition of what the ARB means to your organization it could be flawed from the beginning.

There are some basic questions that you should be able to answer before embarking on an ARB. Some of those include:

• What is the purpose or charter of the ARB?
• What value does the ARB bring to the company?
• What value does it bring to me or my team?
• When should people engage an ARB?
• How will an ARB help reduce complexity and manage risk?