TOGAF EA Practitioner study guide
TOGAF EA Practitioner · Work through your exam, one topic at a time.
The TOGAF Enterprise Architecture Practitioner credential sits in The Open Group's TOGAF Certification Portfolio, alongside the TOGAF Enterprise Architecture Foundation credential. It is a knowledge-based professional certification aimed at practising enterprise architects who already understand the TOGAF Standard conceptually and need to demonstrate that they can apply it to realistic situations rather than simply recall definitions. The TOGAF EA Practitioner study guide has 10 sections and about 2,801 words.
01Preliminary Phase and Architecture Governance
The Preliminary Phase answers "how will we do architecture here?" before any project architecture begins. You prepare the enterprise: scope the organizations impacted, confirm governance and support frameworks, establish the Architecture Capability (team, roles, tools), define Architecture Principles, tailor the ADM, and populate the Architecture Repository.
284 words, about 1 min02Phase A: Architecture Vision
Phase A creates the high-level, aspirational Architecture Vision and the Statement of Architecture Work that authorises the project. The step order is stakeholder-first: establish the project, identify stakeholders, concerns and requirements, confirm business goals and drivers, assess business capability and readiness for transformation, define scope (breadth, depth, time period, domains, partitions), confirm principles, build the vision, define the value proposition and KPIs, identify transformation risks, then obtain approval of the Statement of Architecture Work.
310 words, about 2 min03Phase B: Business Architecture
Phase B describes the baseline and target Business Architecture and the gaps between them: organization, business capabilities, value streams, functions, services, processes, roles, actors, information flows and locations. Business scenarios derive requirements, and the Architecture Vision is re-confirmed.
266 words, about 1 min04Phase C: Information Systems Architectures
Phase C covers Data Architecture and Application Architecture. They may be developed in either order, though data is often first because applications are justified by the data they manage.
279 words, about 1 min05Phase D: Technology Architecture
Phase D defines the Technology Architecture that supports the target Business and Information Systems Architectures: hardware, software infrastructure, networks, communications and processing, plus the technology standards and principles that constrain them. It runs baseline to target with gap analysis and produces candidate roadmap components for Phase E.
277 words, about 1 min06Phase E: Opportunities and Solutions
Phase E consolidates the gaps and candidate roadmap components from Phases B, C and D into a first complete Architecture Roadmap. It groups change activity into work packages, identifies Transition Architectures, and performs an initial prioritisation and dependency analysis.
278 words, about 1 min07Phase F: Migration Planning
Phase F converts the draft roadmap into an approved, funded, executable plan. It finalises the Architecture Roadmap and the Implementation and Migration Plan, sequences the Transition Architectures, assigns projects and work packages, and performs the cost, benefit, risk, value and dependency analysis needed for prioritisation.
257 words, about 1 min08Phase G: Implementation Governance
Phase G ensures implementation projects conform to the architecture. The EA team does not build; it prepares and issues Architecture Contracts, mobilises the Architecture Board, performs Architecture Compliance Reviews, and manages dispensations.
252 words, about 1 min09Phase H: Architecture Change Management
Phase H establishes and runs the architecture change management process. It monitors technology, business and regulatory drivers, assesses change requests, decides how to respond, and maintains the Architecture Repository so the architecture reflects reality.
283 words, about 1 min10Architecture Requirements Management and ADM Techniques
Requirements Management sits at the centre of the ADM and runs continuously through every phase. It does not own the content of requirements; it records them, stores them in the Requirements Repository, traces them to phases and artefacts, and performs a Requirements Impact Assessment whenever a change arrives.
315 words, about 2 min