TOGAF with ArchiMate
This is the first of 7 Comparison, Tailoring, and Capstone modules. It covers the W14C TOGAF-ArchiMate mapping in full, including all concept mappings between the two standards. The central point is that TOGAF and ArchiMate are complementary because they solve different problems: method versus modelling language. Both are Open Group standards, but one does not replace the other.
By the end of this module you will be able to:
- Explain in plain language why TOGAF and ArchiMate are related but not interchangeable
- Describe the W14C concept mappings between TOGAF content metamodel elements and ArchiMate elements
- Identify the ArchiMate layers (Strategy, Business, Application, Technology, Physical, Implementation and Migration, Motivation) and their TOGAF counterparts
- Explain where ArchiMate strengthens TOGAF practice and where it does not help
- Apply a selective combination principle: model what earns its keep, not everything the notation supports
- Apply method-versus-notation thinking to the London case and its repository artefacts
Real-world case
Richer views. Still unread.
A programme architect once told me that adopting ArchiMate had "solved their TOGAF problem." When I asked what the problem had been, the answer was revealing: stakeholders could not read the architecture views. Six months after adopting ArchiMate, the views were technically richer, formally correct, and still unread.
The consulting team had spent considerable effort translating the entire repository into ArchiMate notation. The models were beautiful. They were also impenetrable to the business stakeholders who needed to use them. The modelling language had improved precision. It had not fixed the governance, decision rights, or stakeholder engagement that made the architecture useful.
That story captures the central point of this module: notation and method solve different problems, and improving one does not automatically fix the other.
If a modelling language improves diagram precision but stakeholders still cannot explain the architecture, has the problem been solved?
This module explains the TOGAF-ArchiMate relationship through the W14C mapping guide, shows where the complementarity is genuinely useful, and identifies where the combination adds no value.
58.1 Two standards, two different jobs
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.
58.2 The W14C concept mappings
W14C (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.
ArchiMate layers and their TOGAF counterparts
- 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). 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 layer (ArchiMate). 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 layer
- TOGAF Gap maps to ArchiMate Gap in the Implementation layer
58.3 Where ArchiMate genuinely helps
- 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 layer 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.
58.4 Where ArchiMate does not help
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.
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.
Common misconception
“ArchiMate replaces the need for TOGAF because it can model the same layers.”
ArchiMate covers the same domain scope through a notation lens, not a process lens. It does not supply the governance system, scope logic, stakeholder management, or migration method that TOGAF provides. A repository full of elegant ArchiMate views can still sit on top of weak architecture practice.
58.5 The selective combination principle
- Use TOGAF to define the enterprise problem, method boundaries, governance points, and artefact expectations.
- Introduce ArchiMate where the team needs more precise, reusable, and analysable models than informal diagrams can provide.
- Model only what earns its keep. Do not translate the whole repository into ArchiMate simply because the notation exists.
- Keep the repository readable by stakeholders who are not fluent in modelling notation. Formal views should strengthen communication, not replace explanation.
- 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.
“The biggest practical risk is that the modelling effort becomes self-referential. If the views exist to satisfy the modelling team rather than to improve a cross-enterprise decision, the effort is not earning its place.”
Course observation - Method versus notation discipline
Selective, purposeful use of ArchiMate is stronger than model-everything enthusiasm. Each formal view should earn its place by improving a real decision, trace, or review.
London Grid Distribution: where ArchiMate would earn its keep
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.
A team adopts ArchiMate and creates detailed cross-layer models of their target architecture. Six months later, stakeholders still cannot explain why the target state was chosen or how it will be governed. What is the most likely cause?
W14C maps TOGAF Data Entity to which ArchiMate elements?
An architecture lead proposes translating the entire London repository into ArchiMate notation. What is the strongest practical objection?
Key takeaways
- TOGAF and ArchiMate complement one another because they solve different problems: method versus modelling language.
- W14C provides the official concept mappings between TOGAF content metamodel elements and ArchiMate layers.
- ArchiMate adds seven layers (Strategy, Business, Application, Technology, Physical, Implementation/Migration, Motivation) with formal notation.
- Good modelling does not rescue weak architecture practice. Notation without method is precision without purpose.
- The selective combination principle: model what earns its keep, not everything the notation supports.
Standards and sources cited in this module
W14C, A Practitioner’s Guide to Using the TOGAF Framework and the ArchiMate Language
Full guide
The official mapping guide between TOGAF and ArchiMate concepts.
Official specification
The current ArchiMate standard defining layers, elements, and relationships.
Official landing page for the TOGAF Standard, 10th Edition
The core enterprise-architecture standard compared in this module.
The TOGAF Standard, 10th Edition (C220)
Parts 0-5
The core standard providing the method, content framework, and governance model.
You now understand why TOGAF and ArchiMate are complementary rather than competing, and how W14C maps their concepts. The next comparison asks a different question: what happens when business-architecture depth has its own body of knowledge? That is Module 59.
Module 58 of 64 · Comparison and Capstone