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:

1. 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.

2. 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:

1. Architecture Review Board – Validates and approves solutions based on their alignment to the strategic imperatives of the organization.

2. 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:

1. 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.

2. 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.

3. 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.

4. 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.