Stage 8. Comparison, Tailoring, Limitations, and Capstone: phase summary

6 min read 5 sections 7 key points

This phase turns from learning TOGAF to judging it: comparing the standard honestly against five other approaches, deciding when it does and does not fit, tailoring its depth to real size, speed, and risk, and proving the whole London Grid Distribution case locks together as one traceable architecture pack. The running thread is that TOGAF is a method, not a winner of every contest, and that an artefact only earns its place when it changes a decision. By the end you can compare without slogans, tailor without abandoning, and critique an architecture pack rather than just describe it.

Compare by what each approach is built to do, not by ticks and crosses

The four comparison modules each fix a different framing error. ArchiMate is a modelling language, not a method, mapped to TOGAF through the W14C guide across its seven layers; BIZBOK is business-architecture depth, not a full enterprise method; DoDAF and FEAF were shaped by defence coordination and federal cross-agency planning, so their viewpoint catalogues and reference models follow from context rather than quality; Zachman is a schema and ontology, not a methodology. A comparison that tests one approach against capabilities it never claimed to offer is broken before it starts.

Each approach contributes something TOGAF does not, and TOGAF still carries the method

BIZBOK can sharpen London's capability decomposition and value-stream analysis; ArchiMate would formalise its capability-to-application mapping, information authority flows, and transition plateaus where formal modelling earns its keep; DoDAF lends viewpoint discipline and FEAF lends reference-model thinking that a regulated utility working with Ofgem, NESO, and other DNOs can borrow selectively; Zachman acts as a completeness lens at review points. In every case TOGAF still supplies the end-to-end ADM, cross-domain integration, governance, migration logic, and one repository. The discipline is borrowing the idea without inheriting another sector's context, and treating any gap a lens reveals as a question, not an automatic order to create an artefact.

Diagnose bad fit versus bad implementation before blaming the standard

Many angry TOGAF stories are really implementation failures: weak tailoring, artefacts with no decision purpose, ceremonial governance, and architecture detached from delivery. Module 62 separates these with diagnostic tests and the central question, if you removed the architecture work, which enterprise decisions would get worse? It also names genuine bad-fit cases where TOGAF is the wrong tool: a tightly bounded local change, an urgent incident, a single-team software design problem, an organisation that refuses governance visibility, a need for only a modelling language or classification aid, an early-stage startup, and architecture used to protect hierarchy. The G21B business-leader view reframes all of it: architecture must justify itself in cost, risk, speed, and regulatory terms, not in framework terms.

Tailor by designing a proportionate operating model, not by deleting what feels boring

Tailoring protects decision memory, traceability, and exception governance while letting artefact depth, governance cadence, modelling formality, repository tooling, and ADM phase treatment vary. Module 63 gives four reference profiles (small low-risk, medium cross-team, high-risk regulated, and fast delivery with strategic consequence), the G20F principle that every tailoring choice must be explainable, and a five-part minimum viable architecture test (new-joiner, decision-trace, exception, roadmap, repository). London sits mainly in Profile 3 with Profile 4 in its digital workstreams, making it a heavy upper reference point rather than a universal template.

The capstone is a coherence test of trace lines, not a recap

Module 64 walks London in seven moves from architecture vision and principles through business, information, technology, roadmap, and governance, testing whether one enterprise concern can be followed end to end without losing the thread. A defensible pack is traceable, proportionate, and decision-bearing; a stack of individually plausible artefacts is a filing cabinet. The honest closing judgement is that TOGAF provided structure, the content metamodel, governance, Series Guides, and shared vocabulary, while domain knowledge, stakeholder engagement, design trade-offs, proportionate tailoring, and critical self-assessment remained the work of professional judgement.

Watch out for

  • Comparing TOGAF with ArchiMate, BIZBOK, DoDAF, FEAF, or Zachman as if they all do the same job, then concluding one is missing capabilities it never claimed to provide.
  • Calling deletion of activities you find boring tailoring, when real tailoring adjusts depth while preserving decision memory, traceability, and exception governance.
  • Treating a Zachman empty cell or any framework gap as an artefact that must be filled for completeness rather than asking whether it affects a real decision.
  • Judging an architecture pack by artefact count, diagram polish, or notation rather than whether each artefact is traceable and changes a decision.

Key takeaways

  • The official Zachman source calls the framework a schema and ontology, not a methodology, so it compares with TOGAF as classification lens versus method, not rival to rival.
  • W14C maps TOGAF content metamodel elements to ArchiMate's seven layers (Strategy, Business, Application, Technology, Physical, Implementation and Migration, Motivation); ArchiMate is notation, TOGAF is method.
  • DoDAF expects conformance and FEAF works through mandated reference models, while TOGAF expects tailoring; the differences follow from operating context, not quality.
  • The core diagnostic for TOGAF value: if you removed the architecture work, which enterprise decisions would get worse? If the answer is unclear, the work is not earning its place.
  • Good tailoring keeps decision memory, traceability, and exception governance visible even in the lightest implementation; the four profiles and the minimum viable architecture test calibrate how far to cut.
  • A defensible architecture pack is traceable, proportionate, and decision-bearing; every artefact must change a decision, handoff, or review.
  • London is deliberately a high-governance Profile 3 case so the full method can be shown; it is a teaching reference, not a claim that every enterprise should work at that depth.

With the comparison framing, fit diagnostics, tailoring profiles, and capstone trace-line test consolidated, the scenario practice puts them to work on realistic situations where you must choose the right approach, tailor it proportionately, and spot the broken trace before the timed stage assessment.

Start the scenario practice