TOGAF with ArchiMate

The official Open Group complementarity guidance is clear. The TOGAF Standard provides the method, structure, governance, and body of knowledge for running enterprise architecture. The ArchiMate language provides a visual modelling language and notation for representing architecture.

TOGAF answers questions like: how should architecture work be scoped? What ADM phases apply? Who governs what? How are exceptions handled? How does architecture connect to delivery?

ArchiMate answers questions like: how should a cross-layer dependency be represented visually? What notation distinguishes a business service from a business process? How can motivation, behaviour, and structure be expressed in a consistent visual language?

People often compare them as if they were rival frameworks competing for the same job. They are not. TOGAF explains how architecture work should be organised and governed. ArchiMate helps the enterprise describe what that architecture looks like in a more formal and analysable way.

W14C, the TOGAF Framework and ArchiMate Modeling Language Harmonization White Paper (subtitled A Practitioner's Guide to Using the TOGAF Framework and the ArchiMate Language), is the official mapping guide. It shows how concepts from the TOGAF content metamodel map to ArchiMate elements. The mappings are not always one-to-one because the two standards have different granularity and purpose.

One caution on vintage. W14C came out of the TOGAF 9.1 and ArchiMate 2.1 harmonisation project, so it predates the current editions of both standards. The mapping logic still holds, but the layer structure below follows the current ArchiMate 3.2 framework, which added the Strategy layer and the Physical extension after the White Paper was published.

ArchiMate layers, the Motivation aspect, and their TOGAF counterparts

The ArchiMate 3.2 full framework defines six layers. Motivation elements form an aspect that cuts across those layers, not a seventh layer, which matters because motivation concepts attach to elements at every level rather than sitting in a stratum of their own.

• Strategy layer (ArchiMate). Maps to TOGAF capability, course of action, and resource concepts. ArchiMate adds explicit strategy elements (Capability, Course of Action, Resource) that TOGAF addresses through the business architecture and capability planning guides (G211, G178).
• Business layer (ArchiMate). Maps to TOGAF business services, processes, functions, roles, actors, and business objects. This is the closest mapping because both standards share the same conceptual territory.
• Application layer (ArchiMate). Maps to TOGAF application components, application services, and logical/physical application models. ArchiMate adds formal distinction between application services (what is offered) and application components (what provides it).
• Technology layer (ArchiMate). Maps to TOGAF technology components, platform services, and infrastructure. ArchiMate formalises the distinction between technology services and the nodes/devices that provide them.
• Physical layer (ArchiMate). Formally an extension of the Technology layer, covering equipment, facilities, distribution networks, and materials. Maps to TOGAF physical infrastructure and facility concepts. This layer is particularly relevant for London because distribution network assets, substations, and OT equipment are physical elements.
• Implementation and Migration layer (ArchiMate). Maps to TOGAF work packages, plateaus, and implementation migration plans from Phase E and Phase F. ArchiMate adds explicit modelling of plateaus and gaps that TOGAF describes procedurally.
• Motivation aspect (ArchiMate). An aspect that cuts across the layers rather than a layer in its own right. Maps to TOGAF drivers, goals, objectives, principles, requirements, and constraints. ArchiMate provides a formal notation for these elements that TOGAF addresses through textual artefacts.

Key concept mappings from W14C

• TOGAF Business Service maps to ArchiMate Business Service
• TOGAF Organisation Unit maps to ArchiMate Business Actor
• TOGAF Architecture Building Block maps to ArchiMate elements at the appropriate layer
• TOGAF Data Entity maps to ArchiMate Business Object or Data Object depending on context
• TOGAF Application Component maps to ArchiMate Application Component
• TOGAF Technology Component maps to ArchiMate Node, Device, or System Software
• TOGAF Work Package maps to ArchiMate Work Package in the Implementation layer
• TOGAF Principle maps to ArchiMate Principle in the Motivation aspect
• TOGAF Gap maps to ArchiMate Gap in the Implementation layer

One mapping walked end to end

Mapping tables become clearer when you follow a single chain all the way through. Take London's new connections service, which runs through the capstone case.

• Business. The TOGAF business service "Manage new connections" becomes an ArchiMate Business Service, realised by a Business Process and performed by the connections team modelled as a Business Actor.
• Data. The TOGAF data entity "Connection request" appears twice: as a Business Object where the business defines and owns it, and as a Data Object where the connections system stores and processes it. The realisation relationship between the two records exactly where the business concept meets its application representation.
• Application. The TOGAF application component "Connections management system" becomes an ArchiMate Application Component, and its Application Service serves the business process. The what-is-offered versus what-provides-it distinction stays explicit instead of living in a diagram convention.
• Technology. The platforms hosting the system become Nodes and System Software in the technology layer, while the substation equipment the service ultimately touches sits in the physical extension.
• Change. The Phase E work package that replaces the legacy connections system becomes an ArchiMate Work Package, the target operating state becomes a Plateau, and the residual shortfall is recorded as a Gap.

The payoff is traceability. When the connection request data model changes, the model shows which processes, services, and work packages are affected without anyone reassembling the picture from separate catalogues and matrices. That is what complementarity means in practice: TOGAF names the artefacts and the method steps, ArchiMate connects their contents into one analysable structure.

The honest case for adding ArchiMate to a TOGAF practice rests on a small number of specific gains, not on a general sense that formal is better than informal. Five stand up to scrutiny.

• Cross-layer traceability. ArchiMate provides a formal notation for expressing relationships between business, application, and technology layers. This makes impact analysis and dependency mapping more rigorous than informal diagrams.
• Repository consistency. When several architects contribute to one repository, a shared modelling language reduces interpretation drift. Without a common notation, each architect invents their own diagramming conventions.
• Motivation modelling. ArchiMate's Motivation aspect gives formal structure to goals, principles, requirements, and constraints that TOGAF typically captures in text form. This can make the rationale behind architecture choices more visible and testable.
• Transition modelling. The implementation and migration layer provides explicit plateau and gap modelling that makes transition states more formal and analysable.
• Tool interoperability. ArchiMate is supported by a wide range of modelling tools. Using a standard notation makes it easier to exchange models between teams and tools.

Notice what unites these five. Each is a precision gain: relationships become explicit, drift becomes visible, and analysis becomes repeatable. None of them is a method gain. A team that adopts ArchiMate acquires sharper instruments, not a different way of deciding what to build, who approves it, or how exceptions are handled.

The consulting team in the opening story achieved most of these gains and still failed, because precision was never their problem. Readability and governance were. That is why the next section matters as much as this one.

ArchiMate does not supply the governance system, scope logic, stakeholder management, or migration method that TOGAF provides. Specifically:

• ArchiMate does not define how to scope architecture work or decide which domains to include.
• ArchiMate does not provide decision rights, board composition, or escalation logic.
• ArchiMate does not define a compliance review process or waiver mechanism.
• ArchiMate does not provide a skills framework or capability maturity model.
• ArchiMate does not explain how architecture connects to delivery, programme governance, or operational change.

The gap shows up in review meetings. One organisation I assessed had a complete ArchiMate model of its target state and no record of who had agreed it. When a delivery programme diverged from the model, nobody could say whether the divergence was an approved exception or an accident, because there was no compliance review to consult and no waiver trail to check. The model was precise about decisions that had never actually been made.

A repository full of elegant ArchiMate views can still sit on top of weak architecture practice if the method, governance, and delivery interfaces are absent.

If ArchiMate strengthens some parts of TOGAF practice and does nothing for others, the working rule cannot be adopt or avoid. It has to be selective. This course uses a five-step principle for deciding where formal modelling earns its place.

1. Use TOGAF to define the enterprise problem, method boundaries, governance points, and artefact expectations.
2. Introduce ArchiMate where the team needs more precise, reusable, and analysable models than informal diagrams can provide.
3. Model only what earns its keep. Do not translate the whole repository into ArchiMate simply because the notation exists.
4. Keep the repository readable by stakeholders who are not fluent in modelling notation. Formal views should strengthen communication, not replace explanation.
5. Test each formal view against one question: does this model improve a real decision, trace, or review? If not, it is not earning its place.

Step five is the one that keeps the other four honest. It is easy to defend a model on the grounds that it might be useful one day. It is much harder, and far more useful, to name the decision, trace, or review the model improved in the last quarter. If nobody can, the model is stock rather than tooling, and maintaining it is a cost without a customer.

Applied to the opening story, the principle would have stopped the wholesale translation before it started. The stakeholders' problem was comprehension, not precision, so the first investment should have been fewer views, better explained, with formal models reserved for the cross-layer traces where notation genuinely sharpens the answer.

London has enough cross-domain complexity to benefit from formal modelling in specific areas.

• Capability to application mapping. London's capability map links to multiple application components. ArchiMate would formalise these relationships and make impact analysis more rigorous.
• Information authority flows. The information authority model defines which source owns which data domain. ArchiMate's data object and business object notation could make authority boundaries more explicit and testable.
• Transition state modelling. London's multi-year roadmap includes defined transition states. ArchiMate's plateau and gap modelling would formalise these transitions beyond textual descriptions.
• OT/IT boundary. The physical layer and technology layer would help formalise the distinction between operational technology assets and information technology components.

Where ArchiMate would not add value for London: stakeholder engagement documents, principle statements, board charters, and governance procedures. These are text-based governance artefacts that do not benefit from formal modelling notation.