Architecture Governance is scrutiny and crucial activity to have successful implementation in any organization. In TOGAF, Architecture Governance is executed in Phase G- Implementation Governance. By applying Architecture Governance you can cover the management and control of all aspects of the development and evolution architectures. Governance is essentially about ensuring that business is conducted properly. It's about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives. If your organization is not large you don't have to apply all Architecture Governance Framework and methodologies.
Architecture Governance can include the following as distinct domains with their own disciplines and processes:
- Corporate Governance
- Technology Governance
- IT Governance
- Architecture Governance
Remember that each of these domains may exist at multiple geographic levels which are global, regional and local.
Architecture Board
Architecture Boards is the main point for successful architecture governance. Architecture Board should represent the key stakeholders and contains of a group of executives who are responsible for the review of the architecture. Architecture Board is the sponsor of the architecture within the enterprise but Architecture Board needs support from executive levels. In most organizations, CIO is the first person who is in the Architecture Board. As an Enterprise Architecture, you shouldn't overlook company's board of directors. They are responsible for and have significant impact on the business vision, objectives and strategies. Because, nowadays, IT is the core of any business and shouldn't be thought without another.
What about the size of Architecture Board
According to TOGAF, Architecture Board includes four or five permanent members. I wrote permanent members because sometimes they might not find enough time to attend the architecture review meeting or review the ongoing architecture. In order to keep architecture governance running you are able to find a way how to rotate the members of Architecture Board to senior managers. After the work of Architecture Board is reviewed by executive sponsors, remember to update the Architecture Compliance review process.
If the organization is large Architecture Board can be separated into three levels :
Each board should be identified with responsibilities, decision making capabilities and authority limits.
When do you need to set up the Architecture Board?
According to TOGAF there are a few reason to establish the Architecture Board :
- If organization employees a new CIO
- If your company is being merged or acquire a company
- If your organization decides to change current forms of computing
- If IT doesn't fulfill or meet business needs
- If your organization decides to apply a new enterprise architecture program
- If your organization's business changes significantly or business grows rapidly
- Requirements for complex, cross-functional solutions
In which ADM phase do you set up the Architecture Board?
Architecture Board should be defined at the beginning of the enterprise architecture. In TOGAF, this is preliminary phase. In preliminary phase, as an enterprise architect you should specify Architecture Board with support framework to provide business process and architecture governance through enterprise architecture.
What are the expectations from Architecture Board?
In TOGAF Architecture Framework, the responsibilities of Architecture Board have to be achieved are written below:
- 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 levels of architecture
- 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 (SLA), etc.) changes where similar dispensations are requested and granted; 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
Architecture Governance Framework
Architecture Governance needs to be supported by an Architecture Framework. In TOGAF, Architecture Framework has 2 sections which are
Conceptual Structure and
Organizational Structure.
Conceptual Structure : Context, Process and Content are fundamental to the support of the architecture governance initiative. It's possible to add new governance material without excessively impacting the processes. As you see the figure below, Architecture Governance Framework is part of Enterprise Continuum. While executing the processes you can use different type of content. This gives you flexibility to implement proven methods.
 |
| Conceptual Structure |
- Policy Management and take-on: In this process all kind of documents, contracts and supporting information are collected to ensure that they are managed and audited.
- Compliance: SLAs, OLAs, standards and regulatory requirements will be implemented on an ongoing basis to be sure stability, conformance, and performance monitoring.
- Dispensation: It's always possible that a compliance assessment might be rejected. If it happens there is an alternate route is provided through dispensations. Time which is not indefinite is given to set of identified service and operational criteria to meet service and operational levels.
- Monitoring and Reporting: It's required to ensure that operational and service components are managed against an agreed set of criteria.
- Business Control: It's used to make certain compliance with the organization's business policies.
- Environment Management: In order to make sure that repository-based environment supports architecture governance framework effectively.
Organizational Structure : Architecture Governance is the approach to ensure enterprise architectures and any other architectures are managed. In order to do that it's necessary to have the proper organizational structure. In the figure below, you can see main part of the organizational structure elements.
 |
| Organizational Structure |
There are three main areas of architecture management.
One or more groups in organization is responsible for each main area. As you see the below of the Organizational Structure figure, Enterprise Continuum support all major areas with artifacts.
Architecture Compliance
Essential point of view of Architecture Governance is to ensure each project in organization is finished in compliance with architecture contracts. In term of TOGAF it's called Architecture Compliance. Terminology usage in TOGAF about Architecture Compliance is explained below:
 |
| Levels of Architecture Compliance |
Architecture Compliance Review Process
Architecture Compliance Review is needed to understand the level of Architecture Compliance. As follows, Architecture Compliance Review Process is explained by TOGAF. The main purpose of the process is to create an assessment report of the architecture. In this process, people in organization collaborates to produce assessment report which is prominent to review and define the level of architecture compliance. The report shows that how the architecture is implemented to address the business requirements. The level of architecture compliance is explained in TOGAF. You are free to customize it in accordance with your organization.
 |
| Architecture Compliance Review Process |
Below, you can find 12 steps of Architecture Compliance Review Process and the roles which takes responsibility in each step.
- Request Architecture Review: Anyone with an interest in or responsibility for the business area.
- Identify responsible part of organization and project principals: Architecture review coordinator
- Identify lead enterprise architect and other architects: Architecture review coordinator
- Determine scope of review:
Architecture review coordinator
- Tailor checklists:Lead Enterprise Architect
- Schedule architecture review meeting:Architecture review coordinator with collaboration of lead enterprise architect.
- Interview project principles:Lead enterprise architect and/or architect, project leader, and customers
- Analyzed completed checklists:Lead enterprise architect
- Prepare architecture compliance review report: Lead enterprise architect
- Present review findings: Lead enterprise architect
- Accept review and sign-off: Architecture board and customer
- Send assessment report/summary to architecture review coordinator: Lead enterprise architect
What are the Roles in Architecture Compliance Review Process?
Above, there are a few roles mentioned in Architecture Compliance Review Process. You can find the responsibilities of each roles as listed below:
- Architecture Board: To ensure that IT architectures are consistent and support overall business needs.
- Project Leader: Responsible for the whole project
- Architecture Review coordinator : To administer the whole architecture development and review process
- Lead Enterprise Architect: To ensure that the architecture is technically coherent and future-proof.
- Architect: One of the Lead Enterprise Architect's technical assistant.
- Customer: To ensure that business requirements are clearly expressed and understood.
- Business Domain Expert: To ensure that the process to satisfy the business requirements are justified and understood.
- Project Principals: To ensure that the architects have a sufficiently detailed understanding of the customer department's processes. They can provide input to the business domain expert or to the architects.