Archimate - From Motivation to Migration

ArchiMate is a shared visual-and-text language for enterprise architecture. It sits at the “coherence” level, giving an overview that links the pieces together. Team work through views and viewpoints, and a viewpoint is defined by its stakeholders, purpose, content and representation. The language has four domains: Motivation (why), Strategy (direction and capabilities), Core (Business, Application and Technology layers), and Implementation and Migration (the plan). Elements are active structures, behaviors (service, process, function), or passive structures. The main relationships are composition, assignment, realization, flow, triggering, serving, and access. Each core layer has a different job:

·        Business covers what the organization does and the value it delivers. It is usually modeled first and is read by executives and process owners.

·        Application covers the software that supports those processes. It is read by solution architects and developers.

·        Technology covers the platforms the software runs on. It is read by infrastructure and security teams.

Projects often run from Business through Application to Technology, but they iterate, and some start from Technology.

ArchiMate 3.2 describes an enterprise in six connected domains. Motivation says why, Strategy says where the organization is heading, Business, Application and Technology describe the solution in three layers, and Implementation and Migration plan how to get there. One shared set of relationships ties them together, so a requirement can be traced from a stakeholder's concern down to a server. For each domain, this article gives its agenda, its usual owner, and how it links to the other domains.

The framework at a glance

The top five domains read from why to run, with Implementation and migration alongside them as the plan for getting there.

Agenda, ownership and audience by layer

Each domain has an agenda, meaning the decisions its work has to settle, a typical owner who is accountable for its content, and an audience that reads its views

Domain	Agenda: what the layer settles	Typically owned by (inferred)	Audience (inferred)
Motivation	Who cares and why: concerns, drivers, goals, principles, requirements and constraints, so every later choice has a stated reason	Executive sponsors and business leadership own goals and drivers; the enterprise architect keeps the traceability	Executives, stakeholders, enterprise and business architects
Strategy	Where to invest: which capabilities to build, improve or retire, which value streams matter most, which course of action to fund	Executive team and strategy office; business architects keep the capability map	Executives, senior management, enterprise architects
Business	How value is delivered: processes, services, roles and products, and the organization that runs them	Business unit leaders and process owners; business architects model it	Process owners, business analysts, product owners
Application	Which software delivers each business service, how applications interface, where data lives, and build, buy or reuse	Application owners, with solution architects and development teams	Solution and application architects, developers, application owners
Technology, with physical elements	Where applications run and how they are connected, secured and operated	Infrastructure, cloud and platform teams, with security and technology architects	Infrastructure, cloud and network engineers, operations, security
Implementation and migration	The path from today to the target: plateaus, gaps, work packages, deliverables and their order	Program and project managers, with architects governing the roadmap	Program and project managers, architects, delivery teams

Motivation Domain: why we are doing this

Motivation records the reasons behind a design, so a requirement can be traced back through goals and drivers to the stakeholder whose concern started it

Element	What it represents
Stakeholder	A person, team or organization, or a class of them, with an interest in the effects of the architecture
Driver	A condition, inside or outside the organization, that pushes it to set goals and make changes
Assessment	The result of analyzing how things stand with respect to a driver
Goal	A high-level statement of intent, direction or desired end state
Outcome	An end result or effect of some state of affairs
Principle	A general rule that applies to any system in a given context
Requirement	A statement of need for a specific system as described by the architecture
Constraint	A limit on the architecture, on how it is implemented, or on how it is realized
Meaning	The knowledge or interpretation attached to a concept in a particular context
Value	The relative worth, utility or importance of a concept

•    Agenda: Agree who cares, what drives them, what they want, and what rules limit you, before you draw any solution.

• Owned by: Executive sponsors own the drivers and goals. Business and product owners own the requirements. The architect keeps the trace between them.
• Connects to Strategy: Goals say what is wanted, and a course of action is the chosen way to get there. Every strategic choice should trace back to a goal. Capabilities and courses of action can also satisfy or influence requirements directly.
• Connects to the core layers: A requirement is satisfied by something real, such as a process, application, or server. You can follow it down to that element. Goals and principles are met indirectly, through requirements.
• Use it to: Justify decisions. Show which driver and goal sit behind a requirement, and which principles and constraints shape the answer.

Strategy Domain: direction and capability

Strategy models how the organization intends to create value and which abilities it needs for that. It sits between the reasons in Motivation and the detailed design in the core layers

Element	What it represents
Resource	An asset owned or controlled by an individual or an organization
Capability	An ability that an organization, person, or system possesses
Value Stream	A sequence of activities that creates an overall result for a customer, stakeholder, or end user
Course of Action	An approach or plan for configuring capabilities and resources to achieve a goal

• Agenda: Decide where to invest. Choose which capabilities to build, improve, or retire, which value streams matter most, and which course of action to fund.
• Owned by: The executive team and strategy office own direction. Business architects keep the capability map up to date.
• Connects up to Motivation: A course of action is picked to reach a goal, and capabilities and resources are the means. They can also satisfy or influence requirements. Checking how ready a capability is counts as an assessment.
• Connects down to Business: Business processes, functions, and services deliver capabilities and value streams. Resources are backed by actors, applications or servers. So each capability maps to the processes and teams behind it, and the same rule reaches the Application and Technology layers.
• Use it to: Show which capabilities a new strategy depends on and which it affects. A capability map is the usual picture for executives.

The core: Business, Application and Technology layers

The three core layers share one element pattern: something that acts, the behavior it performs, and what it acts on.

Role in the pattern	Business	Application	Technology
Does the work (active structure)	Business Actor, Business Role	Application Component	Node, Device, System Software
Several do it together	Business Collaboration	Application Collaboration	Technology Collaboration
Where a service is reached	Business Interface	Application Interface	Technology Interface
Behavior grouped by criteria	Business Function	Application Function	Technology Function
Behavior in sequence toward a result	Business Process	Application Process	Technology Process
Joint behavior of a collaboration	Business Interaction	Application Interaction	Technology Interaction
A state change	Business Event	Application Event	Technology Event
Behavior exposed to others	Business Service	Application Service	Technology Service
What is acted upon (passive structure)	Business Object, Contract, Representation	Data Object	Artifact
Extras that belong to one layer	Product	None	Path, Communication Network, and the physical elements:   Equipment, Facility, Distribution Network, Material

Business layer: what the organization does

• Agenda: Define how value is delivered: who does what, in which order, through which services and products.
• What is distinct: An actor is who performs. A role is the responsibility they take on. A contract is the agreement, and a product bundles services for customers.
• Why needed: It keeps IT work tied to business value.
• Owned by: Business unit leaders and process owners are accountable. Business architects and analysts model it.
• Connects to: Upward, its processes and services deliver Strategy’s capabilities and satisfy Motivation’s requirements. Downward, application services support its processes and data objects hold its business information. Links from Business to Technology go through the Application layer.
• Use it to: Show end-to-end workflows, who runs them, and which services reach customers. It gives business and IT common ground.

Application layer: the software

• Agenda: Decide which software delivers each business service, how applications exchange data, where data lives, and whether to build, buy, or reuse.
• What is distinct: A component is a replaceable block of functionality. A data object is structured data. An interface is where a service is offered.
• Why needed: It shows which software supports which process, so the business connects to the infrastructure.
• Owned by: Application owners are accountable. Solution architects and dev teams design, build, and run it.
• Connects to: Upward, application services serve business processes and data objects represent business objects. Downward, technology services serve the applications and artifacts realize them. A node runs an application indirectly, through the artifact deployed on it.
• Use it to: Map applications to business needs, show interfaces and data flows, and spot gaps and overlaps.

Technology layer and physical elements: software runs on

• Agenda: Decide where applications run and how they are connected, secured, and operated.
• What is distinct: A node is something that hosts or runs things. A device is the physical machine. System software is the environment software runs in. A network connects them, and an artifact is a file or deployable piece.
• Physical elements: Equipment, facilities, distribution networks, and materials. Use them when the model includes factories, logistics, or sensors.
• Why needed: Hosting, capacity, resilience, and security decisions live here.
• Owned by: Infrastructure, cloud, and platform teams run it. Security teams and technology architects set standards.
• Connects to: Upward, technology services serve application behavior, and artifacts realize components and data objects. Nothing sits below it, but the physical elements extend it outward.
• Use it to: Map hosting and networks, and see which applications depend on which servers. A data-flow view for the security lead is a typical example.

Implementation and migration, and composite elements

Implementation and migration models how the organization gets from its current architecture to the target one

Element	What it represents
Plateau	A relatively stable state of the architecture that exists for a limited period
Gap	A statement of the difference between two plateaus
Work Package	A series of actions designed to achieve specific results within time and resource limits
Deliverable	A precisely defined result of a work package
Implementation Event	A state change related to implementation or migration

• Agenda: Decide the path from today to the target: which stages, in which order, which gaps each closes, and which work delivers it.
• Why needed: Without it, the target is only a picture. This domain ties the design to time, work, and deliverables.
• Owned by: Program and project managers own delivery. Architects govern the roadmap so every step stays consistent with the target.
• Connects to: It cuts across every layer. A deliverable can create or change an element in any layer, or satisfy a requirement directly. A plateau is a snapshot of the architecture at one point in time. A gap is what differs between two plateaus. Motivation can record why a change is on the roadmap.
• Use it to: Plan the roadmap. Describe today and the target as plateaus, record the gaps between them, and attach the work packages and deliverables that close each gap.

How the layers connect:

Each domain hands something to the next, and the relationships from the previous section carry it

The table covers every pair from a concern down to a server, or from a server back up to the reason it exists. The metamodel limits which relationships are allowed between which element types.

Between	Direct link?	How they connect	Question it answers
Motivation and Strategy	Yes	A Course of Action is the approach chosen to achieve a goal. Capabilities, value streams, courses of action and resources can realize or influence requirements, and a course of action can realize or influence an outcome. Influence links also run between motivation elements.	Which strategic choice serves which goal or requirement?
Motivation and Business, Application, Technology	Yes	A requirement is realized directly by structure and behavior elements in any core layer. Goals, principles and outcomes are realized indirectly, through requirements. Meaning and Value can be associated with any structure or behavior element.	What satisfies this requirement?
Strategy and Business	Yes	Capabilities and value streams are realized by business processes, functions and services. Resources are realized by business actors and other structure elements.	Which processes and teams deliver this capability?
Strategy and Application, Technology	Yes, same rule	Application or technology behavior can realize a capability or value stream, and application components or nodes can realize a resource.	Which systems or platforms does this capability depend on?
Business and Application	Yes	Serving: application services serve business processes, and business services can also serve application behavior. Realization: application behavior can realize business behavior, and data objects realize business objects.	Which software supports this process, and where is this business data held?
Application and Technology	Yes	Serving: technology services serve application behavior, and technology interfaces serve components. Realization: artifacts realize application components and data objects. An artifact deployed on a node realizes the component, so the node indirectly runs it.	What does this application run on?
Business and Technology	Indirect	A technology object can realize a business object directly, as a physical representation. Other links are derived through the Application layer, for example a node that serves a component that serves a process.	Which servers or devices does this process depend on?
Implementation and migration and the core layers	Yes	A deliverable realizes an element in any core layer. A plateau aggregates or composes the elements that exist at one point in time, a gap is associated with the elements that differ between two plateaus, and a business role can be assigned to a work package.	What changes, and in which step?
Implementation and migration and Motivation	Yes	A deliverable can realize a requirement directly, and a plateau can include goals, outcomes and requirements.	Which release delivers this requirement?
Implementation and migration and Strategy	Yes	A plateau can realize part of the architecture, such as a capability increment. Other links use the standard relationships.	When is each capability increment delivered?

Where conceptual, logical and physical models fit

TOGAF draws a similar line when its content metamodel separates logical from physical application and technology components, with the physical component realizing the logical one. The placement below is my reading of how that maps onto the ArchiMate domains, so treat it as a working convention.

Motivation, Strategy, and Business are conceptual by nature. The Application layer is the usual home of the logical model. The Technology layer is the physical model. Conceptual and logical models line up with Architecture Building Blocks and physical models with Solution Building Blocks.

Level	Where it sits	Typical ArchiMate elements	TOGAF counterpart (inferred)
Conceptual	Motivation, Strategy and the Business layer. Answers what the enterprise wants and does, with no product or technology named.	Goals, requirements, capabilities, value streams, business actors, processes, services and objects	Architecture Vision and Business Architecture content; Architecture Building Blocks at the business level
Logical	The Application layer, plus technology services and standards. Answers which systems and data the design needs, without naming vendors.	Application components, interfaces, services and data objects; technology services	Logical application and technology components; Architecture Building Blocks
Physical	The Technology layer and physical elements, plus named product versions. Answers which products run where.	Nodes, devices, system software, artifacts, communication networks, equipment, facilities	Physical application and technology components; Solution Building Blocks

What to build at each project stage

The matrix (from inception to deployment) shows where modeling effort sits: it starts in Motivation and Strategy and moves down the layers as the project advances. 

Lead means the main modeling effort at that stage, Support means the layer is refined alongside, and a blank means little or none.

Stage	What to build	Typical viewpoints (inferred)	Who is involved
Inception: should we do this, and why?	Lead: Motivation (stakeholders, drivers, goals, principles, first constraints) and Strategy (capabilities in scope, candidate courses of action). Support: an outline of the affected business processes.	Stakeholder, Motivation, Goal Realization, Capability Map	Sponsors, executives, enterprise architect
Discovery: what exists today, and what must change?	Lead: Strategy (capability assessment) and Business (baseline processes, services and actors). Support: Motivation (assessments, requirements, constraints), a coarse Application and Technology inventory, and the first gaps.	Capability Map with assessments, Business Process Cooperation, Application Cooperation, Technology	Business analysts, process and application owners, infrastructure teams
Design: what should the target look like?	Lead: Business (to-be processes and services), Application (target applications and interfaces) and Implementation and migration (plateaus, gaps, options compared). Support: Motivation (requirements realized by design elements), Strategy (does the course of action still hold) and Technology (hosting options).	Layered, Application Usage, Technology Usage, Requirements Realization, Migration	Business, solution and technology architects
Build: how do we deliver it?	Lead: Application and Technology (detailed design handed to UML, BPMN or infrastructure automation, with ArchiMate as the overview) and Implementation and migration (work packages and deliverables). Support: Business (process and role changes in flight).	Implementation and Deployment, Project	Development teams, engineers, project managers
Deploy: how do we move to the target safely?	Lead: Technology (cutover and retiring old elements) and Implementation and migration (the migration path across plateaus, implementation events). Support: Application (release) and Business (readiness of people and processes). Update the model to match what was actually delivered.	Migration, Implementation and Migration	Programme managers, operations, release and security teams

TOGAF ADM, Architecture Building Blocks and Solution Building Blocks:

TOGAF's Architecture Development Method (ADM) is a cycle of phases that takes an architecture from vision to delivery and back again. ArchiMate supplies the modeling language for the content of those phases, and TOGAF supplies the process around it.

ADM phase	What it settles	ArchiMate domains it leans on (inferred)
Preliminary	Architecture capability, principles and governance	Motivation: principles and drivers
A. Architecture Vision	Scope, stakeholders and a high-level target	Motivation and Strategy, with rough sketches of the other layers
B. Business Architecture	The business baseline and target	Business layer, tied to Strategy capabilities and value streams
C. Information Systems Architectures	The data and application baseline and target	Application layer: data objects, components, services
D. Technology Architecture	The platforms the systems run on	Technology layer and physical elements
E. Opportunities and Solutions	Which solutions and work packages deliver the target	Implementation and migration, plus the products chosen in Application and Technology
F. Migration Planning	The order of the work and the transition states	Implementation and migration: plateaus, work packages, gaps
G. Implementation Governance	Oversight of delivery against the architecture	Implementation and migration: deliverables, checked against Motivation requirements
H. Architecture Change Management	Which changes to accept and when to start a new cycle	Motivation: new drivers and assessments, then any layer that changes
Requirements Management	Requirements kept current across every phase	Motivation: requirements

•     Architecture Building Block (ABB): It describes a requirement without naming any product. ABBs come from the architecture side of TOGAF and are mostly defined in phases A to D.

•     Solution Building Block (SBB): It is a real product; SBBs come from the solutions side of TOGAF. 

•     How they pair: So the pairing can be one-to-one, one-to-many or many-to-one.

•     In ArchiMate: ABBs are the high-level elements such as capabilities, business services, application components and services, and technology services. SBBs are the concrete ones.

        TOGAF does not label each artifact as an ABB or an SBB.

ADM phase	ABB side: what is required	SBB side: what is chosen and built
Preliminary and A	Principles Catalog, Stakeholder Map Matrix, Value Chain Diagram, Solution Concept Diagram	None yet
B. Business	Organization/Actor, Driver/Goal/Objective and Role Catalogs; Business Interaction and Actor/Role Matrices; Business Footprint and Functional Decomposition Diagrams	Rare at this layer
C. Data	Data Entity/Data Component Catalog (logical entities); Data Entity/Business Function Matrix; Conceptual Data and Logical Data Diagrams	Catalog rows for physical data stores; Data Migration Diagram
C. Application	Application Portfolio Catalog (logical components); Interface Catalog; Application/Organization, Role/Application, Application/Function and Application Interaction Matrices; Application Communication and Process/Application Realization Diagrams	Catalog entries naming products and versions; Application and User Location, Software Distribution, Software Engineering and Application Migration Diagrams
D. Technology	Technology Standards Catalog; Platform Decomposition Diagram	Technology Portfolio Catalog; Application/Technology Matrix; Environments and Locations, Networked Computing/Hardware, Network and Communications and Processing Diagrams
E, F and G	Architecture Requirements Specification, used to check that solutions meet the ABBs	Architecture Roadmap, Transition Architectures, Implementation and Migration Plan, Project Context and Benefits Diagrams, Architecture Contract
H. Change Management	Revised ABBs when requirements change	Replaced or upgraded SBBs

Advantages and disadvantages of ArchiMate:

ArchiMate's main strength is a shared language across business and IT, and its main limit is that it gives an overview, not detailed design.

Advantages

•     One common language across business, application and technology, so business leaders, IT teams and developers read the same picture.

•     An end-to-end view of a complex system that can be visualized, analyzed and communicated.

•     Viewpoints filter the model to one stakeholder's concern, so each audience sees only what it needs.

•     Visible dependencies between layers, which supports impact analysis when something changes.

•     An open standard from The Open Group, so people, training and tools are easy to find, and it links to UML and BPMN for detail.

•     In a modeling tool, the model can be queried and analyzed, not just drawn.

Disadvantages

•     It is not a silver bullet: detailed design still needs UML, BPMN or similar.

•     Diagrams overload easily. The ArchiMate 101 book suggests about 20 elements, 40 at most.

•     The notation and relationship rules take learning, so non-architects need simplified views and a legend (inferred).

•     Models need a tool and ongoing upkeep, or they go stale and lose value (inferred).

•     Skipping stakeholder feedback means the model misses real concerns.

•     Colors carry no formal meaning, so conventions vary between teams.

•     The notation can become the goal, when it is only a means to better decisions.

References: 

• https://www.opengroup.org/sites/default/files/docs/downloads/n221p.pdf
• https://togaf.visual-paradigm.com/2025/02/18/comprehensive-guide-to-getting-started-with-archimate-concepts-examples-and-best-practices/
• https://www.visual-paradigm.com/tutorials/how-to-draw-archimate-diagram.jsp
•