Role Responsibilities Setting Up Operation
A key element in a successful Architecture Governance strategy 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 cost 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:
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:
In such cases, each board will be established with identifiable and articulated:
The Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals:
Further responsibilities from an operational perspective should include:
From a Governance perspective, the Architecture Board is also responsible for:
One or more of the following occurrences typically triggers the establishment of an Architecture Board:
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.
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.
The TOGAF 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 taken into account regarding 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. 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:
This section describes the operation of the Architecture Board particularly from the Governance perspective.
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.
These meetings will provide key direction in:
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 his or her availability and attendance at the governance board meeting.
This section outlines the contents of a governance board meeting agenda. Each agenda item is described in terms of its content only.
Minutes of Previous Meeting
Minutes contain the details of previous governance board meeting as per standard organisational 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
The dispensation is the mechanism used 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 service and operational criteria that must be enforced during the life span 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 compliance activity.
Compliance Assessments
Compliance is assessed against SLAs, OLAs, cost targets and required architecture refreshes. These assessments will be reviewed and either accepted or rejected depending on the criteria defined within the governance framework. The compliance assessment report will include details as described.
Dispute Resolution
Disputes that have not been resolved through the compliance and dispensation processes are identified here for further action and are documented through the 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 governance board. It should take the form of standard architecture documentation.
Actions Assigned
This is a report on the actions assigned at previous governance board meetings. An action tracker is used to document and keep the status of all actions assigned during the governance 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 as versioned [Adobe Acrobat™ PDF format] files.
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.
Copyright © The Open Group, 1999, 2003