Business Layer elements are used to model the operational organization of an enterprise in a technology-independent manner, whereas strategy elements (Chapter 7) are used to model the strategic direction and choices of the enterprise.
Figure 52 gives an overview of the Business Layer elements and their relationships. “Business Internal Active Structure Element”, “Business Internal Behavior Element”, and “Business Passive Structure Element” are abstract elements; only their specializations (as defined in the following sections) are instantiated in models.
Figure 52: Business Layer Metamodel
Note: This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7.
The active structure aspect of the Business Layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships. The active entities are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.
Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the element of business collaboration has been introduced.
The element of business interface is introduced to explicitly model the (logical or physical) places or channels where the services that a role offers to the environment can be accessed. The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current Business Layer modeling approaches to recognize the business interface element.
In the Business Layer, three types of internal active structure element are defined: business actor, business role, and business collaboration.
Figure 53: Business Internal Active Structure Elements
Note: This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7. The full specification of permitted relationships can be found in Appendix B.
A business actor represents a business entity that is capable of performing behavior.
A business actor is a business entity as opposed to a technical entity; i.e., it belongs to the Business Layer. Actors may, however, include entities outside the actual organization; e.g., customers and partners. A business actor can represent such business entities at different levels of detail and may correspond to both an actor and an organizational unit in the TOGAF framework [4]. Examples of business actors are humans, departments, and business units.
A business actor may be assigned to one or more business roles. It can then perform the behavior to which these business roles are assigned. A business actor can be aggregated in a location. The name of a business actor should preferably be a noun. Business actors may be specific individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic; e.g., “customer” or “supplier”.
Figure 54: Business Actor Notation
A business role represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event.
Business roles with certain responsibilities or skills are assigned to business processes or business functions. A business actor that is assigned to a business role is responsible for ensuring that the corresponding behavior is carried out, either by performing it or by delegating and managing its performance. In addition to the relation of a business role with behavior, a business role is also useful in a (structural) organizational sense; for instance, in the division of labor within an organization.
A business role may be assigned to one or more business processes or business functions, while a business actor may be assigned to one or more business roles. A business interface or an application interface may serve a business role, while a business interface may be part of a business role. The name of a business role should preferably be a noun.
Figure 55: Business Role Notation
ArchiMate modelers may represent generic organizational entities that perform behavior as either business actors or business roles. For example, the business actor “Supplier” depicts an organizational entity, while the business role “Supplier” depicts a responsibility. Specific or generic business actors can be assigned to carry responsibilities depicted as business roles. For example, the specific business actor “ABC Corporation” or the generic business actor “Business Partner” can be assigned to the “Supplier” business role.
A business collaboration represents an aggregate of two or more business internal active structure elements that work together to perform collective behavior.
A business process or function may be interpreted as the internal behavior of a single business role. In some cases, behavior is the collective effort of more than one business role; in fact, a collaboration of two or more business roles results in collective behavior which may be more than simply the sum of the behavior of the separate roles. Business collaborations represent this collective effort. Business interactions can be used to describe the internal behavior that takes place within business collaboration. A business collaboration is a (possibly temporary) collection of business roles, actors, or other collaborations within an organization which perform collaborative behavior (interactions). Unlike a department, a business collaboration need not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles. It is especially useful in modeling Business-to-Business (B2B) interactions between different organizations such as provider networks, and also for describing social networks.
A business collaboration may aggregate a number of business roles, actors, or other collaborations and may be assigned to one or more business interactions or other business internal behavior elements. A business interface or an application interface may serve a business collaboration, while a business collaboration may have business interfaces (through composition, and also through aggregation via derived relationships). The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.
Figure 56: Business Collaboration Notation
A business interface represents a point of access where a business service is made available to the environment.
A business interface exposes the functionality of a business service to other business roles or actors. It is often referred to as a channel (telephone, Internet, local office, etc.). The same business service may be exposed through different interfaces.
A business interface may be part of a business role or actor through a composition relationship, and a business interface may serve a business role. A business interface may be assigned to one or more business services, which means that these services are exposed by the interface. The name of a business interface should preferably be a noun.
Figure 57: Business Interface Notation
The “ArchiSurance Contact Center”, modeled as a business actor, is composed of three employees, also modeled as business actors: “Greg”, “Joan”, and “Larry”. The “ArchiSurance Contact Center” has three business interfaces to serve customers: “Phone”, “E-mail”, and “Web Chat”. Greg fulfills the business role of “Travel Insurance Claim Analyst”, Joan fulfills the business role of “Home Insurance Product Specialist”, and Larry fulfills the business role of “Customer Service Representative”. The former two business roles are specializations of a business role “Specialist”. “High-Risk Claims Adjudication” is a business collaboration of two business roles: “Specialist” and “Customer Service Representative”.
Example 23: Business Active Structure Elements
Based on service-orientation, a crucial design decision for the behavioral part of the ArchiMate metamodel is the distinction between “external” and “internal” behavior of an organization.
The externally visible behavior is modeled by the element business service. A business service represents a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized internally. A distinction can be made between “external” business services, offered to external customers, and “internal” business services, offering supporting functionality to processes or functions within the organization.
Several types of internal behavior elements that can realize a service are distinguished. Although the distinction between the two is not always sharp, it is often useful to distinguish a process view and a function view on behavior; two elements associated with these views, business process and business function, are defined. Both elements can be used to group more detailed business processes/functions but based on different grouping criteria. A business process represents a workflow consisting of smaller processes/functions, with one or more clear starting points and leading to some result. It is sometimes described as “customer to customer”, where this customer may also be an internal customer, in the case of sub-processes within an organization. The goal of such a business process is to “satisfy or delight the customer” [10]. A business function offers functionality that may be useful for one or more business processes. It groups behavior based on, for example, required skills, resources, (application) support, etc. Typically, the business processes of an organization are defined based on the products and services that the organization offers, while the business functions are the basis for, for example, the assignment of resources to tasks and the application support.
A business interaction is a unit of behavior similar to a business process or function, but which is performed in a collaboration of two or more roles within the organization. Unlike the interaction concept in AMBER [9], which is an atomic unit of collaborative behavior, the ArchiMate business interaction can be decomposed into smaller interactions. Although interactions are external behavior from the perspective of the roles participating in the collaboration, the behavior is internal to the collaboration as a whole. Similar to processes or functions, the result of a business interaction can be made available to the environment through a business service.
A business event is something that happens (externally) and may influence business processes, functions, or interactions. The business event element is similar to BPMN event elements, to the trigger element in AMBER [9], and the initial state and final state elements in UML activity diagrams. However, the ArchiMate business event is more generally applicable in the sense that it can also be used to model other types of events, in addition to triggers.
In the Business Layer, three types of internal behavior element are defined: business process, business function, and business interaction.
Figure 58: Business Internal Behavior Elements
Note: This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7. The full specification of permitted relationships can be found in Appendix B.
A business process represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services.
A business process describes the internal behavior performed by a business role that is required to produce a set of products and services. For a consumer, the products and services are relevant and the required behavior is merely a black box, hence the designation “internal”.
A complex business process may be an aggregation of other, finer-grained processes. To each of these, finer-grained roles may be assigned.
There is a potential many-to-many relationship between business processes and business functions. Informally speaking, processes describe some kind of “flow” of activities, whereas functions group activities according to required skills, knowledge, resources, etc.
A business process may be triggered by, or trigger, any other business behavior element (e.g., business event, business process, business function, or business interaction). A business process may access business objects. A business process may realize one or more business services and may use (internal) business services or application services. A business role may be assigned to a business process to perform this process manually. An automated business process can be realized by an application process. The name of a business process should clearly indicate a predefined sequence of actions using a verb or verb-noun combination and may include the word “process”. Examples are “adjudicate claim”, “employee on-boarding”, “approval process”, or “financial reporting”.
In an ArchiMate model, the existence of business processes is depicted. High-level business, end-to-end processes, macro flows, and workflows can all be expressed with the same business process element in the ArchiMate language. It does not, however, list the flow of activities in detail. This is typically done during business process modeling, where a business process can be expanded using a business process design language; e.g., BPMN [12].
Figure 59: Business Process Notation
A business function represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.
Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competencies, knowledge, etc.
There is a potential many-to-many relation between business processes and business functions. Complex processes in general involve activities that offer various functions. In this sense, a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities.
A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may be served by business, application, or technology services. A business role may be assigned to a business function. The name of a business function should clearly indicate a well-defined behavior. Examples are customer management, claims administration, member services, recycling, or payment processing.
Figure 60: Business Function Notation
A business interaction represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations.
A business interaction is similar to a business process/function, but while a process/function may be performed by a single role, an interaction is performed by a collaboration of multiple roles. The roles in the collaboration share the responsibility for performing the interaction.
A business interaction may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business interaction may access business objects. A business interaction may realize one or more business services and may use (internal) business services or application services. A business collaboration or two or more business actors or roles may be assigned to a business interaction. The name of a business interaction should preferably be a verb in the simple present tense.
Figure 61: Business Interaction Notation
A business event represents an organizational state change.
Business processes and other business behavior may be triggered or interrupted by a business event. Also, business processes may raise events that trigger other business processes, functions, or interactions. Unlike business processes, functions, and interactions, a business event is instantaneous: it does not have duration. Events may originate from the environment of the organization (e.g., from a customer), but also internal events may occur generated by, for example, other processes within the organization.
A business event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model time schedules; e.g., to model an event that triggers a recurring business process to execute every first Monday of the month.
A business event may trigger or be triggered (raised) by a business process, business function, or business interaction. A business event may access a business object and may be composed of other business events. The name of a business event should preferably be a verb in the perfect tense; e.g., “claim received”.
Figure 62: Business Event Notation
A business service represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment.
A business service exposes the functionality of business roles or collaborations to their environment. This functionality is accessed through one or more business interfaces.
A business service should provide a unit of behavior that is meaningful from the point of view of the environment. It has a purpose, which states this utility. The environment includes the (behavior of) users from outside as well as inside the organization. Business services can be external, customer-facing services (e.g., a travel insurance service) or internal support services (e.g., a resource management service).
A business service is associated with a value. A business service may serve a business process, business function, or business interaction. A business process, business function, or business interaction may realize a business service. A business interface may be assigned to a business service. A business service may access business objects. The name of a business service should preferably be a verb ending with “-ing”; e.g., transaction processing. Also, a name explicitly containing the word “service” may be used.
Figure 63: Business Service Notation
“Claims Administration” is a business function that is composed of a number of business processes and a business interaction. This business function realizes a “Claims Processing” business service. A business event “Claim Filed” triggers the first business process “Accept Claim”, which in turn triggers a business process “Assign Claim”. Depending on the type of claim, either the business process “Adjudicate Standard Claim” or the business interaction “Adjudicate High-Risk Claim” is performed. Adjudication of high-risk claims is a business interaction because, according to the company policy, two people should always be involved in this activity to minimize the risk of fraud. After adjudication, the business processes “Notify Customer” and “Pay Claim” are performed in parallel, and when both have finished, business process “Close Claim” is triggered.
Example 24: Business Behavior Elements
The passive structure aspect of the Business Layer contains the passive structure elements (business objects) that are manipulated by behavior, such as business processes or functions. The passive entities represent the important concepts in which the business thinks about a domain.
In the Business Layer, there are two main types of passive structure elements: business object and representation. Furthermore, a contract, used in the context of a product, is a specialization of a business object.
Figure 64: Business Passive Structure Elements
A business object represents a concept used within a particular business domain.
As explained in Section 3.6, the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a business object typically models an object type (cf. a UML class) of which multiple instances may exist in operations. Only occasionally, business objects represent actual instances of information produced and consumed by behavior elements such as business processes. This is in particular the case for singleton types; i.e., types that have only one instance.
A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes. A business object could be used to represent information assets that are relevant from a business point of view and can be realized by data objects.
Business objects may be accessed (e.g., in the case of information objects, they may be created, read, or written) by a business process, function, business interaction, business event, or business service. A business object may have association, specialization, aggregation, or composition relationships with other business objects. A business object may be realized by a representation or by a data object (or both). The name of a business object should preferably be a noun.
Figure 65: Business Object Notation
A contract represents a formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction.
The contract element may be used to model a contract in the legal sense, but also a more informal agreement associated with a product. It may also be or include an SLA describing an agreement about the functionality and quality of the services that are part of a product. A contract is a specialization of a business object.
The relationships that apply to a business object also apply to a contract. In addition, a contract may have an aggregation relationship with a product. The name of a contract is preferably a noun.
Figure 66: Contract Notation
A representation represents a perceptible form of the information carried by a business object.
Representations (for example, messages or documents) are the perceptible carriers of information that are related to business objects. If relevant, representations can be classified in various ways; for example, in terms of medium (electronic, paper, audio, etc.) or format (HTML, ASCII, PDF, RTF, etc.). A single business object can have a number of different representations. Also, a single representation can realize one or more specific business objects.
A meaning can be associated with a representation that carries this meaning. The name of a representation is preferably a noun.
Figure 67: Representation Notation
The business object “Claim” may be realized by either of the following three physical representations (in different stages of the claims administration process): “Submission Form”, “Claim File Summary”, or “Claim Letter”. All of these representations refer to a representation “Policy Summary”, which realizes a contract “Insurance Policy”.
Example 25: Business Passive Structure Elements
The Business Layer contains one composite element: product. This aggregates or composes services and passive structure elements across the layers of the ArchiMate core language.
Figure 68 shows the applicable part of the metamodel. This crosses layers, as also described in Chapter 12.
Figure 68: Product Metamodel
A product represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
This definition covers both intangible, services-based, or information products that are common in information-intensive organizations, and tangible, physical products. A financial or information product consists of a collection of services, and a contract that specifies the characteristics, rights, and requirements associated with the product. “Buying” a product gives the customer the right to use the associated services.
Generally, the product element is used to specify a product type. The number of product types in an organization is typically relatively stable compared to, for example, the processes that realize or support the products. “Buying” is usually one of the services associated with a product, which results in a new instance of that product (belonging to a specific customer). Similarly, there may be services to modify or destroy a product.
A product may aggregate or compose business services, application services, and technology services, business objects, data objects, and technology objects, as well as a contract. Hence a product may aggregate or compose elements from other layers than the Business Layer.
A value may be associated with a product. The name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., “travel insurance”).
Figure 69: Product Notation
A product “Insurance” consists of a contract “Insurance Policy” and a business service “Customer Service”, which aggregates four other business services: “Application”, “Renewal”, “Claims Processing”, and “Appeal”. An “Auto Insurance” product is a specialization of the generic “Insurance” product, with an additional business service “Drive Well and Save”, and accompanying contract “Drive Well and Save Agreement”.
Example 26: Business Composite Element: Product
Table 6 gives an overview of the Business Layer elements, with their definitions.
Table 6: Business Layer Elements
|
Element |
Description |
Notation |
|
Business actor |
Represents a business entity that is capable of performing behavior. |
|
|
Business role |
Represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event. |
|
|
Business collaboration |
Represents an aggregate of two or more business internal active structure elements that work together to perform collective behavior. |
|
|
Business interface |
Represents a point of access where a business service is made available to the environment. |
|
|
Business process |
Represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services. |
|
|
Business function |
Represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization. |
|
|
Business interaction |
Represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations. |
|
|
Business event |
Represents an organizational state change. |
|
|
Business service |
Represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment. |
|
|
Business object |
Represents a concept used within a particular business domain. |
|
|
Contract |
Represents a formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction. |
|
|
Representation |
Represents a perceptible form of the information carried by a business object. |
|
|
Product |
Represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers. |
|
Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Library as document C197.
