-
47. Architecture Board
This chapter provides guidelines for establishing and operating an Enterprise Architecture Board.
47.1 Role
A key element in a successful architecture governance strategy (see 50. 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.
The costs of establishing and operating an Architecture Board are more than offset by the savings that accrue as a result of preventing one-off solutions and unconstrained developments across the enterprise, which invariably lead to:
- High costs of development
- High costs of operation and support:
- Numerous run-time environments
- Numerous implementation languages
- Numerous interfaces and protocols ...
- Lower quality
- Higher risk
- Difficulty in replicating and re-using solutions
Architecture Boards may have global, regional, or business line scope. Particularly in larger enterprises, Architecture Boards typically comprise representatives from the organization at a minimum of two levels:
- Local (domain experts, line responsibility)
- Global (organization-wide responsibility)
In such cases, each board will be established with identifiable and articulated:
- Responsibilities and decision-making capabilities
- Remit and authority limits
47.2 Responsibilities
The Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals:
- Consistency between sub-architectures
- Identifying re-usable components
- Flexibility of enterprise architecture:
- To meet changing business needs
- To leverage new technologies
- Enforcement of Architecture Compliance
- Improving the maturity level of architecture discipline within the organization
- Ensuring that the discipline of architecture-based development is adopted
- Providing the basis for all decision-making with regard to changes to the architectures
- Supporting a visible escalation capability for out-of-bounds decisions
Further responsibilities from an operational perspective should include:
- All aspects of monitoring and control of the Architecture Contract
- Meeting on a regular basis
- Ensuring the effective and consistent management and implementation of the architectures
- Resolving ambiguities, issues, or conflicts that have been escalated
- Providing advice, guidance, and information
- Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives
- Considering policy (schedule, Service Level Agreements (SLAs), etc.) changes where similar dispensations are requested and granted; e.g., new form of service requirement
- Ensuring that all information relevant to the implementation of the Architecture Contract is published under controlled conditions and made available to authorized parties
- Validation of reported service levels, cost savings, etc.
From a governance perspective, the Architecture Board is also 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
47.3 Setting Up the Architecture Board
47.3.1 Triggers
One or more of the following occurrences typically triggers the establishment of an Architecture Board:
- New CIO
- Merger or acquisition
- Consideration of a move to newer forms of computing
- Recognition that IT is poorly aligned to business
- Desire to achieve competitive advantage via technology
- Creation of an enterprise architecture program
- Significant business change or rapid growth
- Requirement for complex, cross-functional solutions
In many companies, the executive sponsor of the initial architecture effort is the CIO (or other senior executive). However, to gain broad corporate support, a sponsoring body has more influence. This sponsoring body is here called an Architecture Board, but the title is not important. Whatever the name, it is the executive-level group responsible for the review and maintenance of the strategic architecture and all of its sub-architectures.
The Architecture Board is the sponsor of the architecture within the enterprise, but the Architecture Board itself needs an executive sponsor from the highest level of the corporation. This commitment must span the planning process and continue into the maintenance phase of the architecture project. In many companies that fail in an architecture planning effort, there is a notable lack of executive participation and encouragement for the project.
A frequently overlooked source of Architecture Board members is the company's Board of Directors. These individuals invariably have diverse knowledge about the business and its competition. Because they have a significant impact on the business vision and objectives, they may be successful in validating the alignment of IT strategies to business objectives.
47.3.2 Size of the Board
The recommended size for an Architecture Board is four or five (and no more than ten) permanent members.
In order to keep the Architecture Board to a reasonable size, while ensuring enterprise-wide representation on it over time, membership of the Architecture Board may be rotated, giving decision-making privileges and responsibilities to various senior managers. This may be required in any case, due to some Architecture Board members finding that time constraints prevent long-term active participation.
However, some continuity must exist on the Architecture Board, to prevent the corporate architecture from varying from one set of ideas to another. One technique for ensuring rotation with continuity is to have set terms for the members, and to have the terms expire at different times.
In the ongoing architecture process following the initial architecture effort, the Architecture Board may be re-chartered. The executive sponsor will normally review the work of the Architecture Board and evaluate its effectiveness; if necessary, the Architecture Compliance review process is updated or changed.
47.3.3 Board Structure
The TOGAF Architecture Governance Framework (see 50.2 Architecture Governance Framework) provides a generic organizational framework that positions the Architecture Board in the context of the broader governance structures of the enterprise. This structure identifies the major organizational groups and responsibilities, as well as the relationship between each group. This is a best practice structure, and may be subject to change depending on the organization's form and existing structures.
Consideration must be given to the size of the organization, its form, and how the IT functions are implemented. This will provide the basis for designing the Architecture Board structure within the context of the overall governance environment. In particular, consideration should be given to the concept of global ownership and local implementation, and the integration of new concepts and technologies from all areas implementing against architectures.
The structure of the Architecture Board should reflect the form of the organization. The architecture governance structure required may well go beyond the generic structures outlined in the TOGAF Architecture Governance Framework (see 50.2 Architecture Governance Framework). The organization may need to define a combination of the IT governance process in place and the existing organizational structures and capabilities, which typically include the following types of body:
- Global governance board
- Local governance board
- Design authorities
- Working parties
47.4 Operation of the Architecture Board
This section describes the operation of the Architecture Board particularly from the governance perspective.
47.4.1 General
Architecture Board meetings should be conducted within clearly identified agendas with explicit objectives, content coverage, and defined actions. In general, board meetings will be aligned with best practice, such as given in the COBIT framework (see 50.1.4.1 An IT Controls Framework - COBIT).
These meetings will provide key direction in:
- Supporting the production of quality governance material and activities
- Providing a mechanism for formal acceptance through consensus and authorized publication
- Providing a fundamental control mechanism for ensuring the effective implementation of the architectures
- Establishing and maintaining the link between the implementation of the architectures and the stated strategy and objectives of the organization (business and IT)
- Identifying divergence from the contract and planning activities to realign with the contract through dispensations or policy updates
47.4.2 Preparation
Each participant will receive an agenda and any supporting documentation - e.g., dispensation requests, performance management reports, etc. - and will be expected to be familiar with the contents of each.
Where actions have been allocated to an individual, it is that person's responsibility to report on progress against these.
Each participant must confirm their availability and attendance at the Architecture Board meeting.
47.4.3 Agenda
This section outlines the contents of a Architecture Board meeting agenda. Each agenda item is described in terms of its content only.
Minutes of Previous Meeting
Minutes contain the details of previous Architecture Board meeting as per standard organizational protocol.
Requests for Change
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; e.g., ensure that voice traffic to premium numbers, such as weather reports, are barred and data traffic to certain web sites is controlled.
Any request for change is made within agreed authority levels and parameters defined by the Architecture Contract.
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., exclude provision of service to a subsidiary, request for unusual service levels for specific business reasons, deploy non-standard technology or products to support specific business initiatives.
Dispensations are granted for a given time period and set of identified services and operational criteria that must be enforced during the lifespan of the dispensation. Dispensations are not granted indefinitely, but are used as a mechanism to ensure that service levels and operational levels, etc. are met while providing a level flexibility in their implementation and timing. The time-bound nature of dispensations ensures that they are a trigger to the Architecture Compliance activity.
Compliance Assessments
Compliance is assessed against SLAs, Operational Level Agreements (OLAs), cost targets, and required architecture refreshes. These assessments will be reviewed and either accepted or rejected depending on the criteria defined within the Architecture Governance Framework. The Architecture Compliance assessment report will include details as described.
Dispute Resolution
Disputes that have not been resolved through the Architecture Compliance and dispensation processes are identified here for further action and are documented through the Architecture Compliance assessments and dispensation documentation.
Architecture Strategy and Direction Documentation
This describes the architecture strategies, direction, and priorities and will only be formulated by the global Architecture Board. It should take the form of standard architecture documentation.
Actions Assigned
This is a report on 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
Contract Documentation Management
This is a formal acceptance of updates and changes to architecture documentation for onward publication.
Any Other Business (AOB)
Description of issues not directly covered under any of the above. These may not be described in the agenda but should be raised at the beginning of the meeting. Any supporting documentation must be managed as per all architecture governance documentation.
Schedule of Meetings
All meeting dates detail should be detailed and published.