Figure 49 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 49: 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.6.
The Business Layer is typically used (often in conjunction with the strategy elements described in Chapter 7) to model the business architecture of an enterprise, defined by the TOGAF framework [4] as a description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
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 50: Business Internal Active Structure Elements
A business actor is 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 51: Business Actor Notation
A business role is 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 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 (through a composition relationship, which is not shown explicitly in the interface notation). The name of a business role should preferably be a noun.
Figure 52: 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 is 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 are used to describe the internal behavior that takes place within business collaboration. A collaboration is a (possibly temporary) collection of business roles or actors within an organization, which perform collaborative behavior (interactions). Unlike a department, which may also group roles, 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 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 or actors, 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 53: Business Collaboration Notation
A business interface is 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, which is not shown in the standard notation, 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 54: 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 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 22: 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 or value stream 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 55: Business Internal Behavior Elements
A business process represents a sequence of business behaviors that achieves a specific outcome 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 or automated, respectively. The name of a business process should clearly indicate a predefined sequence of actions, 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 56: Business Process Notation
A business function is a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), 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, competences, 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 57: Business Function Notation
A business interaction is a unit of collective business behavior performed by (a collaboration of) two or more business roles.
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 an application collaboration may be assigned to a business interaction. The name of a business interaction should preferably be a verb in the simple present tense.
Figure 58: Business Interaction Notation
A business event is a business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization.
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 59: Business Event Notation
A business service represents an explicitly defined exposed business behavior.
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 is realized by one or more business processes, business functions, or business interactions that are performed by the business roles or business collaborations, respectively. It may access business objects.
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 60: 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 23: 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 61: 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, 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 62: 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 a Service-Level Agreement (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 63: 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 64: Representation Notation
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 24: 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 65 shows the applicable part of the metamodel. This crosses layers, as also described in Chapter 12.
Figure 65: Product
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 66: 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 25: 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 |
A business entity that is capable of performing behavior. |
|
|
Business role |
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 |
An aggregate of two or more business internal active structure elements that work together to perform collective behavior. |
|
|
Business interface |
A point of access where a business service is made available to the environment. |
|
|
Business process |
A sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services. |
|
|
Business function |
A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization. |
|
|
Business interaction |
A unit of collective business behavior performed by (a collaboration of) two or more business roles. |
|
|
Business event |
A business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization. |
|
|
Business service |
An explicitly defined exposed business behavior. |
|
|
Business object |
A concept used within a particular business domain. |
|
|
Contract |
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 |
A perceptible form of the information carried by a business object. |
|
|
Product |
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 ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes. A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C162.
