TOGAF EA Practitioner common mistakes
TOGAF EA Practitioner · Understand the traps and how to avoid them.
When a scenario describes pre-ADM setup work (agreeing architecture principles, tailoring the framework, standing up the Architecture Repository and the Architecture Board) the candidate selects options about producing an Architecture Vision or a Statement of Architecture Work as part of that setup.
Preliminary and Phase A both read as 'getting started', and Phase A material is studied more heavily, so answers drift toward the better-known artifacts.
What to do instead
Memorise Preliminary as a closed output list: Architecture Principles, tailored framework and architecture maturity, the organisation model for the EA practice, the Architecture Repository and its governance structures, and the business principles/goals/drivers that trigger a Request for Architecture Work. Any option naming stakeholders' concerns, an Architecture Vision, or a Statement of Architecture Work belongs to Phase A, not Preliminary.
Candidates choose 'produce the complete Architecture Definition Document' or 'resolve the target technology baseline' as Phase A outputs, and describe the Architecture Vision as a summary of B-to-D work already done.
The label 'Architecture Vision' suggests a finished architecture, and ambitious-sounding options attract selection.
What to do instead
Hold Phase A to scope and ambition: a high-level outline of the Architecture Definition Document, the approved Architecture Vision, the approved Statement of Architecture Work, a capability assessment, and a communications plan. If an option requires resolved architectural detail or a completed baseline, it is a later phase.
Candidates attribute Business Scenarios and Business Transformation Readiness Assessment to Phase B as its core techniques, and use them to justify Phase B deliverables.
Both techniques are business-facing, so they are intuitively grouped with Business Architecture.
What to do instead
Place Business Scenarios in Phase A (they elicit requirements and shape the Architecture Vision) and Business Transformation Readiness Assessment in Phase A, revisited in Phase E. Phase B's own techniques are business models, value chain and organisation mapping, and gap analysis across business baseline and target.
Candidates answer that Data Architecture must be finished before Application Architecture can start, or that Phase C is two strictly sequential sub-phases with a separate sign-off between them.
Waterfall intuition and sequential diagrams make a fixed order feel mandatory, and 'Information Systems Architectures' looks like a single artefact.
What to do instead
State that TOGAF leaves the order of the data and application sub-architectures to the architecture team, allowing them to be developed iteratively or in parallel, with one consolidated Phase C output set (Architecture Definition Document content, Architecture Requirements Specification, Architecture Roadmap). Reject any option that hard-codes precedence or demands separate approval gates.
Candidates reduce Phase D to a hardware and network inventory, ignoring middleware, communications, processing, technology standards, and the mapping of application and data components onto technology components.
Physical infrastructure is the most visible part of technology architecture, and catalogue-style lists look like architecture work.
What to do instead
Test every Phase D option against the full scope: baseline and target technology architecture covering logical and physical technology components, the Technology Standards and Technology Portfolio catalogues, and the mapping of Application and Data components to technology. Also recall that Phase D consumes and updates the Architecture Requirements Specification produced in Phases B and C.
Candidates pick Phase E options that describe a dated schedule, project plans, and detailed cost/benefit and risk analysis for each project.
'Opportunities and Solutions' sounds like planning, and Phase E outputs (work packages, transition architectures) look like plans.
What to do instead
Keep Phase E at the level of what to do and how to group it: consolidated gaps, candidate and grouped work packages, transition architectures, and a high-level Architecture Roadmap. Sequencing and timing, the Implementation and Migration Plan, and detailed cost/benefit and risk analysis per project are Phase F. Options about dates, funding or per-project business cases belong to Phase F.
Candidates assume Phase F produces the Architecture Contract signed with implementers, or that Phase F is where Architecture Compliance reviews are performed.
Phases F and G both concern implementation readiness, and 'Migration Planning' sounds contractual and governance-heavy.
What to do instead
Assign Phase F the Implementation and Migration Plan, with transition architectures confirmed, work packages phased and scheduled, benefits, cost and risk stated, and implementation recommendations. The Architecture Contract is agreed in Phase G between the sponsor and the implementing organisation, and compliance reviews are Phase G governance activity.
Candidates answer that Phase G handles change requests to the architecture, or that Phase G produces the Implementation and Migration Plan and then hands off.
Implementation Governance and change management are adjacent in practice, and both involve live projects.
What to do instead
Scope Phase G to delivery governance: negotiating and confirming Architecture Contracts, running Architecture Compliance reviews, and managing dispensations or exceptions. Requests for change to the architecture, and the decision on whether to re-enter the ADM, belong to Phase H. If an option mentions a change request or a re-architecture decision, it is Phase H.
Candidates treat every change request as automatically triggering a full new ADM cycle, or classify every change as incremental without distinguishing the TOGAF change categories.
The ADM is described as iterative, so 'start a new cycle' feels like the safe answer, and the three categories are easily collapsed into one.
What to do instead
Learn the classification and its consequence: simplification and incremental changes are handled through change management with updates to the architecture and the repository, while re-architecting change, being major, sends the team back into the ADM from the Architecture Vision onward. Match the chosen option to the category the scenario describes.
Candidates place Architecture Requirements Management as a discrete step in the ADM sequence, for example between Phase A and Phase B, or as a final phase after Phase H.
It is drawn as a central ellipse on the ADM diagram and is easily misread as a stage rather than a continuous function.
What to do instead
Describe it as a continuous, central activity that captures, stores and circulates requirements through every phase, maintaining the Architecture Requirements Specification and the requirements repository. Pair this with technique placement: Business Scenarios are the main elicitation technique in Phase A, and Gap Analysis is applied repeatedly across Phases B, C and D.