Architecture Review Board (ARB)

The Architecture Review Board is to be the quality gate, reviewer and governing body of all architectures created by the architecture team.

ARB

The primary purpose of this Architecture Review Board is to provide the basis for decision-making with regard to the architectures. Assess and drive consistency between sub-architectures, establish targets for re-use of components, assess architectures for flexibility in meeting the business needs and accommodating new technologies, enforce architecture compliance and improve the maturity level of the architecture discipline within the organization.

Actions

The actions assigned at previous Architecture Board meetings. An action tracker is used to document and keep the status of all actions assigned during the Architecture Board meetings and should consist of at least the following information:

Reference
Priority
Action description
Action owner
Action details
Date raised
Due date
Status
Type
Resolution date

Approvals

Architecture approvals.

Architecture Models

Either models within the EA modeling tool or presentations that summarize the same. The model represents the domain or service and adheres to the reference architecture and style guides.

Architecture Review Board Chair

The chair leads the board, sets its agenda and ensures it is an effective working group. The Chair must promote a culture of openness and debate and is responsible for effective communication with the stakeholders. The Chair must ensure that all board members receive accurate, timely and clear information.

Architecture Review Board Meeting Agenda

The agenda for the architecture review board is as follows:

Minutes of Previous Meeting
Requests for Change / Review
Dispensations
Compliance Assessments
Dispute Resolution
Architecture Strategy and Direction
Actions Assigned
Any Other Business (AOB)

Architecture Review Board Member

The ARB board consists of voting members, which act on behalf of, and is subordinate to the programme’s full architecture group, which usually chooses the members of the board or are randomly selected from volunteers.

The board’s activities are determined by the role & responsibilities laid out in the architecture review board’s terms of reference.

Architecture Review Board Technical Design Authority

The purpose of a Technical Design Authority (TDA) is to provide direction and momentum to a project.

The technical design authority:

knows concretely how the project must proceed (vision)
has the authority to make binding decisions (mandate)
has the professional knowledge and skill to make material choices based on substantive argumentation (knowledge)
has the power to settle discussions and implement choices on a daily basis (leadership)
motivates participants to perform beyond their own expectations (charisma).

Architecture Review Board Terms of Reference

The Architecture Review Board (ARB) performs the following role in relation to the architecture:

Governance & compliance
Conflict resolution
Change
Advice, guidance and Information
Architecture acceptance and approval

The ARB has the following responsibilities:

Provides the basis for all decision-making with regard to the “out-of-domain” architectures
Drives consistency between sub-architectures over and above that of the “services”
Establish targets for re-use of the architecture and components
Enforcement of the Architecture Compliance
Ensure effective and consistent management and implementation of the architectures
Resolving ambiguities, issues or conflicts that have been escalated
Provides advice, guidance and information
Reviewing and approving dispensations that are in keeping with the architectural strategy and objectives
Consider policy (Schedules, Service Level Agreements (SLAs), etc.) changes
Provide governance structure
Provide a mechanism for the formal acceptance and approval of the architecture

Governance & Compliance

From a governance perspective, the ARB is responsible for:

The production of usable governance material and activities
Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication
Providing a fundamental control mechanism for ensuring the effective implementation of the architecture
Establishing and maintaining the link between the implementation of the architecture, the architectural strategy and objectives embodied in the enterprise architecture, and the strategic objectives of the business
Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates
Provide a compliance model to assess the architecture against the reference model
Managed by the modeling team.
Comprised of comparing the architectures provided against the reference architecture and “style guides”

Conflict Resolution

From a Conflict Resolution perspective, the ARB is responsible:

Understanding the conflict and how it came to be
Resolving the conflict between domains and/or services so that an agreed outcome can be reached
Listen to both sides of the conflict
Board members to vote if necessary
Decision may not be in either party’s interest

Change

From a Change perspective, the ARB is responsible:

Understanding the need for the change
Approving or rejecting the change
Having reviewed the change request
Having explored and questioned the need for the change request
Provide “next steps” where appropriate and/or necessary.

Advice, Guidance & Information

From an Advice, Guidance and Information perspective, the ARB is responsible:

Giving advance, guidance and information when it is asked.
Providing information to the wider architecture team when information needs to be distributed
Guidance on architecture standards
Compliance reporting
Changes from the programme / senior leadership
Priorities

Architecture Acceptance & Approval

From an Acceptance and Approval or Architecture perspective, the ARB is responsible:

Voting on the acceptance and approval of architectural changes where appropriate
Architecture changes
Dispensations
Voting on the rejection of architectural changes where appropriate
Providing feedback on the reasoning behind the rejection

The Board Structure

The Board will consist of:

4x Board members from the architecture team
Each member is expected to vote unless they are presenting to the board (default abstain)
Each member is expected to attend each ARB
Each member will remain on the board for 6 months
After 6 months a new member is randomly selected
1x T echnical Design Authority
TDA is expected to vote
No expiration of membership (based on role)
1x Chair person (Usually the Chief Architect)
Chair is expected to vote
No expiration of membership (based on role)

Inputs to the Architecture Review Board Meeting

Minutes for review/agreement
Architecture Change Requests
Architecture Dispensations
Compliance / Maturity Reports
Architecture Models

Change Requests

Items under this heading are normally change requests for amendments to architectures, principles, etc., but may also include business control with regard to Architecture Contracts.

Compliance / Maturity Reports

Compliance is assessed against the reference architecture and style guides.
These assessments will be reviewed and either accepted or rejected depending on the criteria defined by the architecture maturity model.

Dispensations

A dispensation is used as the mechanism to request a change to the existing architectures, contracts, principles, etc. outside of normal operating parameters; e.g., deploy non-standard technology or products to support specific business initiatives, non-compliance to the reference architecture.

Dispensations are granted for a given time period and for a specific area, domain or service.

Dispensations are not granted indefinitely. The time-bound nature of dispensations ensures that they are a trigger to the Architecture Compliance activity.

Minutes

Minutes contain the details of previous Architecture Board meeting as per standard organizational protocol.

Notice of Decisions

Architecture decisions may be documented as Notice of Decisions (NoDs) for distribution to a wider audience.

Outputs and decisions from the Architecture Review Board

Notice of Decisions
Change / Review Request Approvals
Dispensation Approvals
Actions

Service and Domain Lead Architects

The lead architect for each solution service and domain.

Service and Domain Lead Engineers

The lead engineers for each of the solution services and domains.

Architecture Governance Service

The Architecture and Engineering team provide an Architecture governance service to the rest of the business and in Collaboration with the customer / stakeholders.