Summary and revision

Enterprise Architecture Summary

Use this page to recap the operating logic of the course, repair the most common TOGAF misconceptions, and rehearse the questions that should remain live in your head when you review real enterprise architecture work.

Four Recap Themes

  • Read TOGAF as a backbone with targeted depth: Keep the core standard as the method spine, then bring in Series Guides only where the architecture problem requires more depth.
  • Always tie architecture to enterprise consequences: A TOGAF artefact matters only if it changes decisions, exposes dependencies, or improves governance and delivery control.
  • Use one recurring case to see the method properly: The London Grid Distribution case is meant to show continuity across phases, not to provide isolated examples.
  • Tailoring is part of doing TOGAF well: The method should be scaled intentionally by scope, pace, and risk, not blindly maximised or gutted.

Misconception Repair

  • TOGAF is only an ADM wheel.
    The ADM matters, but TOGAF also includes content guidance, governance, capability design, and supporting guides that make the phases usable.
  • Capability maps are the same as business architecture.
    Capabilities are important, but business architecture also covers value streams, business models, organisation, services, goals, measures, and business-layer gaps.
  • A single source of truth is the whole data architecture answer.
    Enterprise information architecture usually requires authority boundaries, stewardship, metadata, publication rules, and controlled reuse rather than one magical master.
  • Tailoring means removing anything that looks formal.
    Tailoring should preserve the controls that make the architecture explainable and governable, even when the artefact set is small.

Revision Questions

  1. What enterprise decision is improved by each major artefact in the London case?
  2. Which TOGAF guide would you reach for first if your problem was capability planning, metadata, or agile architecture cadence?
  3. How does a transition architecture differ from an unfinished target state?
  4. When does TOGAF become the wrong fit for the problem?
  5. Which comparison framework adds modelling depth, which adds business-architecture depth, and which adds stronger public-sector viewpoint or reference-model structure?

Stage-by-stage recall map

  • Stage 1. Orientation and TOGAF 10 in practice
    Explain the difference between the TOGAF core, Series Guides, Library material, and your own professional judgement without collapsing them into one undifferentiated source.
  • Stage 2. Preliminary Phase and Architecture Vision
    State the enterprise boundary, the main stakeholders, the architecture principles, and the minimum reason the architecture work is authorised to proceed.
  • Stage 3. Business Architecture
    Describe the business problem through capabilities, value streams, organisation, and business-layer gaps rather than through systems alone.
  • Stage 4. Information Systems Architecture
    Explain who holds information authority, what must be published, how application boundaries are drawn, and why one vague source-of-truth slogan is not enough.
  • Stage 5. Technology Architecture
    Show how resilience, security, interoperability, and technology constraints trace back to business and information needs.
  • Stage 6. Opportunities, Solutions, Migration, and Delivery
    Walk from gaps to work packages, transition states, sequencing, and readiness without turning the roadmap into a wish list.
  • Stage 7. Running EA as a Capability
    Explain what the Architecture Board decides, how waivers stay visible, and why repository stewardship is part of capability rather than admin overhead.
  • Stage 8. Comparison, tailoring, limitations, and capstone
    Compare TOGAF accurately with companion approaches, tailor it proportionately, and trace the London case end to end as one coherent evidence pack.

Framework comparison prompts

  • TOGAF and ArchiMate
    Can you state, without hesitation, which one gives the method and which one gives the modelling language?
  • TOGAF and BIZBOK
    Can you explain the difference between business-architecture depth and enterprise-method breadth without forcing the two into a winner-takes-all choice?
  • TOGAF, DoDAF, and FEAF
    Can you name the public-sector context that shaped DoDAF and FEAF before you compare them with a general enterprise standard?
  • TOGAF and Zachman
    Can you explain why structure or ontology is not the same thing as a delivery method?

Capstone self-audit

  1. Choose one London concern and trace it across principles, business architecture, information architecture, technology, roadmap, and governance.
  2. Name one artefact in the capstone that could be removed with no decision loss. If you cannot, the pack is probably coherent. If you can, explain why it is still there.
  3. Describe one place where TOGAF helped and one place where professional judgement still had to do the real work.
  4. Decide whether the London pack is proportionate to its enterprise problem, then explain which parts you would lighten for a smaller or faster context.
Reopen the London capstoneOpen the reference pack

Assessment routes