ArchiMate Business Layer: Actors, Roles, Business Processes and Services in Sparx EA

The ArchiMate business layer describes how an organization delivers value to its stakeholders through people, processes, and services. It organizes every business element into three categories: active structure (who performs work — Business Actor, Business Role, Business Collaboration), behavior (what work happens — Business Process, Business Function, Business Interaction, Business Event, Business Service), and passive structure (what work acts on — Business Object, Contract, Representation, Product). Get two distinctions right — Actor versus Role, and Process versus Function — and the rest of the layer falls into place. In Sparx EA, this is the layer your non-technical stakeholders actually read, so it carries more communication weight than any other.

The three categories of business-layer element

Every element in the business layer belongs to one of three tiers. Knowing which tier an element sits in tells you what connectors it can legitimately carry and what it can be confused with. Keep the tiers straight and the common modeling errors largely disappear.

Active structure: who performs the work

Active structure elements represent the entities that perform — or are capable of performing — behavior.

Business Actor

A Business Actor is a named entity — a person, organizational unit, system, or external party — that performs work. Actors are concrete. Think “Customer Service Team,” “Compliance Officer,” “External Payment Processor,” or “Customer.”

They are named because they exist in organizational reality. “Customer Service Team” is a real unit with people, a manager, and a budget. When you reorganize, the Actors change.

Business Role

A Business Role is a named set of responsibilities or capabilities an Actor can fulfill. Roles are abstract — “Approver,” “Data Owner,” “Process Owner,” “Relationship Manager.”

The distinction is precise: an Actor is something; a Role is something an Actor plays. The Assignment connector links the two — “the Compliance Officer [Actor] is assigned the Data Owner [Role].”

Why it matters in practice: Roles survive reorganizations; Actors do not. A process model built on Actors needs rework every time the org chart shifts. A process model built on Roles stays valid through the change — only the Assignment connectors move. That single design choice is the difference between a model you maintain monthly and one you maintain once.

In Sparx EA, use the Assignment connector from the ArchiMate 3 palette to link Business Actor to Business Role. Never substitute one element type for the other on a diagram — doing so corrupts the semantic model.

Business Collaboration

A Business Collaboration represents two or more Actors working together on a shared behavior. Reach for it when the behavior cannot be attributed to a single Actor and the combined effort is semantically significant — for example, “Joint Venture Management” between two organizations. It appears less often than Actor and Role, but it is the correct tool for cross-organizational and multi-party work.

Behavior: what work happens

Behavior elements describe the work performed by active structure. Five distinct types each serve a different modeling purpose.

Business Process

A Business Process is a sequence of business behaviors, triggered by an event and designed to produce a specific result. Processes are temporal — they start, run, and end, typically kicked off by a Business Event. Examples: “Loan Origination Process,” “Customer Complaint Resolution Process,” “New Employee Onboarding Process.”

Processes are the primary element for modeling cross-functional workflows where sequence and triggers matter, and they compose into the process architecture that shows how the organization creates and delivers value.

Business Function

A Business Function is a collection of business behavior grouped by a unit’s area of responsibility. Functions are continuous and organizational — they do not start and stop; they represent standing operational areas. Examples: “Treasury Management,” “Credit Risk Assessment,” “Human Resources Management.”

Process vs Function: a Process is triggered and ends; a Function is continuous. “Process a loan application” is a Process. “Loan Operations” is a Function — the ongoing responsibility of a team. Use Process when temporal sequence and triggering matter; use Function when describing what a unit is responsible for, independent of any specific trigger.

Business Interaction

A Business Interaction is behavior performed by multiple Actors working collaboratively. It is the behavioral counterpart to Business Collaboration — pair it with a Business Collaboration as the performing active structure.

Business Event

A Business Event is a business-meaningful occurrence that triggers behavior — “Customer Order Received,” “Regulatory Deadline Passed,” “System Alert Generated.” Events are the triggers for Processes; modeling them explicitly makes the process architecture more complete and sharpens any analysis of what sets organizational behavior in motion.

Business Service

A Business Service is the externally visible functionality a Business Role or Actor offers to its environment — the value delivered to a customer or stakeholder, as experienced by whoever receives it. Examples: “Loan Origination Service,” “Customer Support Service,” “Payment Settlement Service.”

Business Services are the external interface of the business layer, connecting the internal (processes, functions) to the external (stakeholders, customers). In cross-layer modeling, Application Services realize Business Services — the technology layer underwrites what the business delivers.

Passive structure: what work acts on

Passive structure elements represent the things active structure creates, uses, transforms, or consumes.

Business Object

A Business Object is a concept or information entity relevant to the business domain — “Customer Record,” “Insurance Policy,” “Invoice,” “Contract Terms.” Business Objects are the business-level counterpart of Data Objects in the application layer and Artifacts in the technology layer. They capture information at the abstraction business stakeholders recognize, independent of how it is stored or processed.

Contract

A Contract is a formal specification of an agreement that one party’s behavior must conform to. Use it for modeling obligations between Actors — supplier contracts, service level agreements, regulatory obligations.

Representation

A Representation is the perceptible form of the information a Business Object carries — a document, report, or other artifact that makes the information visible. A “Loan Assessment Report,” for instance, is a Representation of the “Loan Assessment” Business Object.

Product

A Product is a coherent collection of services and passive structure elements offered to the market — how the organization bundles its Business Services and Business Objects into something a customer perceives and buys. A “Home Loan Product” bundles the “Loan Origination Service,” “Loan Servicing Service,” and “Mortgage Contract” into a single named offering.

The key distinctions: Actor vs Role, Process vs Function

These two pairs are the source of the most common business-layer modeling errors. A quick reference:

Concept	Describes	Stable across reorganizations?	Example
Business Actor	A named entity	No	“Credit Risk Team”
Business Role	A responsibility or capacity	Yes	“Risk Approver”
Business Process	A triggered, sequential behavior with an end state	Largely yes	“Credit Assessment Process”
Business Function	An ongoing responsibility area of an organizational unit	Yes	“Credit Risk Management”

The practical rule that follows: build your process architecture on Roles, not Actors. Build your capability architecture on Functions — or better, on strategy-layer Capabilities. Reserve Actors for the Assignment relationship that records who currently holds which Role.

Modeling a complete business capability end-to-end

The business layer earns its keep when elements connect into coherent patterns. A complete end-to-end view of a business capability draws on all three tiers:

1. Active structure: a Business Actor assigned to a Business Role (who is responsible).
2. Behavior: the Business Role performs a Business Process; the Business Process realizes a Business Service (what happens, and what is delivered).
3. Passive structure: the Business Process accesses a Business Object and produces a Representation (what the work acts on and creates).

In Sparx EA, you model this on a single ArchiMate business-layer diagram using the standard Assignment, Realization, and Access connectors from the ArchiMate 3 palette. The payoff is a view business stakeholders can read on their own — they recognize their Roles, their Processes, and their deliverables. That readability is what makes the business layer the heart of business architecture and the natural home for a capability map.

Connecting the business layer to application and technology

The business layer does not stand alone. Its cross-layer connections are where the architecture proves its value.

Business to application: Application Services serve Business Processes and Business Functions (Serving relationship), and Application Components realize Business Services — the technology enabling what the business delivers. These links make application portfolio rationalization tractable: which applications support which business services, and which services are critical to which strategic goals?

Business to technology: Technology Services support the application layer, which in turn supports the business layer. The chain — Technology Service → Application Component → Business Service — is the vertical traceability that answers “if this server fails, which business services are affected?”

Business to strategy: Business Functions and Processes are realized by or associated with Capabilities in the strategy layer. A Capability such as “Customer Onboarding” is realized by the “Customer Onboarding Process” together with the applications and technology behind it.

In Sparx EA, draw these relationships with the Serving connector (for support) and the Realization connector (for fulfillment). Combining business and application layers on one canvas is standard ArchiMate practice and is fully supported by the Sparx EA ArchiMate MDG Technology.

Frequently asked questions

Model business reality your stakeholders actually recognize

A well-constructed ArchiMate business layer is the single most important communication tool in an enterprise architecture practice. It speaks the language of business stakeholders while giving you the structural foundation for application and technology analysis. Get the Actor/Role and Process/Function distinctions right, connect the tiers with the correct connectors, and the rest of the model follows.

Sparx Services’ training for architects builds exactly this capability — from ArchiMate notation discipline to business-layer governance to the connection patterns that make cross-layer analysis work.