TOGAF Enterprise Architecture common mistakes
TOGAF Enterprise Architecture · Understand the traps and how to avoid them.
Answering the definitional core-concept questions (what the TOGAF Standard is, what counts as an 'enterprise', the difference between architecture and an architecture description) from memory of the ADM cycle diagram rather than from the stated definitions, and therefore picking answers that describe the Standard as a prescriptive process rather than a framework of concepts plus an adaptable method.
Candidates jump straight to memorising Phases A–H because that is where the volume of exam content appears to be, and skip the Introduction and Core Concepts material as 'not examinable'.
What to do instead
Read the Introduction and Core Concepts section first and write out verbatim-quality summaries of the key definitions and of how the Standard is structured (Fundamental Content plus Series Guides). Practise explaining in one sentence why TOGAF is a framework, not a method, and where the 'enterprise' boundary is drawn relative to 'solutions'.
Using 'deliverable', 'artifact' and 'building block' interchangeably, and picking an architecture building block (ABB) when the question describes a reusable, implemented solution component (or vice versa).
In ordinary architecture conversation the words overlap, and candidates recall the content framework only as a list of diagram names rather than as three distinct levels of content with different owners and re-use characteristics.
What to do instead
Learn the three definitions as a hierarchy: deliverables are formally reviewed, signed-off work products; artifacts are the finer-grained catalogs, matrices and diagrams inside them; building blocks are the potentially reusable components. Then anchor ABBs to the architecture/design stage (evolution described, not implemented) and SBBs to the solution delivery stage, and test yourself on which side of the Architecture Definition Document a given item sits.
Mis-assigning content to ADM phases - for example placing the Statement of Architecture Work in Phase B, the Architecture Roadmap outside Phase E/F, or the Architecture Definition Document in Phase A - and choosing answers that look plausible because the phase names are familiar.
The ADM is memorised as a ring of phase names with a few headline outputs, without building a phase-by-phase picture of purpose, objectives, steps, inputs and outputs; adjacent phases then blur together under exam pressure.
What to do instead
Build a one-page phase table with four columns: purpose, key inputs, key outputs, notable steps. Populate it from the Standard's own phase descriptions, not from secondary summaries. Pay particular attention to the A/B boundary (vision and Statement of Architecture Work versus the baseline/target business architecture) and the E/F boundary (roadmap creation versus transition architecture and implementation planning).
Treating the ADM as a single-pass waterfall - forgetting that Requirements Management sits at the centre and runs continuously, and failing to apply iteration across the Strategic, Segment and Capability levels of the Architecture Landscape.
The circular diagram is easy to read as a sequence of eight boxes, and candidates rarely rehearse questions about which iteration cycle (capability, architecture development, transition planning, or governance) a described scenario belongs to.
What to do instead
Rehearse three separate mental models: the continuous Requirements Management activity feeding every phase, the four iteration cycles, and the three levels of architecture with the scope each one covers. For any scenario question, first ask 'which level and which iteration is this?' before looking at the options.
Confusing the named guidelines and techniques with each other and with the phases that use them - for example selecting Business Transformation Readiness Assessment when the scenario is about defining objectives and scope, or selecting Capability-Based Planning when the scenario describes identifying differences between baseline and target.
The technique names are all 'architecture-sounding' and candidates learn the list as vocabulary without attaching each technique to the question it answers and the phase in which it is normally applied.
What to do instead
For each technique, record one line: the question it answers, the typical phase, and one distinguishing keyword. Business Scenarios answer 'what is the business outcome and how do we express it'; Business Transformation Readiness Assessment answers 'can the organisation absorb this change'; Gap Analysis answers 'what is missing between baseline and target'; Capability-Based Planning answers 'how do we structure planning around business capabilities'; Interoperability Requirements answers 'what must be shared and how'.
Selecting a vague, aspirational statement as the correct form of an architecture principle, or accepting an option that omits rationale and implications, or confusing a principle with an architecture requirement or a constraint.
Principles in everyday business writing are slogans, so candidates apply ordinary usage instead of the Standard's required anatomy and quality criteria (for example completeness, specificity and measurability), and they collapse the distinction between 'we will always decide this way' and 'we must deliver this'.
What to do instead
Memorise the recommended anatomy (name, statement, rationale, implications) and the quality criteria. Practise classifying a set of candidate statements as principle / requirement / constraint / guideline, and reject any option that is untestable, has no rationale, or states something that must simply be complied with.
Guessing where content lives in the Architecture Repository - putting standards in the Reference Library, treating the Governance Log as the place for architecture requirements, or conflating the Architecture Landscape with the Solutions Landscape.
The repository components are studied as a diagram with eight boxes and no worked examples, so the boundaries between them feel arbitrary and candidates default to the most familiar-sounding box.
What to do instead
For each repository component write a one-line rule with an example item: approved standards and industry reference material go in the Standards Information Base and Reference Library; the Architecture Landscape holds the architectures in use at the three levels; the Solutions Landscape holds deployed solution descriptions; the Governance Log records decisions, dispensations and compliance outcomes; architecture requirements are held in the Requirements Repository. Also be clear on how the Enterprise Continuum relates to the repository without being a part of it.
Mixing up governance roles and compliance outcomes - crediting the Lead Enterprise Architect or the sponsor with decisions that belong to the Architecture Board, or failing to distinguish a dispensation from a compliance review outcome, or treating all non-compliance as automatically blocking.
Governance questions are written as short organisational scenarios and candidates answer from general management intuition rather than from the defined responsibilities and the defined set of compliance outcomes.
What to do instead
Write a responsibility map for Architecture Board, Architecture Sponsor, Lead Enterprise Architect, Architecture Manager and the architecture team, and a separate list of compliance outcomes with the exact meaning of each (including dispensation and the conditions under which a decision to proceed is recorded). Then re-read Phase G and the Architecture Governance material and check every mapping against it.
Skipping the Preliminary Phase as 'just setup' and therefore missing questions about establishing the Architecture Capability - the maturity assessment, the skills and roles, the tailoring of the ADM, the definition of architecture principles and the placement of the architecture function within the operating model.
Phase A feels like the real start of the method, and the Preliminary Phase is short in the text but disproportionately represented in scenario questions about capability, operating model and tailoring.
What to do instead
List every output the Preliminary Phase is responsible for ('the things you need before you can do architecture') and rehearse the distinction between setting up the capability and producing an architecture. Learn the maturity model and skills framework concepts by name and purpose, and be able to say which preliminary decisions belong to the sponsor versus the architecture function.
Applying phase-gate, big-design-up-front logic to agile and digital scenarios, and rejecting answers that describe lightweight, iterative, 'just enough' architecture, deferred decisions, or architecture work embedded in delivery teams - or conversely refusing to allow any tailoring of the ADM.
The ADM diagram and the deliverable-heavy content framework create an impression of a heavyweight process, and candidates have not studied the guidance on adapting the ADM and on architecture in agile and digital contexts.
What to do instead
Study the tailoring guidance and the Series Guides on agile and digital transformation, and learn the vocabulary of adaptation: iteration, minimum viable architecture, emergent design, decision deferral, architecture runway and the shift from gatekeeping to enablement. Then practise scenario questions by first identifying the delivery context and only afterwards judging whether a heavyweight or lightweight behaviour is appropriate.