11.2 The Architecture Board
Key Takeaways
- A cross-organization Architecture Board is a key element of a successful architecture governance strategy, overseeing its implementation.
- Architecture Board goals include consistency between sub-architectures, identifying re-usable components, and enforcement of Architecture Compliance.
- The Architecture Board supports a visible escalation capability for out-of-bounds decisions.
- The Architecture Board identifies divergence from Architecture Contracts and plans realignment through dispensations or policy updates.
- TOGAF suggests an Architecture Board of four or five permanent members, and no more than ten.
11.2 The Architecture Board
The Foundation syllabus asks you to briefly explain the role of an Architecture Board and its responsibilities. A key element in a successful architecture governance strategy is a cross-organization Architecture Board to oversee the implementation of that strategy.
Role of the Architecture Board
The Architecture Board is an executive-level body, representative of all the key stakeholders in the architecture, that is typically responsible for the review and maintenance of the overall architecture. It oversees the implementation of the architecture governance strategy and provides the mechanism through which architecture decisions are made visible, agreed, and enforced.
Why Organizations Set One Up
Typical triggers for establishing an Architecture Board include:
- A new CIO
- Merger or acquisition
- Organizational restructuring
- Consideration of a move to newer forms of computing
- Recognition that IT is poorly aligned to the business
- The desire to achieve competitive advantage through technology
- Creation of an enterprise architecture program
- Significant business change or rapid growth
- Requirement for complex, cross-functional solutions
Responsibilities
The Architecture Board is typically made responsible, and accountable, for achieving some or all of these goals:
| Goal | What it means in practice |
|---|---|
| Consistency between sub-architectures | Architectures developed by different teams or partitions fit together |
| Identifying re-usable components | Components are recognized and promoted for re-use |
| Flexibility of Enterprise Architecture | The architecture can meet changing business needs and leverage new technologies |
| Enforcement of Architecture Compliance | Projects comply with the architecture |
| Improving the maturity level of architecture discipline | The organization's architecture practice improves over time |
| Ensuring architecture-based development is adopted | Architecture is used to guide development, not bypassed |
| Supporting a visible escalation capability | There is a clear route for out-of-bounds decisions |
From an operational perspective, the Board is also responsible for:
- Monitoring and control of architecture compliance activities
- Providing the basis for all decision-making with regard to the architectures
- Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication
- Providing a fundamental control mechanism for ensuring effective implementation of the architecture
- Establishing and maintaining the link between implementation of the architecture, the architectural strategy and objectives, and the strategic objectives of the business
- Identifying divergence from the Architecture Contract and planning activities to realign with it, through dispensations or policy updates
- Resolving ambiguities, issues, or conflicts that have been escalated, and providing advice, guidance, and information
Setting Up and Operating the Board
| Aspect | TOGAF guidance |
|---|---|
| Membership | Representative of all the key stakeholders; executive-level and cross-organizational |
| Size | A good rule of thumb is four or five permanent members, and no more than ten |
| Rotation | To keep the Board manageable yet representative, consider rotating membership, giving decision-makers across the enterprise exposure over time |
| Charter | The Board's responsibilities and authority should be defined and agreed |
| Meetings and records | Meetings follow an agenda, and decisions, including compliance assessments and dispensations, are recorded so they can be audited |
The Architecture Board Across the ADM
| Where | Board involvement |
|---|---|
| Preliminary Phase | The architecture governance framework, including the Board's role, is confirmed; Architecture Principles are agreed with key stakeholders such as the Board |
| Requirements Management | The Architecture Requirements Repository holds the authorized architecture requirements agreed with the Architecture Board |
| Phase G | Compliance assessments, divergence from Architecture Contracts, and dispensations come to the Board |
| Phase H | The step "Manage Governance Process" arranges a meeting of the Architecture Board, or other governing council, to decide on handling changes, including technology and business changes and dispensations |
| Partitioned architectures | The Board maintains consistency between sub-architectures developed by different teams |
Because the Board sees decisions across projects and partitions, it is also well placed to spot re-usable components and to drive improvement in the maturity of the architecture discipline.
Scenario: Escalating an Out-of-Bounds Decision
Two business units propose competing customer relationship management platforms. Neither project team has the authority to decide for the enterprise, so the issue is escalated to the Architecture Board. Using the architecture principles ("Common Use Applications"), the strategic architecture, and the re-use goal, the Board selects one platform as the enterprise standard, records the decision, and plans how the second unit will migrate — consistency between sub-architectures, re-use, and a visible escalation route all at work.
Common Exam Pitfalls
- Treating the Board as a project management office. It governs architecture decisions and compliance; it does not run project schedules.
- Making the Board too large. TOGAF suggests four or five permanent members and no more than ten.
- Forgetting consistency between sub-architectures. It is a core Board responsibility, especially with partitioned architectures.
- Overlooking escalation. Supporting a visible escalation capability for out-of-bounds decisions is an explicit goal.
Which of the following is an Architecture Board responsibility in the TOGAF Standard?
What does TOGAF suggest as a good rule of thumb for Architecture Board size?
What role does the Architecture Board play when a project diverges from its Architecture Contract?
Two business units cannot agree on a shared platform, and neither project team can decide for the enterprise. Which Architecture Board goal is most directly engaged?