TOGAF with ArchiMate

50 min read 6 outcomes 1 interactive diagram 4 standards cited

TOGAF and ArchiMate are complementary Open Group standards that solve different problems: one is a method, the other a modelling language, and neither replaces the other. The W14C guide sets out the full set of concept mappings between them, showing exactly where the two standards meet and where they remain distinct.

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
Structured built environment image used here to suggest architecture method and modelling language being related but not identical responsibilities

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?

The TOGAF-ArchiMate relationship runs through the W14C mapping guide, which is most useful where the complementarity earns its place and least useful where the combination adds nothing.

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

TOGAF and ArchiMate complement each other; each owns what the other does not

TOGAF the method and ArchiMate the notation each own distinct work, then converge on the joint artefacts where the models are drawn.

TOGAF is the method. ArchiMate is the notation. Each owns work the other does not, and the map names where they meet so the joint artefacts are explicit.

TOGAF and ArchiMate complement each other; each owns what the other does not A convergence map with three columns. The left column, TOGAF owns the method, holds three blue panels: ADM phases, Content metamodel and Governance. The right column, ArchiMate owns the notation, holds three blue panels: Layers, Relationships and Viewpoints. Arrows point inward from both owners to the centre column, Both own the joint artefacts, three red panels: the business, application and technology models, each drawn in ArchiMate notation on the TOGAF metamodel. A closing note in red states the method decides what each model must contain and the notation decides how it is drawn, so the two are used together. TOGAF owns: the methodBoth own: the joint artefactsArchiMate owns: the notationSequence, structure, controlSymbols, layers, views ADM phasesThe sequence of work Content metamodelWhat an artefact is GovernanceBoard, principles, waivers Business modelArchiMate on TOGAF metamodel Application modelArchiMate on TOGAF metamodel Technology modelArchiMate on TOGAF metamodel LayersBusiness, app, technology RelationshipsComposition, realisation ViewpointsStakeholder views The joint artefacts are where they meet.The method decides what each model must contain; the notation decides how it is drawn. Use them together, not inplace of one another.
Loading interactive component...

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.

ArchiMate fit on two axes: model complexity and audience expertise

The grid maps the two choices that decide the notation. Each quadrant names the fit verdict for one combination, with what to reach for and what to watch.

ArchiMate is precise but unfamiliar to non-architects. The matrix names when full notation fits, when a legend rescues it, and when box-and-line is the better tool.

ArchiMate fit on two axes: model complexity and audience expertise A two-by-two matrix of ArchiMate fit on two blue axis rails: a vertical Model complexity rail, simple to complex, and a horizontal Audience expertise rail, mixed to expert. Each quadrant names a verdict, with a green marker for what to reach for and an amber marker for what to watch. Simple plus mixed: drop the notation, box-and-line is enough but loses formal element types. Simple plus expert: full ArchiMate on a tight subset, watching for over-modelling. Complex plus mixed: full notation with a legend on every figure, or readers stall without the key. Complex plus expert, marked in red, is the home ground full ArchiMate was built for; the trade across the grid is precision against reach. Model complexity: simple to complex Audience expertise: mixed to expert Complex model, mixed audience Full plus a legend A legend on every figure Readers stall without the key Complex model, expert audience Full ArchiMate The home ground for the notation Still needs disciplined layering Simple model, mixed audience Drop the notation Box-and-line is enough to land it Loses formal element types Simple model, expert audience Full, tight subset Notation with a limited vocabulary Over-modelling a small picture What to reach forWhat to watch Complex and expert is the home ground.It is the only quadrant where full ArchiMate earns its precision; every other cell trades vocabulary forreach.

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

  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.

“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.

TOGAF method and ArchiMate notation working together as complementary Open Group standards solving different architecture problems
TOGAF provides the method and governance. ArchiMate provides the notation. Both are Open Group standards, but they solve different problems.
Check your understanding

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

  1. 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.

  2. ArchiMate 3.2 Specification

    Official specification

    The current ArchiMate standard defining layers, elements, and relationships.

  3. TOGAF overview

    Official landing page for the TOGAF Standard, 10th Edition

    The core enterprise-architecture standard compared in this module.

  4. The TOGAF Standard, 10th Edition (C220)

    Parts 0-5

    The core standard providing the method, content framework, and governance model.

Previous: London governance repository and assurance modelNext: TOGAF with BIZBOK

Module 58 of 64 · Comparison and Capstone