What an Architecture Board is accountable for, who should sponsor it and how large it should be.
From Ultra Transcenders OGEA-101 by Tony Rough (publishing soon)
The Architecture Board is the central body that puts the governance strategy into effect. Understanding how governance is organised largely comes down to what the board is, who sits on it and what it is responsible for.
The Architecture Board is a cross-organisation board that oversees the implementation of the governance strategy. It should represent all the key stakeholders in the architecture and is typically made up of executives responsible for reviewing and maintaining the overall architecture. Its scope may be global, regional or a single business line. Larger enterprises usually need at least two levels:
Each level has its own defined responsibilities, decision-making powers, remit and limits of authority.
| Area | Responsibilities |
|---|---|
| Overall accountability | Providing the basis for all decision-making about architectures; consistency between sub-architectures; setting targets for re-use of components; keeping the Enterprise Architecture flexible enough for changing needs and new technology; enforcing Architecture Compliance; improving the maturity of the architecture discipline; ensuring architecture-based development is adopted; providing a visible escalation route for decisions outside agreed bounds |
| Operational | Monitoring and controlling Architecture Contracts; meeting regularly; consistent management and implementation of governance; resolving escalated ambiguities, issues and conflicts; giving advice and guidance; ensuring compliance and granting dispensations that fit the technology strategy; considering policy changes where the same dispensation keeps being requested; publishing contract information under controlled conditions; validating reported service levels and cost savings |
| Governance | Producing usable governance material; acting as the mechanism for formal acceptance and approval of architecture through consensus and authorised publication; serving as the fundamental control mechanism for effective implementation; linking implementation to the architectural strategy and to business strategic objectives; spotting divergence and planning realignment through dispensations or policy updates |
The board also approves the Architecture Principles developed by the enterprise architects with key stakeholders (see Chapter 9, Architecture Principles and Business Scenarios), and it must be satisfied that the ADM itself is being applied correctly in every phase.
Common trap: The CIO’s sponsorship is enough - the Standard says the board needs an executive sponsor at the highest level, and a lack of executive participation is a common reason governance fails.
Common trap: A larger board is more representative and therefore better - the recommendation is four or five permanent members and no more than ten, with representation achieved by rotating membership rather than by growing the board.
This note is one section of Ultra Transcenders OGEA-101: Enterprise Architecture Foundation, an independent study guide that explains every learning unit the exam covers, topic by topic, with comparison tables, diagrams and the common traps, plus a glossary linked to the TOGAF Standard.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · OGEA-101 terms in the glossary · All OGEA-101 study notes
What the Business, Data, Application and Technology domains each describe, and which subjects cut across all four.
The contextual, conceptual, logical and physical levels, the question each answers, and the difference between logical and physical.
Why the Enterprise Continuum is a classification scheme rather than a place, and what it does for communication and re-use.
The Preliminary Phase, Phases A to H and Requirements Management, each with its purpose and essential output.
How to set Baseline Architecture Building Blocks against Target ones to see what is included, what is new and what is eliminated.
Architecture Capability, Architecture Development, Transition Planning and Architecture Governance iterations, and the phases each one spans.
How stakeholders' concerns are framed by viewpoints and addressed by views, and why a view and a viewpoint are not the same thing.