ArchiMate for Beginners: Layers, Elements and Relationships Explained

ArchiMate has a reputation for being simultaneously too simple and too complicated — simple enough that a manager can nod along to a landscape diagram in five minutes, complicated enough that two architects can argue for twenty about whether a login screen is an Application Component or an Application Interface. Both reactions are correct, and understanding why is most of what it takes to use the language well. This is a primer on the actual mechanics: the three core layers, the element types that live in each one, and the ten relationship types that do the real work of saying how anything connects to anything else.

What ArchiMate Actually Is

ArchiMate is an open modelling standard maintained by The Open Group, the same industry consortium behind TOGAF. First published in 2009 and now in its third major revision, it defines a fixed vocabulary of element types and relationship types for describing an enterprise's architecture — not a methodology for how to run an architecture practice, and not a specific tool. TOGAF tells you how to run the process of doing architecture; ArchiMate gives you the nouns and verbs to describe what you find. The two are commonly used together, but neither requires the other, and plenty of organizations use ArchiMate's notation without touching TOGAF's Architecture Development Method at all.

The problem ArchiMate solves is one that anyone who has maintained architecture diagrams by hand will recognize: free-form boxes and arrows let every diagram invent its own meaning for a line. One diagram's arrow means "calls," another's means "owns," a third's means "reports to," and nothing distinguishes them except a legend that may or may not be up to date. ArchiMate fixes the vocabulary. A composition relationship means the same thing whether it connects two business processes or two pieces of hardware. That consistency is the entire value proposition — it's what lets a business architect, an application architect, and an infrastructure architect draw from the same language instead of three dialects that happen to share some clip art.

The Layer Model

ArchiMate organizes everything into layers, and the layering is not decorative — it's the main structuring idea of the whole language. Each layer describes a different kind of thing, at a different level of abstraction, and the layers stack in an order that mirrors how most organizations actually work: the business layer describes what the organization does and delivers, independent of any particular software; the application layer describes the software that supports that; and the technology layer describes the infrastructure the software runs on. A well-formed model lets you start at any layer and trace both up and down — from a server, up through the application it hosts, up through the business process that application supports, up to the business service delivered to a customer.

Three extension layers sit around this core, and most beginners can safely ignore them at first. The motivation layer captures the why — stakeholders, drivers, goals, and requirements — and is most useful when a model needs to justify itself to people who don't care about the technology. The strategy layer captures capabilities, resources, and courses of action, and tends to matter more in portfolio and investment conversations than in day-to-day system design. The implementation and migration layer describes change itself — work packages, plateaus, and gaps between an as-is and to-be state — and shows up mainly in transformation roadmaps. There's also a small set of physical elements — facility, equipment, material, distribution network — that were folded into the technology layer in ArchiMate 3.0, relevant mainly to organizations with real physical assets: utilities, logistics, manufacturing. None of these extensions change how the three core layers work; they just give you vocabulary for questions the core layers weren't designed to answer.

The Business Layer

The business layer describes the organization as seen by its customers and stakeholders, with no reference to systems or software. Get this layer right and it should still make sense to someone who has never seen an IT diagram in their life.

• Business Actor — an organizational entity capable of performing behavior: a person, a department, a whole organization.
• Business Role — the responsibility assigned to an actor for a specific piece of behavior. The same actor can hold several roles; the same role can be filled by different actors over time.
• Business Process — a sequence of behaviors that produces a defined outcome, such as "handle a permit application."
• Business Function — a grouping of behavior organized around required skills and resources rather than a specific outcome; more stable over time than a process, because reorganizing how work flows doesn't necessarily change what capability performs it.
• Business Service — an explicitly defined unit of value that a process or function makes available to the outside world. This is the element most often confused with a process — more on that below.
• Business Object — a passive piece of information handled by business behavior, described at the business level: "permit application," not "row in a database."
• Business Event, Business Interaction, and Business Interface round out the layer, covering triggers, collaborative behavior between roles, and the point of access to a service.

The Application Layer

The application layer describes the software that supports the business — the layer where most enterprise architects who came up through IT feel most at home.

• Application Component — a modular, deployable, largely self-contained part of a software system. This is the closest ArchiMate element to what most people mean, informally, by "a system": a portal, an API, a batch service.
• Application Service — exposed functionality that a component, or a collaboration of components, makes available, consumed by a business process or by another application. Same pattern as the business layer: the service is the externally visible contract, not the component behind it.
• Application Interface — the specific point where an application service is made accessible, such as a particular API endpoint.
• Data Object — structured data manipulated by application behavior. It's the application-layer counterpart to a business object, and the two are frequently connected: a "permit application" business object realized, at the application layer, by a specific data object with an actual schema.
• Application Function, Application Process, and Application Collaboration mirror their business-layer equivalents, describing internal application behavior, sequenced behavior, and cooperation between components.

The Technology Layer

The technology layer describes the infrastructure everything above it runs on.

• Node — a computational resource that hosts or runs other elements: a server, a container, a virtual machine. Deliberately abstract, so it covers both a physical box and a cloud abstraction of one.
• Device — a physical piece of hardware with processing capability; a specialization of Node for when the physical distinction actually matters to the model.
• System Software — the environment an application component runs inside: an operating system, a database engine, a container runtime.
• Technology Service — exposed infrastructure functionality, such as a hosting service or a messaging service, consumed by application components the same way an application service is consumed by a business process.
• Artifact — a physical or digital piece of data produced or used in development and deployment: a deployable package, a configuration file, a container image.
• Technology Interface, Network (sometimes called Communication Network), and Path cover access points and the connections between nodes.

The pattern repeats at every layer, and it's worth naming explicitly because it's the single most useful thing to internalize about ArchiMate: each layer has an active structural element that does the work (Business Actor, Application Component, Node), a behavior element describing what it does (Business Process, Application Function, Technology Process), a service that exposes that behavior to whatever sits above it (Business Service, Application Service, Technology Service), and a passive element the behavior operates on (Business Object, Data Object, Artifact). Learn that four-part pattern once and most of the element list stops needing to be memorized — it can be derived.

How the Layers Connect

The service pattern isn't just a naming convention — it's the mechanism that keeps the layers from turning into a tangle. The recommended way for one layer to depend on the one below it is through a service, using the serving relationship, not through a direct reference to whatever happens to implement that service. A business process is served by an application service; it doesn't need to know, or model, which application component provides it, still less which node that component runs on. That indirection is exactly what makes the model resilient to change: swap the application component behind a service — replace an old permit system with a new one — and the business process, and everything modelled above it, is untouched, because nothing above the service boundary ever referenced the component directly.

This is also where realization does its job. While serving connects a service to whatever consumes it, realization connects a service down to whatever produces it: an application component realizes an application service, a business process realizes a business service. The two relationships together describe a complete, honest chain — process realizes service, service serves the layer above — without ever collapsing the distinction between "what a service is" and "what actually happens to provide it." Skip that distinction, and diagrams start drawing business processes with arrows straight into servers, which is where most of the value of layering quietly leaks away.

Relationships: The Real Grammar

Elements get most of the attention because they're the boxes, but the relationships are where ArchiMate actually does its job. The standard defines a small, fixed set of them, deliberately — the constraint is the point. A free-text label on an arrow can mean anything the author intended and nothing to anyone else; a realization relationship means the same specific thing everywhere it appears, in anyone's model. Ten relationship types cover essentially everything, and they fall into a few natural groups.

The pair that trips up almost everyone new to the language is composition versus aggregation, and the distinction is worth sitting with because it changes what a diagram is actually claiming. Composition says the part has no independent existence: a business process composed of sub-processes means those sub-processes only make sense as pieces of that specific process. Aggregation says something weaker: a business actor aggregating the business roles it performs doesn't claim those roles belong exclusively to that actor — the same "approver" role might be filled by a different person next quarter, and the role itself is a meaningful, independently defined thing whether or not this particular actor currently holds it.

A Worked Example: Permit Management

Take a small, realistic slice: a municipality's online permit portal. At the business layer, a Business Process — "Handle Permit Application" — realizes a Business Service, "Permit Handling," which is what the citizen actually experiences: submit a form, get a decision. At the application layer, that business service is served by an Application Service, "Permit API," which is realized by an Application Component that actually implements it. The component reads and writes a Data Object representing the application record, stored in a database. At the technology layer, that component and database are assigned to a Node — a specific hosting environment — which is where the model finally touches real infrastructure.

Most people don't start there, though. Sketched on the canvas under the generic profile, that same slice is three boxes and two connections: a Portal, a PermitAPI, and a PermitDB, with an HTTPS call from the portal to the API and a database connection from the API to its store. For a great many conversations that sketch is already enough — it answers "what talks to what" without asking anyone in the room to learn a vocabulary first, which is often the difference between a model that gets drawn and one that gets postponed.

Nothing about that sketch is throwaway. Where the ArchiMate profile earns its keep is on the layers the sketch doesn't yet show: reclassify PermitAPI as an Application Component and it can carry a proper Application Service and Application Interface underneath it; connect it up to a Business Process and a Node, and the same objects that supported the quick landscape sketch now support a formal ArchiMate view, an impact-analysis query, or a rules check — without redrawing anything, because it's the same underlying model, not a separate diagram someone has to keep in sync by hand.

That progression matters more than it sounds, because the usual alternative to it is a rewrite. In most toolchains the informal sketch and the formal ArchiMate model are separate artifacts, frequently in separate products, and the sketch gets abandoned the moment the formal version exists. Which is how organizations end up with a complete, carefully typed, eighteen-month-old ArchiMate model that nobody opens, alongside a whiteboard photo in a chat thread that everybody actually uses. Being able to start loose and tighten in place, on the same objects, is what stops those two from drifting into a model that's correct and a picture that's current.

Where Beginners Actually Get Stuck

Most of the friction with ArchiMate isn't the notation — it's a handful of recurring judgment calls that the standard leaves to the modeller, on purpose, because they genuinely depend on context.

Service or process?

A business service is what's delivered to the outside world; a business process is how it gets produced internally. "Permit Handling" is a service — a citizen doesn't experience your internal workflow, they experience the outcome. "Handle Permit Application" is the process behind it, and it can change completely — different steps, different staff, an outsourced vendor — without the service changing at all, provided the outcome stays the same. Beginners routinely model only the process and skip the service, which works fine right up until someone needs to talk about the system from the outside — a service catalog, an SLA, a customer-facing capability map — and there's no element in the model built for that conversation.

Association as an escape hatch

Every one of the other nine relationship types has a precise meaning, which occasionally makes them inconvenient — it's genuinely faster to draw an association than to stop and work out whether a connection is really serving, or triggering, or access. Used sparingly, association is fine; it exists for exactly the case where nothing more specific applies. Used as a default, it quietly turns the model back into free-form boxes and arrows, just with ArchiMate icons on it. If more than a small fraction of a model's relationships are associations, that's usually a sign the modeller hasn't yet decided what the connections actually mean.

Skipping layers

It's tempting, especially under time pressure, to draw a straight line from a business process to a database, or from a business actor to a server, because everyone in the room knows what's meant. The cost shows up later: an impact analysis that follows relationships mechanically will miss the connection entirely if it isn't there, or it'll follow a shortcut that skips the application layer's actual accountability for that data. The service-serving-realization chain is more typing up front and considerably more honest — and considerably more useful to whoever has to run an impact query against the model six months later, possibly without the context the original modeller had in their head.

Modelling everything at once

ArchiMate's full element list is long enough to be intimidating, and a new modeller who tries to use all of it from day one usually produces a model that's exhaustive and unreadable in roughly equal measure. The layer, service, and four-part structural pattern described above cover the large majority of real modelling needs. Motivation and strategy elements earn their place when a specific audience needs them — a business case, a transformation roadmap — not as a default addition to every model regardless of who's going to read it.

Starting Small, on Purpose

The practical advice that follows from all of this is unglamorous but reliable: start with the three core layers and the four-part pattern — actor/component/node, process/function, service, object — and resist adding motivation or strategy elements until a specific question actually needs them. Model services deliberately, even when it feels like extra work compared to connecting two components directly, because the service is the seam that lets one side of the model change without the other side noticing. And be precise about relationships even when it's slower: the time spent deciding whether something is composition or aggregation, serving or association, pays for itself the first time anyone runs an impact analysis, a rename, or a rule check against the model instead of just looking at a picture of it.

Tooling can help enforce that discipline rather than just hoping for it. Mooodels ships an ArchiMate profile alongside its generic and C4 profiles, so elements and relationships carry their proper ArchiMate types rather than being freehand shapes with matching colors, and its deterministic rules engine can flag the specific mistakes described above — a business process wired directly to a technology service with no application layer in between, a composition relationship that would delete a shared element, a model where association has quietly become the default. None of that replaces understanding the language; it just means the model catches the same category of error a careful reviewer would catch, every time, instead of only when someone happens to look closely.

ArchiMate's real value shows up less in any single diagram and more in what stays true across all of them: the same element, correctly typed, correctly related to its neighbors, means the same thing whether it's shown in an executive landscape, a security review, or an integration diagram nobody outside the platform team will ever see. Learn the layers, learn the four-part pattern, learn what each of the ten relationships actually commits you to, and the rest of the language — the parts this primer only mentioned in passing — turns out to be the same handful of ideas, applied one more time to one more corner of the enterprise.