The ArchiMate business layer describes how an organization delivers value to its stakeholders through people, processes, and services. It contains three categories of element: active structure (who performs work — Business Actor, Business Role, Business Collaboration), behaviour (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). Understanding the distinctions between elements within each category — particularly Actor vs Role and Process vs Function — is the foundation of a coherent business layer model. In Sparx EA, the business layer is the primary arena for capability modeling, process architecture, and stakeholder communication, and it is the layer that most directly determines whether non-technical stakeholders can engage with the architecture.
Key Takeaways
- The business layer answers “what the organization does and who does it” — the operational reality stakeholders recognize
- Actor vs Role is the most important distinction: an Actor is a named entity; a Role is a capacity or responsibility
- Process vs Function is the second critical distinction: a Process is triggered and produces a result; a Function is an ongoing grouping of behaviour by unit
- Business Service is the external-facing interface of business behaviour — what the organization offers to external parties
- Well-modeled business layer elements connect upward to Capabilities (strategy layer) and downward to Application Services (application layer), creating the cross-layer traceability that EA is built to provide
Active Structure: Who Performs the Work
Active structure elements in the business layer represent the entities that perform or are capable of performing behaviour.
Business Actor
A Business Actor is a named entity — a person, organization unit, system, or external party — that performs work. Business Actors are concrete. Examples: “Customer Service Team,” “Compliance Officer,” “External Payment Processor,” “Customer.”
Actors are named because they exist in organizational reality. “Customer Service Team” is a real named unit. It has people, a manager, and budget. When you reorganize, Actors change.
Business Role
A Business Role is a named set of responsibilities or capabilities that an Actor can fulfill. Roles are abstract. Examples: “Approver,” “Data Owner,” “Process Owner,” “Relationship Manager.”
The distinction: an Actor is something; a Role plays something. The Assignment connector links an Actor to a Role: “The Compliance Officer [Actor] is assigned the Data Owner [Role].”
Why this distinction matters: Roles are stable across organizational changes. Actors change when teams are reorganized. A process model built on Actors must be updated every time the org chart changes. A process model built on Roles remains valid when people or teams change — only the Assignment connectors need updating.
In Sparx EA, use the Assignment connector (from ArchiMate 3 connector palette) to link Business Actor to Business Role. Do not substitute one for the other in diagrams — it corrupts the semantic model.
Business Collaboration
A Business Collaboration represents two or more Actors working together to perform a shared behaviour. Use Business Collaboration when the behaviour cannot be attributed to a single Actor and the combined effort of multiple parties is semantically significant. Example: “Joint Venture Management” between two organizations.
Business Collaboration is less commonly used than Actor and Role but is important for modeling cross-organizational processes and multi-party interactions accurately.
Behaviour: What Work Happens
Behaviour elements describe the work performed by active structure elements. Five distinct behaviour types serve different modeling purposes.
Business Process
A Business Process is a sequence of business behaviours triggered by an event and designed to produce a specific result. Processes are temporal — they start, they run, and they end. They are typically triggered 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, especially when the sequence and triggers matter. They compose into process architectures that show how the organization creates and delivers value.
Business Function
A Business Function is a collection of business behaviour grouped by a unit’s area of responsibility. Functions are continuous and organizational — they do not start and end; they represent ongoing operational areas.
Examples: “Treasury Management,” “Credit Risk Assessment,” “Human Resources Management.”
The Process vs Function distinction: 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. In ArchiMate, use Process when temporal sequence and triggering matter. Use Function when describing what an organizational unit is responsible for, independent of specific triggers.
Business Interaction
A Business Interaction is behaviour performed by multiple Actors working collaboratively. It is the behavioural counterpart to Business Collaboration — use it with a Business Collaboration as the performing active structure.
Business Event
A Business Event is a business-meaningful occurrence that triggers behaviour. Examples: “Customer Order Received,” “Regulatory Deadline Passed,” “System Alert Generated.”
Events are the triggers for Processes. Modeling Events explicitly makes the process architecture more complete and enables better analysis of what initiates organizational behaviour.
Business Service
A Business Service is the externally visible functionality that a Business Role or Actor offers to its environment — the value delivered to a customer or stakeholder. Business Services represent what the organization provides, as experienced by those who receive it.
Examples: “Loan Origination Service,” “Customer Support Service,” “Payment Settlement Service.”
Business Services are the external interface of the business layer. They connect the internal (processes, functions) to the external (stakeholders, customers). In cross-layer modeling, Application Services realize Business Services — the technology layer supports what the business delivers.
Passive Structure: What Work Acts On
Passive structure elements represent the things that active structure elements create, use, transform, or consume.
Business Object
A Business Object is a concept or information entity relevant to the business domain. Examples: “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 represent information at the abstraction level that business stakeholders recognize, independent of how the information is stored or processed technically.
Contract
A Contract is a formal specification of an agreement that the behavior of one party must conform to. Use Contract when modeling obligations between Actors — supplier contracts, service level agreements, regulatory obligations.
Representation
A Representation is the perceptible form of the information carried by a Business Object — a document, report, or other artifact that makes the information visible. Example: a “Loan Assessment Report” 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. Products are how the organization bundles its Business Services and Business Objects into something a customer perceives and purchases.
Example: “Home Loan Product” bundles the “Loan Origination Service,” “Loan Servicing Service,” and the “Mortgage Contract” into a named market offering.
The Key Distinction: Actor vs Role, Process vs Function
These two distinctions are the source of the most common errors in business layer modeling. 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 behaviour 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 implication: build your process architecture on Roles, not Actors. Build your capability architecture on Functions (or better, Strategy layer Capabilities). Reserve Actors for the assignment relationship that shows who currently holds which role.
Modeling a Complete Business Capability End-to-End
The business layer shines when elements are connected into coherent patterns. A complete end-to-end view of a business capability uses all three categories:
- Active structure: Business Actor assigned to Business Role (who is responsible)
- Behaviour: Business Role performs Business Process; Business Process realizes Business Service (what happens, what is delivered)
- Passive structure: Business Process accesses Business Object; Business Process produces Representation (what the work acts on and creates)
In Sparx EA, this is modeled on a single ArchiMate business layer diagram using the standard Assignment, Realization, and Access connectors from the ArchiMate 3 palette. The result is a view that business stakeholders can read — they recognize their Roles, their Processes, their deliverables.
Connecting the Business Layer to Application and Technology Layers
The business layer does not exist in isolation. Its cross-layer connections are where architecture earns its value.
Business to Application: Application Services serve Business Processes and Business Functions (Serving relationship). Application Components realize Business Services — the technology enables what the business delivers. These are the connections that make application portfolio rationalization tractable: which applications support which business services, and which business 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 impacted?”
Business to Strategy: Business Functions and Business Processes are realized by or associated with Capabilities (strategy layer). A Capability like “Customer Onboarding” is realized by the combination of the “Customer Onboarding Process” (Business layer) and the applications and technology that support it.
In Sparx EA, draw these cross-layer relationships using the Serving (for support relationships) and Realization (for fulfillment relationships) connectors. Cross-layer diagrams — combining business and application layers on the same canvas — are standard ArchiMate practice and are fully supported by the Sparx EA ArchiMate MDG.
FAQ
What is the difference between a Business Actor and a Business Role in ArchiMate? A Business Actor is a named entity — a specific person, team, or organization — that performs work. A Business Role is a named set of responsibilities or capacities that an Actor can fulfill. Actors are concrete and change with organizational structure; Roles are abstract and stable. The Assignment connector links Actor to Role. Build process and service architectures on Roles, not Actors, so the model remains valid across reorganizations.
What is the difference between a Business Process and a Business Function in ArchiMate? A Business Process is a triggered, sequential behaviour with a defined end state — it starts, runs, and produces an output. A Business Function is an ongoing area of responsibility of an organizational unit — it represents continuous activity rather than a triggered sequence. Use Process when temporal sequence and triggering matter. Use Function when describing what a unit is responsible for as an ongoing operation. Both are valid ArchiMate elements serving different modeling purposes.
What is a Business Service in ArchiMate and how does it relate to a Business Process? A Business Service is the externally visible functionality that the organization offers to its environment — the value delivered to a stakeholder or customer. A Business Process is the internal sequence of activities that produces that value. The relationship: Business Process realizes Business Service. The Process is how the value is produced internally; the Service is how it appears externally. This distinction is critical for application portfolio management — applications serve Processes, but the business impact is measured at the Service level.
How does the business layer connect to the application layer in ArchiMate? Application Services serve Business Processes and Business Functions using the Serving connector. Application Components realize Business Services using the Realization connector. This cross-layer connection is how ArchiMate models the relationship between business operations and technology support, enabling capability-to-application mapping and impact analysis.
What is a Business Object in ArchiMate? A Business Object is a concept or information entity recognized at the business level — the business-meaningful abstraction of information, independent of how it is stored or processed. Examples include Customer Record, Invoice, Policy, or Contract. Business Objects are accessed by Business Processes and Roles, and they correspond to (but are distinct from) Data Objects in the application layer. The distinction: Business Object = what the business understands; Data Object = what the application manages.
Can I model BPMN processes and ArchiMate business processes in the same Sparx EA repository? Yes. Sparx EA supports both notations natively. BPMN is appropriate for detailed process flow modeling with gateways, events, and swim lanes. ArchiMate Business Processes are appropriate for enterprise-level process architecture — the map of what processes exist, how they connect, and how they relate to capabilities and applications. Use both in the same repository, with ArchiMate providing the structural map and BPMN providing the detailed flow where precision is needed.
What is the purpose of the Product element in the ArchiMate business layer? Product represents a coherent bundle of services and information offered to the market or to external stakeholders. It groups Business Services and Business Objects into the named offering that a customer recognizes and selects. Modeling Products is particularly valuable for product portfolio analysis — understanding which capabilities, processes, applications, and data underpin each product line, and which shared components create cross-product dependencies.
How do I use business layer elements to support application portfolio rationalization? Model the connection between Business Services (what the business delivers) and Application Components (what technology supports them) using Realization connectors. Assess each Application Component against the Business Services it realizes — an Application Component with no realized Business Service is a rationalization candidate. Multiple Application Components realizing the same Business Service indicate redundancy. These queries are automatable via EA GraphLink when the connections are modeled correctly in the repository.
Model Business Reality That Stakeholders Actually Recognize
A well-constructed ArchiMate business layer is the single most important communication tool in an EA practice. It speaks the language of business stakeholders while providing the structural foundation for application and technology architecture analysis.
Sparx Services’ Amplify program builds this capability in EA teams — from ArchiMate notation discipline to business layer governance to the connection patterns that make cross-layer analysis possible.
