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

TOGAF and ArchiMate are complementary Open Group standards with different jobs. TOGAF provides the method, structure, governance, and body of knowledge for running enterprise architecture, answering how work is scoped, who governs what, and how architecture connects to delivery. ArchiMate provides a visual modelling language for representing that architecture formally. The official mapping between them is W14C, the TOGAF Framework and ArchiMate Modeling Language Harmonization White Paper, which shows how TOGAF content metamodel elements map to ArchiMate elements. The White Paper predates the current editions of both standards, but the mapping logic still holds, and the current ArchiMate 3.2 framework defines six layers, Strategy, Business, Application, Technology, Physical, and Implementation and Migration, with Motivation as an aspect that cuts across the layers rather than a seventh layer.

The honest case for adding ArchiMate rests on five specific gains, cross-layer traceability, repository consistency, formal motivation modelling, plateau and gap modelling for transitions, and tool interoperability. Every one is a precision gain and none is a method gain. ArchiMate does not define how to scope work, supply decision rights or escalation logic, provide a compliance review or waiver mechanism, or explain how architecture connects to delivery. A repository full of elegant ArchiMate views can still sit on top of weak architecture practice.

That is why the module closes on a selective combination principle. Use TOGAF to define the problem, method boundaries, and governance points, introduce ArchiMate where the team needs more precise and analysable models than informal diagrams, model only what earns its keep, keep the repository readable to people who are not fluent in the notation, and test each formal view against one question. Does this model improve a real decision, trace, or review?

BIZBOK, maintained by the Business Architecture Guild, is a guide to the business architecture body of knowledge. That already fixes the framing. The comparison is not between two identical kinds of thing but between business-architecture depth and a fuller enterprise-architecture method. BIZBOK does not claim to provide an end-to-end development method, governance model, migration planning logic, or repository stewardship. TOGAF does claim all of those, but its business-architecture treatment in Phase B and the supporting Series Guides, G211 on capabilities and G178 on value streams, is necessarily less specialised than a body of knowledge that puts business architecture at the centre.

The strongest argument for BIZBOK-style depth is that it stops the rest of the architecture being built on fuzzy business assumptions. If the business layer is thin, everything built on top of it inherits that weakness, capability maps with vague labels, value streams nobody can walk, business models that never connect to delivery choices. TOGAF still adds what a business-architecture body of knowledge is not designed to provide, the end-to-end ADM, cross-domain integration into information systems and technology architecture, governance and decision rights, migration and transition logic, and repository stewardship.

The clean combination follows a designed integration boundary. Agree one vocabulary for shared concepts such as capability and value stream, let business-architecture depth feed Phase B, keep TOGAF carrying the cross-domain method, hold one repository rather than two, and have governance cover the boundary. The poor combination runs business architecture in one language and enterprise architecture in another and never reconciles the artefacts.

DoDAF and FEAF come from specific public-sector settings, and that single fact explains most of the differences in emphasis and artefact structure. DoDAF structures the framework around viewpoints, All, Capability, Data and Information, Operational, Project, Services, Standards, and Systems, because defence coordination needs shared understanding across organisations that may never have worked together. DoD components are expected to conform to DoDAF to the maximum extent possible, a stronger expectation than anything TOGAF imposes. FEAF describes a business-based documentation and analysis framework with current views, future views, and a transition plan, and FEAF v2 centres on the Consolidated Reference Model, because federal agencies need a common vocabulary for cross-agency planning and investment justification. TOGAF, by contrast, is a general standard that expects tailoring. The differences follow from operating context, not quality.

The TOGAF Standard addresses coexistence directly. The Introduction and Core Concepts volume of the 10th Edition includes a section called Using the TOGAF Standard with Other Frameworks, which states that TOGAF deliverables may be replaced or extended by a more specific set defined in any other framework the architect considers relevant. Framework selection is a design decision shaped by context and existing commitments, not an absolute quality ranking.

What a regulated utility can borrow is the discipline, never the context. Viewpoint discipline transfers wherever one narrative cannot serve every stakeholder, and reference-model thinking transfers wherever taxonomy and cross-organisation consistency matter, but the specific DoDAF product catalogue and the specific federal categorisation schemes do not. The worst outcome is cargo-cult borrowing, copying artefact names from another sector without understanding why those structures exist in their native setting.

The official Zachman source describes the framework as a schema, more specifically an ontology, and states plainly that it is not a methodology. That is a design choice, not a weakness. The matrix crosses six interrogative columns, what, how, where, who, when, and why, with six audience rows, planner, owner, designer, builder, implementer, and worker. Each cell represents a specific type of enterprise description from a specific perspective, and the power of the structure is that it forces completeness questions. If every row describes the what but nothing describes the when, the enterprise description has a gap.

A schema tells you what kinds of descriptions are possible. A method tells you how to produce them, who is involved, what governance applies, and how to move from current state to target state. Comparing the two as rival methodologies is the most common and most damaging error, so the working pattern is complementary. Use TOGAF to run the architecture work, use the Zachman grid as a review lens at key points to challenge descriptive coverage, treat any gap it reveals as a question rather than an order to create an artefact, return whatever is created to the one governed repository, and never build a parallel governance structure around the grid.

The module first clears away persistent misconceptions. TOGAF does not mean one huge document set, because the standard expects tailoring and the G186 and G210 guides address proportionate practice directly. It does not guarantee good architecture, because the standard gives scaffolding while the quality of the building depends on the builders. It is not only for very large enterprises, it is not a waterfall methodology, since Part 3 addresses iteration and G210 and G20F cover agile delivery, and certification demonstrates knowledge of the standard rather than the ability to apply it well.

The central distinction is bad fit versus bad implementation. Many angry TOGAF stories are implementation failures, weak tailoring, artefacts with no decision purpose, ceremonial governance, architecture detached from delivery. The diagnostic tests make the difference visible. For implementation, ask whether removing the architecture work would worsen any decision, who uses each artefact, whether governance changes outcomes, and whether architecture visibly changes delivery. For fit, ask whether the problem spans domains, involves real transition states, needs formal decision rights, and requires coordination across teams.

Some contexts genuinely do not justify the method. The module names seven, a tightly bounded local change, an urgent incident, a purely technical design problem inside one team, an organisation that refuses governance visibility, a need for only a modelling language or classification aid, a very early-stage startup, and architecture used to protect hierarchy rather than improve decisions. The business-leader framing, the course's own with G184, The TOGAF Leader's Guide to Establishing and Evolving an EA Capability, as the nearest published treatment, reframes the whole question. Architecture must justify itself in cost, risk, speed, and regulatory terms, not in framework terms.

TOGAF expects tailoring as a design principle, and tailoring is not casual trimming. Good tailoring protects three things that disappear first when cutting is careless, decision memory, traceability, and exception governance. Almost everything else can vary, artefact depth, modelling formality, governance cadence, repository tooling, review frequency, and how many ADM phases receive explicit treatment. Even the lightest implementation keeps a clear statement of problem and scope, a findable record of the decisions that matter, a minimum useful artefact set, a review path for material exceptions, and traceable movement from current problems to target or transition decisions.

Four reference profiles calibrate the depth. A small low-risk single-team change needs a one-page scope, a decision log, and a lightweight exception path. A medium cross-team platform change keeps explicit domain interfaces, a small repository, and a roadmap with dependencies. High-risk or regulated enterprise change is where the fuller operating pattern earns its cost, with formal governance, architecture contracts, and documented compliance. Fast delivery with strategic consequence keeps architecture thin but fast, with tighter decision logs and explicit release conditions, and the G210 guide on agile sprints is directly relevant. The minimum viable architecture test then checks whether tailoring has cut too deep, the new-joiner, decision-trace, exception, roadmap, and repository questions.

The standard also names two further kinds of adaptation beside scaling by size, speed, and risk. Iterating the ADM means cycling within and across phases rather than running one linear pass, and tailoring the method to the enterprise reshapes the ADM to fit existing governance and delivery practice, with its formal home in the Preliminary Phase. Treat the three as distinct levers, and make every tailoring choice one you can explain.

The capstone is not a recap, it is a coherence test. The London case is walked in seven moves, each corresponding to a stage of the course. Define the enterprise boundary and architecture vision. Set principles and stakeholder concerns. Expose the business architecture. Clarify information authority, metadata, applications, and integration. Choose technology and resilience patterns. Sequence work packages and transition states. Run governance, compliance, and exceptions. If any move cannot explain how it relates to the moves before and after it, the pack has a traceability gap.

A defensible pack has three qualities. It is traceable, so every decision runs back to an enterprise concern and every concern runs forward to delivery decisions. It is proportionate, so every artefact earns its place by improving a decision, handoff, or review. And it is decision-bearing, so the pack visibly influences technology selection, roadmap sequencing, exception handling, and investment. A stack of individually plausible artefacts is a filing cabinet. The critical review method makes this testable, pick one concern and trace it end to end, challenge each artefact's decision purpose, test target-state claims against evidence, test exception governance, and assess proportionality.

The stage closes on an honest judgement about what did the work. TOGAF contributed structure and sequence, the content metamodel, the governance framework, the Series Guides, and a shared vocabulary. Domain knowledge, stakeholder engagement quality, design trade-offs, proportionate tailoring, and critical self-assessment remained the work of professional judgement. The standard provides the scaffolding, and the quality of the building still depends on the builders.

The comparisons stop being abstract when they are asked of London. ArchiMate would earn its keep on the capability-to-application mapping, the information authority flows, and the transition plateaus, and not on principle statements or board charters. BIZBOK-style depth could sharpen the capability decomposition and the new-connections value stream. A regulated utility that works with Ofgem, NESO, and other network companies can borrow DoDAF viewpoint discipline and FEAF reference-model thinking without inheriting either sector's context, and the Zachman grid offers a completeness lens at review points. In every case TOGAF still supplies the end-to-end method, the governance, and the one repository.

On the tailoring spectrum London sits deliberately heavy, primarily Profile 3 for its regulatory, network, and OT and IT architecture, with Profile 4 treatment in the digital workstreams and lighter profiles for internal tooling. That makes it an upper reference point for what the full method looks like when risk and coordination needs are high, not a claim that every enterprise should work at that depth. The capstone then walks the case in seven moves, and it passes only if one enterprise concern can be followed from first principle to governed delivery decision without losing the thread.