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
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.
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.”
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.”
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.
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.”
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.
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.
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.
Dependency Relationships
These represent how one element depends on another to perform its function.
Dynamic Relationships
These capture flows and triggers: the cause-and-effect logic of the enterprise.
Other Relationships
These provide structural flexibility and semantic precision within models.
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.