Mike The Architect

Setting Architecture Review Board Member Expectations

In my previous post Defining the Anatomy of a Architecture Review Board we talked about getting the right people together to assemble your ARB. In this post we will talk about the expectations of those members. 

What you will find with ARB’s is that “the devil is in the details…”. This is especially true for the details of an ARB’s membership. I have found that if you don’t properly set expectation on the membership it can cause some major disruptions in the operations of the ARB.

There are four major expectations every board should define to ensure success. Those expectations are:

• Time – Must allocate [x] to [x] hours to the ARB on a weekly basis for architecture design reviews, exception management and ARB tasks. [x] hour should be dedicated for the meeting itself. This is a minimal of [x] hours a week with the potential of [x] hours a week.
• Meeting Attendance – Meetings will be held bi-weekly. The expectation is that a primary representative is at the meeting and if that individual cannot make it, then the designated secondary individual should attend the ARB.
• Accountability – Members are accountable for their reviews, decisions and deliverables to bring to the ARB. The Chief Architect evaluates the performance on the members on a monthly basis and reports status to the executive sponsors.
• Subject Matter Expertise – The ARB team members are to bring their subject matter expertise to the ARB. Specifically to provide the following:
  • Gather and analyze materials as applicable to their domain of expertise
  • Identify impacts of emerging technologies with current portfolio of assets
  • Provide qualitative and quantitative feedback
  • Ensure discussions are fact based and practical
  • Provide solution recommendations and/or methods for exploration of problem
  • Focus on problems holistically across the enterprise that includes the business, operations and IT aspects.

 

While there can definitely be more expectations that can be set, these general purpose expectations can be leveraged as a base for your ARB.

Defining the Anatomy of a Architecture Review Board

Continuing my series on describing Architecture Review Boards I will discuss the people that will participate in an ARB. We will take a step back to provide context of the membership with a domain based model.

We should first start off with understanding that the ARB is comprised of leaders across an organization with decision making authority. This federated model will allow for cross organizational visibility and coverage of solution reviews. The federated model is based on architecture domains.

Architecture domains are logical representations of areas of concern or sometimes called cross cutting concerns. There are a set of base domains that can be used but each organization has it’s own vocabulary and ways of describing these domains so it is best to use them as a reference rather as authoritative.

Below is a sample of a set of domains:

You can quickly see that these domains are broad. They should span IT, Operations and Business lines. Another observation you may have is you see “Data” listed as a domain. As a general practice I stay away from using data as a domain as it should be a sub domain, “Information” should be the domain here but in this case it was politically more accepted to use Data rather than Information.

With the domains there will need to be some flexibility and keep in mind that nothing is set in stone. Refinement happens naturally as you start to leverage the model.

With these domains there are sub-domains that allow for deeper separation of logical areas. As shown above, the reference below is an example of a set of sub-domains that can be used to describe in further detail your environment.

The above set of sub domains should not snap to an organizational model. These domains and sub-domains need to have subject matter experts aligned rather than an organizational hierarchy. If you have a matrix style organization than there would most definitely be alignment however.

Now that we are talking about people, how do we snap people to our domains and sub domains? What I show below is the separation of the domain and sub-domain.

We have a one to one mapping to the domain and to a role. The two roles are:

• Architecture Domain Owners – Provides leadership to drive excellence inside a domain group. There will be one individual per domain that will be ultimately accountable for the domain. The Domain Owners will also be the final approver of the standards that are developed out of the domain.
• Architecture Domain Experts – These individuals are the implementers and researchers that develop the standards for the organization. They will have responsibilities to manage the portfolio of standards that they have direct ownership over in their sub-domain.

This model provides us with a community driven approach to developing the organizations standards.

Now lets overlay our domains over our governance bodies, namely the ARB and AGT. You will see a nice alignment to these governance bodies.

Additionally, there is a healthy balance of membership of these functions. Based on our definition we have the right people in the right function. See below for the definitions from Relating Architecture Review Boards to Other Architecture Governance Bodies:

• Architecture Review Board – Validates and approves solutions based on their alignment to the strategic imperatives of the organization.
• Architecture Guidance Team (AGT) – This team defines the principles, policies, standards, frameworks and solution guidance that is published to a repository and portal for consumption by the architecture community and ARB.

Once you segment out the right people for the right governance functions we now need to organize the ARB with roles and responsibilities. There are four roles within the ARB:

• Executive Sponsors – While the executive sponsors do not attend the ARB meetings they do approve the ARB processes and extend executive support when needed. These individuals are usually SVP’s or CxO level individuals.
• Chairman – This role is responsible for running the meeting, acting as the mediator, vetoes when appropriate and has the accountability over the ARB’s overall role and effectiveness in the organization. This individual is usually the Chief Architect of the company.
• Voting Members – Domain owners are the voting members. The domain owners provide subject matter expertise for their domain and have voting rights when it is time to approve a solution.
• Non-Voting Members – These individuals are either the teams proposing solutions or supporting resources for a evaluation. These members are usually not the same and are transient.

To qualify for membership on the ARB, members should be knowledgeable and experienced in their respective areas, empowered to act as a spokesperson for their team, and available to attend the meetings and perform follow-on analysis work.

It is important to setup these roles and communicate them to the company. Once the definition and communication plan has been defined, as a good measure to ensure that every ARB is successful there should be a primary and secondary defined. See below for an example:

The primary will be the domain owner as we discussed earlier, and the secondary is usually one of the sub-domain members.

Relating Architecture Review Boards to Other Architecture Governance Bodies

As you begin to develop an Architecture Review Board (ARB) the question of the bigger picture comes up real quick. There are several ways of looking at the ARB’s function in the enterprise.

One way to look at an ARB is to consider the ARB the policy setting group and the architecture validation group. I do not share that opinion. Blending the decision making authority with the rules and policy authority introduces a great deal of conflict of interest. When combining these functions the group loses focus and mixes standards setting with the validation of IT architectures.

Below I think there is a better way. I have outlined a model that shows how to execute an architecture governance structure that I have used in my past EA organizations and plan to continue to use on a going forward basis with my EA organization. 

As shown above there are three main governance functions. Each one has a very specific purpose.

• Architecture Review Board – Validates and approves solutions based on their alignment to the strategic imperatives of the organization.
• Architecture Guidance Team (AGT) – This team defines the principles, policies, standards, frameworks and solution guidance that is published to a repository and portal for consumption by the architecture community and ARB.
• The Office of Enterprise Architecture or Architecture Engagement Services – The enterprise architecture organization facilitates and drives many of the governance functions. While Enterprise, Domain and Solution Architects are not the sole decision makers, given the distributed domain model, they are the thought leaders in the organization to be the agents of change.

To further explain this concept I use an analogy that I have used for the past 5 years that really resonates with folks is using the US government as a parallel to this governance model. See below:

You can see a ton of similarities here. I break these three forms of government into the following activities of the EA function:

• Judge It - This area goes into the governance activates of an Architecture Review Board (ARB). Ideally ARB's should have limited power and only have the ability to review architectures not to create the laws (i.e., standards).
• Standardize It - When we talk about standardization this is the activity that forms virtual teams of domain stakeholders to build what is commonly referred to as Principles, Policies and Standards.
• Execute On It - The executive branch in reality is the "commander chief" that is the official spokesman and stimulates action in time of need. Likewise with EA's on strategic projects and management of future strategies.
  Like with all analogies it's not 100% accurate but it can be a power tool to convey a message.

OR

Architecture Review Board = Judicial Branch

Architecture Guidance Team (AGT) = Legislative Branch

The Office of Enterprise Architecture or Architecture Engagement Services = Executive Branch 

The point of the analogy is not for communicating with people whom already understand EA but rather others such as developers, business representing or senior IT decision makers.

So what's the point here for EA's? Being able to articulate your function and purpose to your audience in terms they understand will greatly help you in your endeavors. This allows your audience to understand what you do and how you can help them. On the flip side, if they do not fully understand your role there is a good possibility that they will not engage. This isn't because they want to, but because they do not know that they should.

What this model provides us with is a clear separation of duties but also ensures that the right people are in the right governance function. When we look at the ARB, we want to have senior IT decision makers in the room evaluating and validating designs to ensure alignment. If we had subject matter experts in the ARB, the room could be filled with a lot of people and a lot more opinions. The ARB should be a tight group of leaders of no more than 10 –12 voting members.

The AGT on the other hand, should be filled with SME’s as they best know the technology sets and most likely will be accountable for them as well. The reverse is true for the ARB members. We wouldn’t want senior decision makers driving a platform or protocol standard.

In a future post I will detail out these members, how it all fits together and their roles and responsibilities.

Keeping in Sync

As you can see from the first model of how all of these functions interact there is somewhat of a lifecycle we are defining with regards to the technology life cycle of the technology portfolio and the architecture repository of knowledge. Since the AGT and the ARB are tightly connected and have integrated processes and transparency the knowledge gathered by both bodies is integrated as well. This in turn keeps this information base always up to date without a separate function in charge to constantly chase people down for information.

You will need a librarian, an ownership model and stewardship thought through but these activities should be light since we are updating this base as an output and/or input to our enterprise processes.

An added benefit to this model as well is the traceability aspects. When using the Architecture Metadata Repository as your main way to validate projects tracing back to business capabilities, goals and objectives is very achievable. Additionally, this can be linked to Business Reference Models (BRM) or Performance Reference Models (PRM) as shown in FEA.

Establishing an Architecture Review Board

In my last post I talked about the definition of an Architecture Review Board (ARB), let’s talk now about what it means to create one. As we talked about in the last post, establishing an Architecture Review Board (ARB) is the best way to facilitate how IT decisions are made across the enterprise. Eliminating the behavior of making architectural discussions in a vacuum and providing visibility to how and why IT decisions are made. If done right, this should result in proactive decision making and raising the education across the enterprise on architecture trade-off analysis.

Keep in mind that establishing an ARB is often times a challenging feat. Introducing this function will effect the core of your Software Development Life Cycle’s (SDLC). This has the potential of touching everyone in the organization, so it is important to get it right.

If an ARB is new to you and makes sense to your organization there are some preliminary activities you are going to want to do in the beginning. Just like with most things in the architecture world you will have to sell, sell, sell…

It is very important that one of the first things you do is to ensure that your approach is bought into by the executive leadership team such as VP’s, CTO’s and CIO’s. Do this early and continue to engage all through the process. Their buy-in will ensure that your ARB get’s top down support.

Establishing support from the top isn’t the only support you will need. Gaining the support of the architecture community within your organization is vital. However, to get things rolling in the right direction you will need to establish the accountabilities and the process frameworks that is fully endorsed by your CIO.

Below are the general steps that can be used to create an ARB:

While there are many activities listed in the steps above, there is further decomposition needed. Ideally, this would be the project plan that is created and the numbered chevrons (Initiate, Plan, Design, Create) would be high level milestones.

Along with these steps there are key items to consider when establishing an Architecture Review Board:

1. Build the Case – This is your business case proposal to present to senior management. This is usually in the form of a PowerPoint deck that delivers the key points at a level that senior management wants to see. It should contain the value of such a board. Understanding what Key Performance Indicators (KPI’s) should be derived will aid in your proposal. You should specifically get ahead of some common questions regarding overhead and bureaucracy.
2. Do Just Enough ARB - Determine your Enterprise Architecture Capability and IT Organizational maturity to derive how your ARB will function. Remember, you should have a multi-program approach to the ARB. You will not achieve the desired state overnight.
3. Gap Analysis - Align ARB with the current governance structure and determine gaps that should be filled. Keep your eye on the high value, low friction items to tackle first in the beginning.
4. Communicate - Build the ARB Communication Plan and keep to it. It is critical, especially in the creation of the ARB framework to keep stakeholders and customers of the progress and decisions for the board. After the creation of the ARB it will be important to send out communications of decisions, value demonstrated and key developments of the board framework.

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?