Orientation is learning what architecture work actually changes and how TOGAF 10 is shaped, so you reach for the right part instead of drowning in documents.
TOGAF 10 structure: the core, the Series Guides, and the Library
Enterprise architecture is the discipline of describing and governing how an enterprise is structured across business, data, application, and technology, so that change across all of them stays coherent. It exists to improve decisions, not to produce documents. TOGAF 10 is the most widely used framework for doing this, and orientation is about learning its shape before its detail.
This matters because most people meet TOGAF as a wall of publications and cannot tell the method from the supporting material. Reaching for the wrong part wastes weeks, and treating diagrams as the goal produces work that changes no decision at all. Knowing the structure is what lets you use the right part for the question in front of you.
The stage builds in order: first what architecture work actually is, then how TOGAF 10 is shaped into a core and its guides, how that relates to certification, how the repository and continuum hold assets, the vocabulary of deliverables and building blocks, and finally how to read the standard by problem rather than by page.
Underneath that structure sits the cycle this course runs through. The Architecture Development Method opens with the Preliminary Phase, which prepares the framework and principles, then moves through Phases A to H, from architecture vision and the business, data, application, and technology architectures into opportunities, migration planning, implementation governance, and change management. At the centre, Requirements Management feeds and disciplines every phase, so the cycle stays driven by what the enterprise actually needs.
The stage builds up in this order. Read it straight through on the first pass, or jump to any concept.
Picture an airline that announces it needs enterprise architecture but cannot say whether it means principles, diagrams, governance, or programme oversight. The work only becomes clear when you ask which decision it is meant to improve. Enterprise architecture is the discipline that makes the relationships, constraints, and consequences across business, data, application, and technology explicit enough for the enterprise to move as one. A redesign of loyalty pricing, for example, touches systems, partners, and obligations at once, and architecture is what keeps those views consistent.
It is tempting to assume that any document with boxes and arrows counts, so that a stack of diagrams and strategy slides becomes the work itself. That is document theatre, and it changes nothing. The better habit is to start from the decision and the cost of getting it wrong: if an artefact will not change a decision that crosses domains, it is not enterprise architecture, whatever it looks like on the page.
A learner opening TOGAF 10 for the first time usually cannot tell which parts are the method and which are optional depth. The standard answers this by separating a stable core, which holds the Architecture Development Method and the fundamental concepts, from a wider body published as Series Guides and the TOGAF Library. The move from version 9.2 to 10 made that split explicit, so the backbone now sits apart from the guidance that surrounds it.
Some dismiss this as a cosmetic repackaging and so read the whole thing straight through as one block, which is exactly the habit the structure is meant to break. The more useful approach is to read the core for the method and its concepts, then pull a single Series Guide only when a stage demands real depth. That way the core stays stable as a reference while the guidance can evolve around it without forcing a rewrite.
Once the core and guides split is clear, the Fundamental Content becomes a numbered document set you can navigate by problem. Picture a retailer reaching in: the TOGAF Standard structure and core concepts orient you, the Architecture Development Method gives the method itself, the ADM techniques and applying the ADM cover how to run it, the Architecture Content defines the outputs, and the EA Capability and Governance content sets up the function. You pull the named part the question needs, not the whole.
Consider a trainee at a bank who treats exam material, the core standard, and the wider guidance as one undifferentiated pile, and then revises the wrong thing for the wrong reason. TOGAF keeps three things apart: the normative core, the supporting Series Guides, and the certification paths that test only selected portions of that body. Practice is therefore always broader than whatever the exam happens to cover.
The trap is to believe that passing the certification proves competence, so the syllabus gets mistaken for the full set of skills an architect needs. Certification is most valuable when it enforces a shared vocabulary and a common structure across a team. Beyond that, it pays to study deliberately the repository discipline, stakeholder handling, and tailoring of the method that the exam never reaches, because those are what real architecture work demands.
Imagine a hospital with hundreds of architecture files that still cannot show how a principle, a standard, a baseline, and a roadmap relate to one another. TOGAF offers two ideas to fix this. The Enterprise Continuum classifies assets along a line from generic to specific, and the Architecture Repository is the navigable system that holds principles, models, requirements, building blocks, and governance records in one place that can actually be traced.
People often repeat this vocabulary while pointing at a shared drive, as if naming the parts turned an unnavigable heap into a repository. It does not. The standard a repository should meet is practical: a board or a delivery lead should be able to answer in minutes what was decided, which principle or requirement it relates to, which baseline and target it affects, and what delivery work or exception follows from it.
Take a team that calls every document a deliverable, every diagram an architecture, and every product choice a building block, and watch the confusion compound. TOGAF separates three terms. A deliverable is the contractual, packaged output; an artefact is a specific representation such as a single diagram; and a building block is a reusable component. A flat-pack furniture kit makes it concrete: the generic specification is the architecture building block, and the particular product you choose against it is the solution building block.
When these words blur, one diagram gets called all three at once and reuse becomes impossible to manage. The vocabulary works best as a hygiene test. A capability map is an artefact, the review pack that contains it may be the deliverable, and the reusable business or technology elements it describes are what later inform building blocks. Getting these words right early keeps the later phases that depend on them disciplined.
A common situation: a learner knows the publications exist but cannot move between core method content, the guides, and comparison reading without losing the thread. The reading strategy that holds is to start from the stage problem rather than from page order. If the problem is a confusing stakeholder landscape, the route is the Preliminary Phase and Phase A together with Business Scenarios; a roadmap question instead points to the later phases and the relevant guides.
Read straight through like a novel and anxiety takes over, so people keep collecting publications instead of applying the few that fit the question in hand. The standard is better treated as a method and a reference library at the same time, entered by the live problem. Read that way, each publication is pulled because it answers the current question, and the reading stays purposeful instead of becoming an end in itself.
Printable, fillable artefacts for putting this stage to work. Each cites its source, opens in the diagram workspace, and downloads as it stands.
Each row is one maturity dimension scored from one to five against the maturity model. The filled blue bar is the score and the pale remainder is the headroom, so the right-hand frontier shows at a glance where the capability is strong and where it has the furthest to climb.
Preliminary
Enterprise architecture is easiest to define by contrast. Read the same three rows, scope, horizon and output, across enterprise architecture, solution architecture and IT strategy to see where each one stops.
Preliminary
The normative Standard C220 is drawn as one enclosing region, with the five parts of Fundamental Content nested inside it. The Series Guides sit outside, joined by an arrow that explains rather than changes the source of truth.
ADM-wide
Three levels grow left to right. Each column names only the publications it adds, and every level requires the publications of the levels before it.
ADM-wide
Three nested bands run from the outer Deliverable, the contractual package a stakeholder signs off, through the Artefacts inside it, to the reusable Building Blocks they are composed from. A Viewpoint sits apart as a lens that reads across all three.
ADM-wide
Three parallel columns each list the TOGAF sections to read in order for one reader profile. Pick the column that matches your problem and read top to bottom; the paths share the C220 core but route through it differently.
ADM-wide
A claim flows down through five stages to the regulator record that anchors it. Each stage carries the test it must pass, and the reject lane on the right names the failure mode that bounces a claim at that stage.
ADM-wide
The architecture development method runs from the Preliminary Phase through Phases A to H, and this map names each phase with the decision it owns so the cycle the course follows is visible at once.
ADM-wide
Check what has landed. The practice set gives instant feedback as you go; the timed assessment mirrors a real sitting, with a pass record and a breakdown by domain.
