What is ArchiMate?

When enterprise architects design the blueprint of a system (from business processes to applications and infrastructure) they need a common language. Without it, communication breaks down: diagrams differ, definitions drift, and decisions slow down.

ArchiMate provides that shared language. It offers a visual and conceptual framework to describe how business, data, applications, and technologies interact across the enterprise.

In this guide, we’ll explore what ArchiMate is, how it works, and how to use it effectively: with practical examples, a clear explanation of its structure, and insights on how tools like Boldo make it simpler and more actionable.

What is ArchiMate?

When architects draw blueprints, they use symbols so that everyone can read the plan the same way. ArchiMate does the same for enterprises: it provides a standard set of visual elements that let business and IT teams describe their systems with a shared vocabulary.

Developed by The Open Group, ArchiMate is an open, vendor-neutral modelling language designed to help organisations describe, analyse, and communicate their enterprise architecture with clarity. Its goal is to make the structure of the enterprise understandable for everyone, from executives defining strategy to teams implementing solutions.

By using common shapes and relationships, ArchiMate removes ambiguity and ensures that a process, an application, or a data object is represented consistently across teams. This shared structure improves collaboration, decision-making, and alignment between business intent and technical execution.

In essence, TOGAF defines the method, and ArchiMate provides the symbols, turning enterprise architecture into a language everyone can understand.

A short history of ArchiMate

ArchiMate was born in the early 2000s in the Netherlands, developed by the Telematica Instituut in collaboration with government and industry partners. Its goal was to create a common modelling notation that could unify business and IT views across organisations.

In 2009, The Open Group officially adopted ArchiMate as a standard, ensuring compatibility with TOGAF and promoting its use globally. Since then, the language has evolved through multiple versions (2.0, 2.1, 3.0, 3.1), gaining wide adoption among enterprise architects, consultants, and EA tool providers worldwide.

ArchiMate Logo (colors changed)

The ArchiMate Metamodel: from “Why” to “What”

At the heart of ArchiMate lies its metamodel the structure that defines all the elements and relationships used to describe an enterprise. It’s what makes the language both rigorous and flexible.

ArchiMate covers every aspect of enterprise development: from motivation and strategy to business, applications, technology, and implementation. This holistic approach allows teams to model both the big picture and its operational details in one consistent framework.

However, not every concept is needed at once. In most cases, a small subset of elements covers the majority of needs, a practical application of the 80/20 rule.

The art of using ArchiMate lies in selecting just enough elements to represent your system clearly without over-modelling.

The Core Metamodel provides the essentials: actors, processes, applications, data, and infrastructure.

The Full Metamodel adds strategy and motivation (the why behind every design) as well as implementation elements that capture how change happens.

A good modelling practice follows this simple logic:

• Why: capture the drivers, goals, and requirements that justify change.
• How: define the capabilities and resources that make it possible.
• What: describe the processes, systems, and technologies that deliver it.

ArchiMate Layers

This flow keeps enterprise architecture coherent, connecting intention, design, and execution.

Two perspectives naturally emerge from this approach:

• A Capability-Based View, where transformation is organised around what the organisation must be able to do.
• A Service-Driven View, where value is delivered through business, application, or technology services rather than isolated systems.

Together, these views make ArchiMate a powerful tool for building architectures that are not only well-structured, but purposeful and traceable.

From layers to assets: What each level represents

Each layer of the ArchiMate metamodel corresponds to real enterprise assets: the concrete elements that make up the organisation’s system.
These assets can be visualised, analysed, and connected in tools like Boldo, turning abstract architecture into an actionable map.

Motivation & Strategy layer - Why we act

This is where purpose lives. It defines the intent behind every initiative: what drives change, and which capabilities are needed to deliver it.
Typical assets: goals, drivers, stakeholders, principles, capabilities, resources.
Example: “Enhance customer satisfaction” (goal) -> realised by the “Customer Engagement Capability.”

Strategy & Motivation - Assets (Simplified, non-official representations of The Open Group.)

Business layer - How we create value

This layer models the organisation in action, its people, processes, and services.
Typical assets: business actors, roles, functions, processes, products, business services.
Example: “Order Management Process” performed by the “Sales Department”, delivering the “Order Fulfilment Service.”

Business Layer - Assets (Simplified, non-official representations of The Open Group)

Application layer - What systems support it

Here, we represent the digital enablers of the business: applications, services, and data exchanges.
Typical assets: applications, components, services, data objects, integrations.
Example: “CRM Application” providing the “Customer Profile Service” to the sales process.

Application layer - Assets (Simplified, non-official representations of The Open Group.)

Technology layer - What infrastructure runs it

This layer describes the technical backbone that supports all upper layers.
Typical assets: servers, devices, platforms, networks, middleware, cloud resources.
Example: “Azure Virtual Machine” hosting the “CRM Application Component.”

Technology Layer - Assets (Simplified, non-official representations of The Open Group)

Implementation & Migration layer - How we change

Finally, this layer captures the transformation journey: how the enterprise evolves over time.
Typical assets: projects, work packages, deliverables, transition architectures.
Example: “Customer360 Initiative” composed of three work packages: Data Integration, CRM Upgrade, and Training.

Change Layer - Assets (Simplified, non-official representations of The Open Group)

Composite Elements - How We Structure

The composite elements layer provides context and organises the other parts of the architecture. It allows assets to be grouped or located to better understand their roles and interactions.

It includes:

• Location - represents a physical or logical place where elements operate (e.g. “EMEA” for a data centre).
• Grouping - combines multiple elements into a coherent whole (e.g. “Data Platform” grouping a warehouse, processing engine, and APIs).

These elements give structure to the architecture map and make it easier to read, turning a list of components into a clear, organised view.

Composite Assets (Simplified, non-official representations of The Open Group.)

Understanding ArchiMate Relationships

If the elements are the words of the ArchiMate language, the relationships are its grammar.
They define how business, application, and technology assets connect, forming the logical backbone of any architecture model.

ArchiMate classifies relationships into four main types, each serving a specific purpose in describing how parts of the enterprise interact.

Structural Relationships

These relationships describe how elements are composed or assigned to one another: the “is part of” or “is built by” logic.

• Composition : one element is made up of others.
  Example: A “CRM System” is composed of multiple “Applications” (Salesforce, Mailchimp, etc.).
• Aggregation : a looser version of composition, elements are grouped but can exist independently.
  Example: A “Customer Management Suite” aggregates “CRM” and “Support Portal.”
• Assignment allocates responsibility between an active element (e.g., role, component) and a behaviour.
  Example: The “Sales Department” performs the “Order Processing Process.”
• Realization : indicates that one element implements or fulfills another.
  Example: The “CRM Application Component” realizes the “Customer Data Management Service.”

Structural Relationships (Simplified, non-official representations of The Open Group.)

Dependency Relationships

These represent how one element depends on another to perform its function.

• Serving : an element provides functionality used by another.
  Example: “Authentication Service” serves the “CRM Application.”
• Access : defines how behaviour accesses data or information.
  Example: “Invoice Process” reads “Customer Database.”
• Influence : models how goals, principles, or requirements impact other elements.
  Example: “Sustainability Principle” influences the “Cloud Provider Selection Requirement.”

Dependency Relationships (Simplified, non-official representations of The Open Group.)

Dynamic Relationships

These capture flows and triggers: the cause-and-effect logic of the enterprise.

• Triggering : one process or event initiates another.
  Example: “Order Received Event” triggers “Order Fulfilment Process.”
• Flow : represents the transfer of data, information, or value between elements.
  Example: “CRM Application” sends customer data to the “Marketing Platform.”

Dynamic Relationships (Simplified, non-official representations of The Open Group.)

Other Relationships

These provide structural flexibility and semantic precision within models.

• Specialization : indicates a more specific version of another element.
  Example: “Online Payment Service” specializes “Payment Service.”
• Association : a generic link between elements that don’t fit other categories.
  Example: “Employee” is associated with “Laptop.”
• Junction : merges or splits relationships to model complex logic.
  Example: Two “Events” can converge on one “Process” using an AND junction.

Other Relationships (Simplified, non-official representations of The Open Group.)

The Boldo Metamodel: when flexibility meets standards

Every organisation has a different level of maturity when it comes to enterprise architecture. Some start with simple tools, while others already manage complex environments. To adapt to this diversity, Boldo’s metamodel is designed to evolve with your organisation. Its modular structure allows you to start by modelling applications, processes, and data, then progressively add more advanced concepts such as capabilities, services, or transformation projects.

Boldo is also preparing the launch of a native ArchiMate-based metamodel, aligned with The Open Group standard. It will provide full interoperability, semantic rigour, and immediate readability for teams already familiar with ArchiMate.

In practice, two complementary approaches will be available: an adaptive, fast, and collaborative model for building initial architecture maps, and a structured ArchiMate model for organisations requiring standardisation and governance. The two can be combined, evolving the architecture model as the organisation’s maturity grows.

This dual approach reflects Boldo’s philosophy: making enterprise architecture both accessible and rigorous, so every team can share the same vision at the right level of detail.

Conclusion

Enterprise Architecture is both a science and an art: connecting strategy, systems, and people.
ArchiMate gives architects a precise language to represent this complexity, turning abstract ideas into structured models.
Boldo brings that language to life.

FAQ