TOGAF® Enterprise Architecture Foundation common mistakes
TOGAF® Enterprise Architecture Foundation · Understand the traps and how to avoid them.
Treating the ADM as a strict waterfall: when a question describes a change to an approved architecture, the candidate answers with the next numbered phase instead of Phase H or the Requirements Management centre.
Foundation questions reward recognition that the ADM is iterative and can be re-entered at any phase; linear memorisation of phase numbers hides the feedback loops.
What to do instead
Redraw the ADM from memory with Requirements Management at the centre and arrows from Phase H back to earlier phases. Practise mapping triggers such as change requests, scope changes, and gap findings to Phase H, Phase A, or the relevant architecture phase.
Confusing the Preliminary Phase with Phase A: the candidate says Phase A establishes the architecture capability and principles, or says the Preliminary Phase produces the Architecture Vision.
Both occur before architecture definition begins, and their names sound preparatory rather than distinct.
What to do instead
Separate the two by purpose: the Preliminary Phase prepares the organisation-principles, architecture capability, governance, tailored framework, tools-while Phase A scopes the initiative and produces the Architecture Vision, Statement of Architecture Work, and communications plan.
Using “Architecture Building Block” and “Solution Building Block” interchangeably, or placing Solution Building Blocks in the Architecture Continuum.
The terms are structurally similar and both describe reusable components, so candidates rely on surface wording rather than on where each belongs.
What to do instead
Anchor each term to its continuum: an Architecture Building Block specifies a capability or requirement at the architecture level and belongs in the Architecture Continuum; a Solution Building Block is implementation-specific and belongs in the Solutions Continuum, realising one or more Architecture Building Blocks.
Treating the Enterprise Continuum, the Architecture Repository, and the Architecture Content Framework as three names for one storage area.
All three concern architecture content, and exam wording often mentions them together without restating their distinct roles.
What to do instead
Learn a one-line distinction: the Continuum classifies architectures and solutions from generic to specific; the Repository is the actual holding area for artefacts; the Content Framework defines the metamodel and the structure of deliverables and artefacts. Match each question to classification, storage, or structure.
Swapping “view” and “viewpoint”, for example saying the viewpoint is what the stakeholder sees and the view is the template or set of conventions.
In everyday speech the words are nearly synonymous, and the exam tests the precise stakeholder–concern–viewpoint–view relationship.
What to do instead
Use a fixed chain: a stakeholder has concerns; a viewpoint is the template or conventions for constructing a view; a view is the representation seen by the stakeholder and conforms to a viewpoint. Rehearse with a short example such as a security stakeholder, a security viewpoint, and a security view.
Assigning project delivery decisions, budget approval, or IT service management to the Architecture Board when a question asks who approves architecture dispensations or monitors compliance.
Governance terminology overlaps with project boards and IT governance, so candidates pick the most familiar governing body.
What to do instead
Limit the Architecture Board to architecture governance: architecture compliance, dispensations, architecture contracts, resolution of architecture issues, and escalation. Distinguish it explicitly from a project board, steering committee, and service management function.
Choosing a phase from an artefact name alone-for example selecting Phase B for a question about Data Architecture-without checking the objective stated in the scenario.
Phase B is Business Architecture, while data and application architectures are developed in Phase C; abbreviated revision leads candidates to match the noun rather than the phase objective.
What to do instead
Build an objective-to-phase map: B for Business Architecture, C for Data and Application Architectures, D for Technology Architecture, E for Opportunities and Solutions, F for Migration Planning, G for Implementation Governance, H for Architecture Change Management. For each practice question, underline the objective before looking at the options.
Reciting TOGAF definitions accurately but failing structural questions that ask how the ADM, Architecture Content Framework, Enterprise Continuum, Architecture Repository, and Architecture Capability relate.
Definitions are memorised as isolated items, so the candidate cannot place a term within the overall framework structure.
What to do instead
Create a structural diagram: the ADM is the process; the Content Framework describes what is produced; the Continuum classifies content from generic to specific; the Repository stores it; Architecture Capability and Governance explain how the work is resourced and controlled. Test yourself by placing each new term into one of these categories.
Treating requirements as a Phase A deliverable only and treating Requirements Management as a phase that occurs once near the start of the ADM.
The ADM diagram places Requirements Management at the centre, but candidates often read it as an initial activity because Phase A mentions high-level requirements.
What to do instead
Memorise that Requirements Management is continuous and feeds every phase, while Phase A captures high-level requirements only as part of the Architecture Vision. Practise questions where a requirement changes after Phase E or G and identify the continuous management path rather than a single phase.
Skipping Architecture Capability content-for example, unable to name the elements that establish capability and instead answering with ADM phases or with architecture artefacts.
Candidates concentrate on the ADM process and treat capability, skills, governance structures, tools, and maturity as peripheral reading.
What to do instead
Study Architecture Capability as an organisational capability: roles and skills, architecture principles, governance bodies, tailored framework and methods, tools, and maturity assessment. Distinguish capability enablers from architecture content and from ADM phases, and practise questions that ask what must be in place before architecture work can be performed.