ArchiMate Notation Quick Reference: Elements by Layer

⏱ 24 min read

Monday, 08:37.

The steering meeting has already drifted off course.

The programme office says the issue is a missing business capability. The delivery team insists the dependency is an application service. Infrastructure says the real blocker is the platform. The data office asks a perfectly reasonable question—where, exactly, is the authoritative register? Legal wants to know whether the audit trail is preserved across agencies. Security asks whether the member-state-facing portal sits inside the same trust boundary as the internal case platform. Procurement reminds everyone that the hosting lot expires in nine months, so please do not model fantasies.

And there you are, the integration architecture lead, trying to stop a two-hour meeting from collapsing into word salad.

In that moment, ArchiMate is either useful or it is dead weight. ArchiMate training

Not because the notation is flawed. It isn’t. The problem is that most “quick references” are written as if architecture teams operate in a clean lab: tidy ownership, stable terminology, one enterprise boundary, no institutional friction. That is not how it feels in EU institutions. In practice, you are usually dealing with multiple Commission services, one or more agencies, external authorities, portals exposed to member states or beneficiaries, a few legacy systems nobody wants to touch before the next budget cycle, and a governance trail long enough to satisfy audit, legal, security, and funding oversight. ArchiMate for governance

So this is not a certification crib sheet.

It is a practical, layer-by-layer field guide for the elements that matter most when you are trying to model integration-heavy landscapes under delivery pressure. The viewpoint here is deliberate: an integration lead working across federated public-sector environments where accountability is distributed, constraints are real, and diagrams need to survive contact with governance boards.

Why “elements by layer” gets messy quickly

Textbooks present ArchiMate layers as a tidy stack. Business on top. Application underneath. Technology below that. Strategy and motivation around the edges. Implementation off in one corner. ArchiMate modeling guide

Useful in theory. Much messier in the real world.

A shared registry, for example, is often described as a business asset by policy teams, a master data domain by information architects, an application service by integration teams, and a database service by operations. All of those views can be legitimate, depending on the question being asked. The trouble starts when they are all mixed into one diagram with no clear point of view.

Same with an API gateway. I have seen it modelled as a platform, a product, an application component, an application service, and—on particularly creative days—a technology service. Again, not always wrong. But if you do not decide which concern the view is supposed to answer, the notation becomes decorative.

Case management platforms are another classic trap. People talk about process design, workflow rules, human task assignment, document retention, service exposure, and integration orchestration as if they are one thing. They are not.

This matters more in EU institutional settings than in many private-sector environments, in my experience. In a smaller company, ambiguity can often be absorbed informally. Someone knows who really owns the thing. In federated public-sector architecture, ambiguity tends to linger. Then it hardens into governance debt. Shared services cross directorates. Platforms are outsourced under framework contracts. Interoperability mandates apply unevenly. Data classification and residency complicate hosting choices. Old national interfaces coexist with newer API-led approaches. Kafka appears for events in one domain while another still moves critical documents by secure email.

That is exactly why layer discipline matters. Not purity for purity’s sake. Accountability.

Before we get into the notation, let’s anchor it in a scenario that feels real.

Running example: cross-border grant and compliance reporting

Imagine an EU institution administering a funding programme. TOGAF training

Applicants submit through a public portal. Internal officers review and assess cases. External agencies validate some information. Financial systems handle commitments and payments. A document repository stores dossiers, annexes, signed decisions, and evidence files. Oversight and audit bodies need reporting. Member-state-facing channels consume some of the same information through different interfaces. The architecture is meant to support multilingual services, traceability, segregation of duties, and proper records retention.

Now add the usual friction.

Applicant data is duplicated across the portal, the CRM-like intake solution, and the case management platform. There are APIs, but ownership is murky. A “shared integration service” exists, except nobody can quite explain whether it is an ESB, an API manager, a Kafka backbone, or simply a team. Documents are still exchanged by email for a handful of edge cases because one agency never adopted the common platform. Process maps live in one repository. Application inventories live in another. Neither aligns well enough to support planning.

This is where ArchiMate earns its keep.

Not by representing everything equally. That is a trap I have seen more than once. What helps is the ability to tie together actors, roles, business services, processes, application components, interfaces, services, data objects, and technology dependencies in a way that lets mixed teams see boundaries clearly.

That is the lens for the rest of this article.

The quick-reference table first

Because, if we are honest, this is what most people scroll for.

ArchiMate Elements by Layer for Integration-Focused Architecture

A quick reference is useful. But it is not a substitute for modelling intent. The same element can be either exactly right or actively misleading depending on the question your view is trying to answer.

That distinction is where most repositories start to decay.

Business layer: where integration leaders either clarify everything or create chaos

A practical test I use with teams is blunt, but effective:

If the thing would still exist even if the software changed tomorrow, start by asking whether it belongs in the business layer.

Not always. But very often.

Business Actor

A Business Actor is the entity that performs behavior. In institutional environments that can be an EU agency, a Commission service, a national authority, a beneficiary organisation, or an internal office.

If you are trying to show who participates in the operating model, actor is usually your friend.

Examples in the running scenario:

• Applicant Organisation
• Programme Office
• External Validation Agency
• Audit Authority

What I see teams do wrong is model every organisational box they can find. That creates chartware. The point is not to reproduce the org chart. The point is to represent the actors that matter to the architecture question at hand.

Business Role

Business Role is often more useful than actor.

Why? Because federated environments run on responsibilities more than org structures. A role like Authorising Officer, Data Controller, Paying Authority, or Programme Manager can remain stable even when the underlying organisational unit changes.

This matters in cross-institution work. A role can be assigned to different actors in different contexts, and that is often exactly the nuance you need.

If accountability matters more than hierarchy, use a role.

Business Process

Use Business Process when sequence matters.

Application intake. Eligibility review. Payment approval. Compliance reporting. Audit follow-up.

In our grant scenario, the process view might show:

• Receive application
• Validate completeness
• Assess eligibility
• Issue decision
• Trigger payment
• Report to oversight

That is useful because integration often follows process seams. Events are emitted at stage changes. Documents are produced at handoffs. APIs support transitions. IAM policies reflect who may act at which step.

The mistake is drawing every activity as a process. Not every stable business behavior is a process.

Business Function

Use Business Function for stable groupings of business behavior, where sequence is not the point.

Examples:

• Grant Administration
• Compliance Management
• Beneficiary Support
• Financial Control

Functions are good for capability-to-operating-model conversations. They are less useful if the real question is handoff sequence or event timing.

Business Service

This one causes endless confusion.

A Business Service is what the business exposes to its environment in terms of outcome or externally visible behavior. Not a website. Not a system. Not a department name with “service” tacked on because it sounds modern.

In the running example, Grant Assessment Service is a business service. It may be consumed by applicants, internal officers, or other institutional bodies through different channels and supported by several applications. The business service is the outcome-facing concept.

This is where API programmes often stumble. Teams design endpoints before anyone agrees on the business service behind them.

Business Object

A Business Object is a business-relevant piece of information or artefact.

Examples:

• Application Dossier
• Decision Record
• Audit File
• Funding Agreement

This is not yet the same thing as the application-managed representation of that information. We will come back to that in the data section, because the confusion between business object and data object is one of the most persistent modelling mistakes I see.

A practical rule of thumb:

• use role when responsibility matters
• use process when sequence matters
• use function when stable grouping matters
• use service when the business outcome exposed to others matters

Simple. Not simplistic.

The diagram I wish teams would stop drawing

Let me be slightly rude for a minute.

There is a diagram that appears in almost every large architecture estate at some point. It contains boxes named Portal, Workflow, SAP, Data Lake, Users, Network, maybe Kafka, maybe IAM, maybe Cloud. Then arrows. So many arrows. Some arrows mean data flow. Some mean hosting. Some mean “is connected to”. Some mean “we bought this already”.

Nobody can explain it six weeks later.

I genuinely wish teams would stop producing these.

They fail especially badly in EU institutional settings because they cannot answer the questions that actually come up in governance:

• Who owns the business service?
• Which application realizes it?
• Where is authoritative data managed?
• Which body consumes the service?
• What legal or policy constraints apply?
• Is the shared platform really shared, or just centrally funded?
• Which changes belong in the current architecture and which are roadmap items?

A better approach is to choose one question per view.

For example:

• Who provides the business service?
• Which application components realize that service?
• Which interfaces are exposed externally?
• Where is authoritative data created and maintained?
• Which technology services matter to trust, resilience, or hosting responsibility?

That one discipline alone improves architecture communication more than adding twenty more metamodel relationships.

Now, into the actual battleground.

Application layer: where integration architecture really lives

If you work in integration, this is the layer you probably inhabit most days.

And it is also where teams get sloppy fastest.

Application Component

An Application Component is the software building block itself. A deployable or logically distinct application unit.

In the running example:

• Submission Portal
• Case Management Platform
• Financial Management System
• Document Repository
• API Gateway
• IAM Platform
• Notification Service

I strongly prefer naming components by responsibility, not vendor alone. “Salesforce” or “SAP” tells me almost nothing architecturally. Case Management Platform (implemented on Dynamics) is far more useful. Vendor matters, certainly. Responsibility matters more.

Application Collaboration

Use Application Collaboration when several application components work together to provide behavior.

A good example is an integration-facing collaboration involving:

• API Gateway
• Identity Provider
• Notification Service
• Event Streaming Backbone (Kafka)
• Integration Orchestration Component

Together, these may support secure service exposure and event-driven workflows across agencies. Modelling them as a collaboration can be clearer than pretending one box does everything.

This is especially useful in shared service landscapes where responsibility is distributed and no single component owns the whole story.

Application Interface

An Application Interface is the access point through which application services are exposed.

For the grant scenario, that might be:

• Public REST API for application submission status
• Secure B2B interface for agency validation
• Back-office UI used by officers
• Event subscription endpoint on Kafka
• SFTP interface for a stubborn legacy exchange that survived another year

The key distinction: the interface is not the service itself. It is how the service is exposed.

That sounds obvious until you look at most repositories.

Application Function

Use Application Function for internal application behavior grouped by responsibility.

Examples:

• Eligibility Rules Evaluation
• Document Classification
• Identity Assertion Processing
• Notification Composition

Function is useful when you need to explain what the application does internally without drifting into full process flow.

Application Process

Use Application Process when sequence within the application matters.

Examples:

• Case Orchestration
• Submission Validation Workflow
• Payment Trigger Sequence

This becomes relevant when a platform coordinates multiple steps, perhaps across synchronous APIs and asynchronous events. In modern estates, especially those using workflow engines or case platforms, this distinction matters. A rules evaluation function is not the same thing as an orchestration process.

Application Service

This is the element integration architects need to get right.

An Application Service represents externally visible application behavior. Something another application, user, or channel can consume.

Examples:

• Beneficiary Validation API
• Document Retrieval Service
• Payment Instruction Service
• Identity Token Validation Service
• Event Publication Service

Notice what these are not: they are not “the portal” or “the case management system”. Those are components. The service is the behavior exposed.

I have a strong opinion here: if an integration architect cannot clearly distinguish an application service from an application interface, the rest of the repository becomes mostly decorative. You can still draw attractive diagrams. They just will not hold under governance or delivery stress.

Data Object

A Data Object is application-layer information handled by software.

Examples:

• Beneficiary Record
• Payment Instruction
• Validation Result
• Submission Package Metadata
• Access Token Claims Set

In practical integration modelling, data object is often enough. You do not need to force every information concept through a complex information architecture model just to make a useful view. But you do need to be honest about what the object represents: an application-managed form of data, not the entire business meaning of the concept.

A few common mistakes in the application layer deserve blunt treatment:

• Naming components only after vendors
• Putting interfaces on every box whether they matter or not
• Treating the integration platform as a magical black hole
• Collapsing orchestration, service exposure, and runtime platform into one symbol
• Calling every application an application service because “service-oriented” sounds mature

In one EU environment I worked with, a shared master data service was consumed by several agencies through APIs, while ownership sat with one institutional application owner. The architecture only became governable once we separated:

• the business service of maintaining beneficiary information
• the application component providing that behavior
• the application service exposed through governed APIs
• the data objects managed by the service
• the IAM and platform elements enabling access and hosting

Before that, every conversation went in circles.

Data confusion: records, registers, and the mythical single source of truth

This deserves its own section because otherwise half the article would turn into people arguing about semantics in the comments.

The most useful distinction is this:

• Business Object = business-relevant thing
• Data Object = application-managed information representation

The same concept may appear in both layers, and that is fine.

For example:

• Beneficiary File as a business object
• Beneficiary Record as a data object

Or:

• Official Decision Document as a business object
• Decision Metadata as a data object

That does not mean you are duplicating meaning carelessly. It means you are representing different concerns.

Authoritative registers are where this gets interesting. A register may be a business asset from an operating model perspective, but architecturally you still need to show where the data is managed, which application component owns updates, which services expose it, and which consumers access it.

So in practice, for an authoritative register, I usually model:

• the business object or business service context at the business layer
• the application component that manages the register
• the application services through which it is consumed
• the data objects that applications access
• and, if necessary, constraints or principles that govern its use

What I do not do is pretend one ArchiMate data object equals semantic harmonisation. It does not. If your cross-institution data meaning is contested, you still need a glossary, canonical model, or proper information architecture work. ArchiMate will not rescue you from weak semantics.

That lesson usually arrives expensively.

Technology layer: enough to be credible, not enough to derail the story

Technology matters. But it should enter the diagram for the right reasons.

The core elements most integration leads actually need are straightforward:

• Node
• Device
• System Software
• Technology Service
• Communication Path
• sometimes Artifact

Node

A Node is a computational or hosting structure.

Examples:

• Managed cloud tenant partition
• Kubernetes cluster
• On-prem application host
• Managed integration runtime

Be careful not to use node for every environment label. “TEST” is not an architecture element. It is an environment designation.

Device

Use Device when a physical device matters to the architecture.

That may be rare in digital integration views, but not nonexistent. A hardware security module, signing appliance, secure scanning station, or specialised archive equipment can matter in regulated workflows.

System Software

System Software covers software environments providing runtime support.

Examples:

• Container runtime
• API management platform software
• Database engine
• Identity middleware

In cloud-heavy estates, teams often skip this and jump directly from application to node. That is usually fine until runtime responsibility or portability becomes a serious concern.

Technology Service

A Technology Service is infrastructure behavior exposed to applications or other technology elements.

Examples:

• Managed Database Service
• Secrets Management Service
• Load Balancing Service
• Identity Hosting Service
• Object Storage Service

This is where people mix up application and technology layers all the time. A business-facing Document Retrieval Service is not the same as the underlying Object Storage Service.

Communication Path

A Communication Path matters when network segmentation, trust boundaries, or secure data transfer are material to the design.

In our scenario:

• secure inter-institution network path
• segmented network zone between public portal and internal applications
• dedicated path to an external validation agency
• private connectivity to a managed cloud service under EU sovereignty constraints

If resilience, trust, or hosting boundaries matter, model them. If not, leave them out.

That is the balancing act. In my experience, teams either under-model technology until operations rejects the architecture as fantasy, or over-model it so heavily that business and application accountability disappear under firewall icons.

A believable technology view for the grant scenario might show:

• case platform deployed on a managed Kubernetes node
• document repository using managed object storage and database services
• IAM integrated via a managed identity platform
• Kafka event brokers running in a secured shared integration environment
• communication paths representing external agency connections and internal secure zones

Enough to support decisions. Not enough to drown them.

The layers everyone forgets until governance gets involved

You can get surprisingly far with business, application, and technology. Then governance asks why the “simplest” option was not chosen, and suddenly you need motivation, strategy, and implementation.

Motivation layer

This layer is underrated in public-sector architecture.

The useful elements are:

• Stakeholder
• Driver
• Assessment
• Goal
• Outcome
• Principle
• Requirement
• Constraint

In EU institutional work, these are not abstract decoration. They explain why a technically elegant option may be rejected.

Examples:

• Stakeholder: Audit Authority, Data Protection Officer, Programme Office
• Driver: interoperability mandate, funding transparency, fraud prevention
• Principle: once-only, API-first, reuse before buy
• Requirement: end-to-end traceability for case decisions
• Constraint: procurement lot boundaries, multilingual obligations, retention law, data residency rules

An integration lead who ignores motivation elements eventually gets trapped in false debates. “Why don’t we just centralise it?” Because there is a procurement constraint. “Why not expose a direct API?” Because records law and accountability require a controlled channel. “Why not stream all events onto Kafka?” Because not every consumer is allowed onto the same trust boundary.

Motivation elements make those reasons visible.

Strategy layer

Use this when architecture needs to support roadmap decisions rather than just describe current structure. ArchiMate in TOGAF

Most practical elements:

• Capability
• Resource
• Course of Action
• Value Stream

Examples:

• Capability: Cross-Institution Data Exchange
• Resource: Shared Integration Platform Team
• Course of Action: consolidate fragmented interfaces into governed API products
• Value Stream: Apply for Funding to Receive Decision

The common mistake is capability maps floating free from architecture reality. Lovely PowerPoint. No trace to services, processes, or applications. If capability cannot eventually connect downwards, it is usually just strategy wallpaper.

Implementation & Migration

When current-to-target matters, this layer becomes essential.

Key elements:

• Work Package
• Deliverable
• Plateau
• Gap

Examples:

• Current Plateau: fragmented grant systems and unmanaged point-to-point interfaces
• Target Plateau: shared case services, governed APIs, common IAM, event-driven notifications
• Work Package: beneficiary master data rationalisation
• Gap: missing audit trace integration between portal and case platform

A practical warning: keep projects and architecture distinct, but linked. If your target-state diagram turns into a Gantt chart with boxes, it stops being architecture.

How the layers connect in one believable story

You do not need to teach the entire metamodel to be useful. What matters is the chain.

In the grant scenario, one simple architecture narrative might look like this:

• A Business Role such as Funding Officer performs the Business Process Eligibility Review.
• That process is supported by an Application Service such as Eligibility Assessment Service.
• The service is realized by an Application Component like the Case Management Platform.
• The component accesses Data Objects including Beneficiary Record and Validation Result.
• It is deployed on a Node in a managed cloud environment and depends on Technology Services such as managed database and IAM.
• A Requirement for auditability constrains the solution.
• A Work Package introduces event traceability and API governance to move from current to target.

That chain is often enough.

For integration leads, the relationships that matter most are usually:

• serving
• realization
• assignment
• access
• flow

Composition and aggregation are useful, but overused. Many repositories suffer less from missing elements than from careless relationships and arrows that mean whatever the author needs them to mean that day.

Three snapshots from real institutional life

A. Shared identity and access across agencies

Business service: user onboarding and access approval.

Application services: identity federation, token validation, role provisioning.

Technology services: managed identity platform, secure key management.

The recurring mistake is treating SSO as just infrastructure. It is not. The moment access approval, delegated administration, and auditability matter across agencies, there is business accountability involved. If you model IAM only as technology, you hide the operating model.

B. Regulatory reporting pipeline

Business process: compile, validate, submit, audit.

Application components: reporting engine, validation rules service, archive repository, Kafka-based event dispatcher.

Data objects: submission package, validation result, audit evidence.

The mistake here is almost always the same: process maps disconnected from system responsibilities. People know the reporting stages, but not which application service supports which stage, or where the authoritative submission package is assembled.

C. Document-heavy grant workflow

Business objects: dossier, decision, annex.

Application services: document ingestion, e-signature, retrieval, retention hold.

Technology concerns: secure object storage, HSM-backed signature device, retention controls.

The common modelling error is labelling the whole repository as a “content service” without distinguishing:

• service exposure
• application responsibility
• storage responsibility
• retention control
• signature trust boundary

That distinction is not pedantic. It affects procurement, security review, and audit defensibility.

A practical quick reference for when you are under pressure

When the meeting is moving too fast, use these shortcuts.

If you are trying to show:

• who is accountable → Business Role
• who participates organisationally → Business Actor
• what the organisation offers → Business Service
• what sequence the business follows → Business Process
• the software building block itself → Application Component
• what a system exposes → Application Service
• how that service is accessed → Application Interface
• the information managed by the application → Data Object
• where it runs → Node
• what infrastructure provides to support runtime → Technology Service
• why it exists or what constrains it → Driver / Goal / Requirement / Constraint
• how it changes over time → Plateau / Work Package / Gap

A few heuristics I trust:

If stakeholders are arguing about semantics, go up a layer.

If teams are arguing about APIs, ownership, and system boundaries, stay in the application layer.

If operations is arguing about resilience, sovereignty, trust boundaries, or runtime accountability, add technology.

And one warning worth repeating: not every concern belongs in one diagram.

What experienced reviewers usually flag

By the time a model reaches a serious review board, certain problems show up again and again.

• Services with no consumers
• Application components with business names that hide technical responsibility
• Capabilities copied from strategy decks with no architectural trace
• Arrows used decoratively
• Data objects shown everywhere, owned nowhere
• Implementation views masquerading as target architecture
• Shared services not distinguished from local applications
• External institutional boundaries handled vaguely
• Legal or policy constraints absent from the model entirely

In EU governance settings, reviewers also look for whether external actors are represented clearly enough and whether the architecture acknowledges institutional boundaries rather than pretending one enterprise owns everything.

The fix patterns are not glamorous:

• simplify the purpose of each view
• rename elements by behavior or responsibility
• add consumers and ownership
• separate current and target states
• connect requirements to the design where they actually matter

That is usually enough to improve a model dramatically.

A compact notation cheat sheet

Here is the version I would actually keep handy.

• Business Role — use for accountability; anti-pattern: using org units when responsibility is what matters
• Business Process — use for business sequence; anti-pattern: modelling every activity as a process
• Business Service — use for business outcome exposed; anti-pattern: naming a website or department as a service
• Business Object — use for business artefacts and information; anti-pattern: pretending it replaces data modelling
• Application Component — use for software building blocks; anti-pattern: vendor-only names
• Application Interface — use for access points; anti-pattern: confusing interface with service
• Application Service — use for externally visible application behavior; anti-pattern: calling the whole system a service
• Data Object — use for application-managed information; anti-pattern: claiming semantic harmonisation from one box
• Node — use for runtime/hosting structure; anti-pattern: using it as an environment label
• Technology Service — use for infrastructure behavior; anti-pattern: mixing it with business-facing functionality
• Requirement — use for design constraints and obligations; anti-pattern: leaving it disconnected from the solution
• Capability — use for strategic ability; anti-pattern: strategy wallpaper with no traceability
• Work Package — use for planned change; anti-pattern: turning target architecture into project management diagrams

If you only memorise six elements as an integration lead, I would pick:

Business Role, Business Service, Application Component, Application Service, Data Object, Requirement.

Those six get you a long way.

A simple visual chain

And a second one for the service/interface distinction:

Not exhaustive. Just enough to stop the usual confusion.

Back to the Monday meeting

The problem in that meeting was never really notation trivia.

It was the absence of shared modelling discipline.

One team was talking about a business capability. Another about an application service. Infrastructure was talking about platform runtime. Data governance wanted authoritative ownership. All valid concerns. The failure was that they were all using one vocabulary blob and one overloaded set of diagrams.

ArchiMate is at its best when it makes boundaries visible for mixed teams.

In EU institutional environments, that means a few things very concretely:

• clarifying service ownership
• separating business intent from application behavior
• showing where authoritative data is actually managed
• making requirements and constraints explicit
• connecting target architecture to realistic transition steps
• and resisting the urge to hide politics inside ambiguous boxes

A good layer model will not remove politics.

Nothing will.

But it does something almost as valuable: it stops politics from disguising itself as architecture.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.

How does ArchiMate support enterprise architecture?

ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.

What tools support enterprise architecture modeling?

The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.