Study guide
2.3 Establishing Architecture Governance, Frameworks, and Tools
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
2.3 Establishing Architecture Governance, Frameworks, and Tools
Key Takeaways Explain This Topic AI
Architecture governance is established in the Preliminary Phase so that principles, compliance, and decision rights exist before project work begins.
TOGAF characterizes governance by discipline, transparency, independence, accountability, responsibility, and fairness.
The Architecture Board represents key stakeholders; TOGAF recommends four or five, and no more than ten, permanent members.
Tailoring adapts the ADM, deliverables, and organization-specific Enterprise Metamodel to the enterprise and to adjacent frameworks such as ITIL and COBIT.
The 10th Edition Architecture Repository includes the Architecture Metamodel, Capability, Landscape, Standards Library, Reference Library, Governance Repository, Requirements Repository, and Solutions Landscape.
Last updated: November 2026
A foundational axiom of the TOGAF Standard 10th Edition is that architecture development cannot succeed in a governance vacuum. When an enterprise architecture team attempts to author models, define standards, and draft roadmaps without established governance authority, its artifacts remain purely theoretical recommendations. Inevitably, under the intense pressures of project delivery deadlines and budgetary constraints, development teams bypass architectural guidelines, resulting in technical debt, fragmented systems, and escalating operational risk.
Establishing architecture governance during the Preliminary Phase establishes formal legitimacy, executive backing, and an enforceable compliance mechanism before individual architecture projects begin.
The Architecture Governance Framework
Architecture governance operates as an integral discipline within broader corporate governance, enterprise risk management, and IT portfolio oversight. TOGAF characterizes good governance by six characteristics: discipline, transparency, independence, accountability, responsibility, and fairness . In practice, the governance arrangements set up in the Preliminary Phase aim at four outcomes:
Strategic Realization : Verifying that capital technology investments directly implement the business strategy and capability roadmap.
Accountability and Transparency : Ensuring that architectural choices, trade-offs, and exceptions are explicitly documented, justified, and approved by accountable leaders.
Compliance Assurance : Monitoring implementation projects through structured stage-gate reviews to prevent deviation from target architectures.
Discipline and Controlled Flexibility : Providing a structured, audit-ready mechanism to grant variances and dispensations when valid business realities preclude strict adherence to standards.
The Architecture Board: Charter, Composition, and Operations
The central operational entity of architecture governance is the Architecture Board . Established and chartered during the Preliminary Phase, the Board serves as the enterprise-wide governing body for all architectural policies, standards, and approvals.
Key aspects of the Architecture Board include:
Cross-Functional Representation : The Board should represent all the key stakeholders in the architecture and typically comprises executives responsible for reviewing and maintaining it. TOGAF recommends four or five (and no more than ten) permanent members , with membership rotated over time to give enterprise-wide representation while preserving continuity.
Charter and Mandate : The Board operates under a formal written charter defining its authority, voting quorums, meeting frequency, escalation paths to executive committees, and authority thresholds for approving investments and dispensations.
Primary Operational Responsibilities :
Approving and maintaining the enterprise Architecture Principles.
Reviewing and ratifying enterprise architecture deliverables, baseline models, and target roadmaps.
Adjudicating dispensation requests and managing the architectural dispensation lifecycle.
Conducting formal Architecture Compliance Reviews at major project delivery stage-gates.
Mediating architectural disputes and misalignments between competing business divisions or vendor platforms.
Architecture Governance Roles and Responsibilities
The following table outlines the key architectural roles established during the Preliminary Phase and their responsibilities within the governance framework:
Governance Role Primary Architectural Focus Key Operational Responsibilities
Architecture Board Strategic authority & policy enforcement Approves principles, ratifies major architectures, adjudicates dispensations, and enforces strategic alignment.
Chief Architect EA capability leadership & executive sponsorship Leads the EA practice, manages the architecture team, reports to C-level executives, and chairs or directs Board sessions.
Enterprise Architect Cross-domain coherence & strategic roadmaps Drives ADM cycles across business units, authors target architectures, and guides multi-year portfolio capital planning.
Domain Architect Deep specialized domain guidance (Data, App, Tech, Bus) Defines domain standards, creates reference models, authors Architecture Building Blocks (ABBs), and leads compliance reviews.
Solution Architect Project-level architecture delivery & conformance Authors project architectures, maps ABBs to Solution Building Blocks (SBBs), and defends solution designs before the Board.
Implementation Lead Project execution & contractual delivery Builds systems adhering to approved Architecture Contracts and submits formal dispensation requests when deviations are required.
Tailoring the TOGAF Framework for Organizational Context
The TOGAF Standard is intentionally designed to be adapted. Applying the ADM in a dogmatic, off-the-shelf fashion without tailoring it to organizational culture and existing operational lifecycles is a proven recipe for institutional rejection. During the Preliminary Phase, the architecture team tailors the framework across four critical areas:
Delivery Process Integration :
Aligning the ADM with existing corporate development methodologies. In organizations utilizing Agile and Scaled Agile Framework (SAFe), the ADM is tailored to provide an 'architectural runway': Phases A through D define the strategic themes, epics, and guardrails, while Phases E through G synchronize directly with Program Increment (PI) planning and sprint release cycles.
Enterprise Metamodel Customization :
The TOGAF Enterprise Metamodel provides a set of entities likely to be found in most enterprises (Actors, Roles, Business Services, Data Entities, Application Components, Technology Services, and more). During Preliminary, the team develops an organization-specific metamodel by leaving out entities that are not relevant and adding organization-specific entities and attributes—such as Regulatory Compliance Obligations , Data Sovereignty Classifications , or SaaS Subscription Attributes .
Deliverable and Documentation Tailoring :
Rather than mandating massive, multi-hundred-page static documents, the team tailors TOGAF deliverables (such as the Architecture Definition Document and Architecture Vision) into modular, living assets, such as repository-driven wiki portals, decision logs (often written as architecture decision records), and executive dashboards.
Harmonization with Adjacent Enterprise Frameworks :
Establishing clear handshakes between TOGAF and complementary governance frameworks:
ITIL / ISO 20000 : Synchronizing architecture components with the Configuration Management Database (CMDB) and IT service management lifecycles.
COBIT : Mapping architecture controls to enterprise IT governance and audit benchmarks.
PMBOK / PRINCE2 : Embedding Architecture Compliance Reviews directly into project stage-gate funding gates.
SABSA : Integrating enterprise security architecture attributes into the tailored metamodel.
Tooling Strategy and Standard Notations
Modern enterprise architecture cannot be sustained using disconnected desktop spreadsheets and static drawing tools. Such unmanaged files quickly become outdated, lack referential integrity, and cannot perform automated dependency tracking. During the Preliminary Phase, the team establishes its tooling strategy:
Adoption of Standard Modeling Notations :
The architecture practice standardizes on formal, vendor-neutral modeling notations. Primarily, this includes ArchiMate (an open The Open Group modeling language standard) for end-to-end, multi-layer enterprise architecture models; BPMN (Business Process Model and Notation) for operational business workflows; and UML (Unified Modeling Language) for low-level application and software interface specifications.
Enterprise Tool Selection Criteria :
Selected modeling platforms must feature a unified repository database, multi-user concurrent modeling, role-based access control, metamodel configurability, automated impact analysis, and integration with DevOps and CMDB systems.
Initializing the Architecture Repository
The Architecture Repository is the official corporate information store holding all architectural assets, models, standards, and governance history. Initializing the repository structure is a mandatory Preliminary Phase activity.
The TOGAF Standard, 10th Edition describes these classes of information in an Architecture Repository:
Architecture Metamodel : the organizationally tailored application of the framework, including the method and a metamodel for architecture content.
Architecture Capability : the parameters, structures, and processes that support governance of the Architecture Repository.
Architecture Landscape : architectural representations of assets in use or planned at particular points in time, at the Strategic, Segment, and Capability levels.
Standards Library : the standards that new architectures must comply with: legal and regulatory obligations, industry standards, and organizational standards.
Reference Library : guidelines, templates, patterns, reference architectures, and other reference material that accelerate new architectures.
Governance Repository : a record of governance activity, including the decision log, compliance assessments, capability assessments, calendar, project portfolio, and performance measurement.
Architecture Requirements Repository : all authorized architecture requirements agreed with the Architecture Board.
Solutions Landscape : the Solution Building Blocks (SBBs) planned or deployed to support the Architecture Landscape.
TOGAF 9.1 material describes only six classes, and TOGAF 9.1 and 9.2 both use the names Standards Information Base and Governance Log ; for OGEA-103, learn the 10th Edition names above.
Practitioner Exam Traps Regarding Governance
Dispensations Are Not Project Failures : A dispensation is a legitimate, proactive governance mechanism that grants a project temporary permission to deviate from a standard under justified business constraints (such as vendor unreadiness or emergency regulatory deadlines). Every dispensation must document a business justification, risk assessment, explicit expiration date, and remediation plan to return to compliance.
Tooling Preceding Process : Procuring an expensive modeling tool before establishing the tailored framework, metamodel, and governance processes almost inevitably results in shelfware. The governance process and tailored metamodel must dictate tool requirements, not the other way around.