Figure 9 shows the metamodel of business layer concepts. The metamodel follows the structure of the generic metamodel introduced in the previous chapter. However, this layer also includes a number of additional informational concepts which are relevant in the business domain: a product and associated contract, the meaning of business objects, and the value of products and business services.
Figure 9: Business Layer Metamodel
Note: This figure does not show all permitted relationships: every concept in the language can have composition, aggregation, and specialization relationships with concepts of the same type; furthermore, there are indirect relationships that can be derived, as explained in Section 7.5.
The active structure aspect at 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 concept of business collaboration has been introduced. Business collaborations have been inspired by collaborations as defined in the UML 2.0 standard [7], [10], although the UML collaborations apply to components in the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to the “community” concept as defined in the RM-ODP Enterprise Language [6], as well as to the “interaction point” concept, defined in Amber [11] as the place where interactions occur.
The concept of business interfaces is introduced to explicitly model the (logical or physical) locations 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 concept.
A business actor is defined as an organizational entity that is capable of performing behavior.
A business actor performs the behavior assigned to (one or more) business roles. A business actor is an organizational entity as opposed to a technical entity; i.e., it belongs to the business layer. Actors may, however, include entities outside the actual enterprise; e.g., customers and partners. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles. The name of a business actor should preferably be a noun.
Figure 10: Business Actor Notation
Example
The model below illustrates the use of business actors. The company ArchiSurance is modeled as a business actor that is composed of two departments. The Travel insurance seller role is assigned to the travel department. In this role, the travel department performs the Take out insurance process, which offers a service that is accessible via the business interface assigned to this role.
Example 1: Business Actor
A business role is defined as the responsibility for performing specific behavior, to which an actor can be assigned.
Business processes or business functions are assigned to a single business role with certain responsibilities or skills. A business actor that is assigned to a business role ultimately performs the corresponding behavior. 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 a business role. A business interface or an application interface may be used by 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 11: Business Role Notation
Example
In the model below, the business role Insurance Seller is fulfilled by the Insurance Department actor and has telephone as a provided interface. The business role Insurance Buyer is fulfilled by the Customer actor, and has telephone as a required interface.
Example 2: Business Role
Business collaboration is defined as an aggregate of two or more business roles that work together to perform collective behavior.
A business process or function may be interpreted as the internal behavior assigned to 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 roles within an organization which perform collaborative behavior (interactions). Unlike a department, which may also group roles, a business collaboration does not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles. However, a business collaboration can be regarded as a kind of “virtual role”, hence its designation as a specialization of role. It is especially useful in modeling B2B interactions between different organizations.
A business collaboration may be composed of a number of business roles, and may be assigned to one or more business interactions. A business interface or an application interface may be used by a business collaboration, while a business collaboration may have business interfaces (through composition). The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.
Figure 12: Business Collaboration Notation
Example
The model below illustrates a possible use of the collaboration concept. In this example, selling an insurance product involves the Sales department, fulfilling a sales support role, and a department specialized in that particular type of insurance, fulfilling an insurance seller role. The example also shows that one role, in this case Sales support, can participate in more than one collaboration.
Example 3: Business Collaboration
A business interface is defined as 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 (provided interface), or expects functionality from other business services (required interface). 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 through a composition relationship, which is not shown in the standard notation, and a business interface may be used by 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 13: Business Interface Notation
Example
In the model below, the business services provided by the Luggage insurance seller and its collaboration with the Medical insurance seller are exposed by means of a web form and call center business interface, respectively.
Example 4: Business Interface
A location is defined as a conceptual point or extent in space.
The location concept is used to model the distribution of structural elements such as business actors, application components, and devices. This is modeled by means of an assignment relationship from location to structural element. Indirectly, a location can also be assigned to a behavior element, to indicate where the behavior is performed.
Figure 14: Location Notation
Example
The model below shows that the departments of an insurance company are distributed over different locations. The Legal and Finance departments are centralized at the main office, and there are claims handling departments at various local offices throughout the country.
Example 5: Location
Based on service orientation, a crucial design decision for the behavioral part of our metamodel is the distinction between “external” and “internal” behavior of an organization.
The externally visible behavior is modeled by the concept 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 concepts associated with these views, business process and business function, are defined. Both concepts 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” [12]. 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 [11], which is an atomic unit of collaborative behavior, our 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” concept is similar to the “trigger” concept in Amber [11] and the “initial state” and “final state” concepts as used in, for example, UML activity diagrams. However, our 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.
A business process is defined as a behavior element that groups behavior based on an ordering of activities. It is intended to produce 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”.
In comparison to a business interaction, in which a collaboration of two or more business roles are (interactively) involved, at a given level of granularity only one business role is involved with a business process. However, a complex business process may be an aggregation of other, finer-grained processes, each of which may be assigned to finer-grained roles that are aggregated by roles that are aggregated by the original role.
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 or an application component may be assigned to a business process to perform this process manually or automated, respectively. The name of a business process should preferably be a verb in the simple present tense; e.g., “handle claim”.
In an ArchiMate model, the existence of business processes is depicted. It does not, however, list the flow of activities in detail. During business process modeling, a business process can be expanded using a business process design language; e.g., BPMN [20].
Figure 15: Business Process Notation
Example
The model below illustrates the use of business processes and its relation with other concepts. The Take out insurance process is composed of three sub-processes. For clarity, the sub-processes are drawn in the overall process (structuring). Each sub-process triggers the next sub-process. The event Request for Insurance triggers the first sub-process. A particular role, in this case an insurance seller, is assigned to perform the required work. The process itself realizes an Insurance selling service. The Receive request sub-process uses the business object Customer info.
Example 6: Business Process
A business function is defined as a behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences).
Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process group’s behavior is 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 use (internal) business services or application services. A business role or an application component may be assigned to a business function. The name of a business function should preferably be a verb ending with “-ing”; e.g., “claims processing”, or a noun ending in “-ion” or “-ment”; e.g., “administration”.
Figure 16: Business Function Notation
Example
The model below illustrates the use of business functions, as well as the relationship between business functions and business processes. The three business functions group a number of business sub-processes. The business process, initiated by a business event, involves sub-processes from different business functions. The Insurer role is assigned to each of the business functions. Moreover, business functions may access business objects; in this case, the Customer handling function uses or manipulates the Customer information object. Also, the Financial handling function makes use of a Billing application service and realizes a Premium collection business service.
Example 7: Business Function
A business interaction is defined as a behavior element that describes the behavior of a business collaboration.
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 17: Business Interaction Notation
Example
In the model below, a business interaction is triggered by a request. The business interaction Take out combined insurance is performed as collaboration between the travel and luggage insurance seller. The business interaction needs the Policy info business object, and realizes the (external) business service Combined insurance selling. As part of the business interaction, the Prepare travel policy and Prepare luggage policy are triggered. The Travel insurance seller and Luggage insurance seller perform these processes separately.
Example 8: Business Interaction
A business event is defined as something that happens (internally or externally) and influences behavior.
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. A business event is most commonly used to model something that triggers behavior, but other types of events are also conceivable; e.g., an event that interrupts a process. 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 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 18: Business Event Notation
Example
In the model below, the Request insurance event triggers the Take out insurance process. A business object containing the Customer info accompanies the request. In order to persuade the customer to purchase more insurance products, a triggering event is raised in the Receive request process. This triggers the Send product portfolio to customer process.
Example 9: Business Event
A business service is defined as a service that fulfills a business need for a customer (internal or external to the organization).
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 functionality 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 be used by a business process, business function, or business interaction. A business process, business function, or business interaction may realize a business service. A business interface or application 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 19: Business Service Notation
Example
In the model below, external and internal business services are distinguished. The Basic administration function acts as a shared service center. The take out business processes corresponding with the travel and luggage insurance use the (internal) business services that are provided by the Basic administration function. Both business processes realize an (external) business service. The insurance selling service is accessible via a business interface (e.g., web form) of the insurance seller. Each business service should be of value to the user(s) of the service (in this example, the insurance buyer role). This value may be explicitly modeled, if appropriate. The value of the Travel insurance selling service to an external customer (the insurance buyer) is that the customer is insured.
Example 10: Business Service
In the passive structure aspect at the business layer, we model the passive entities (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 addition to the active structure concepts, the behavioral concepts, and the business object, which are mainly concerned with the operational perspective on an enterprise, the passive structure aspect at the business layer also defines a number of informational concepts that focus on what we could call the “intentional” perspective.
Information is fundamentally related to communication. Information always serves a particular purpose, which is tightly connected to some communicational goal. As communication always involves a static part (the “message”) and a dynamic part (the communication action itself), the communicational goals may have a link to both our “meaning” concept and our “value” concept. Also, in speech act-based approaches to business modeling, such as DEMO [9], the communicational aspect plays a central role in the context of business transactions.
For the complete description of a meaning, the following two elements are needed, in addition to the representations (and, indirectly, business objects) with which the meaning is associated:
• Some sort of meaning description: A meaning description is not equal to the representation causing the meaning: it is a specialized description that aims to clarify or stipulate a meaning. Natural language may be used for this, but also formal languages or diagrams. Typical examples of meaning descriptions are definitions, ontologies, paraphrases, subject descriptions, and tables of content. Meaning descriptions may draw from or refer to additional meaning description sources; for example, dictionaries. Importantly, meaning descriptions do not necessarily have to describe meaning in detail. The level of detail depends on the types of analysis required. It is quite possible that a very rough meaning description is good enough to capture at architecture level the sort of interpretations a business object conveys. Detailed meaning description can only in a limited number of cases be made very precise; in most cases, interpretation depends on the general language and knowledge of specific actors, which normally remains largely implicit.
• A description of the context(s) in which the meaning is conveyed: A context description covers the situation in which the interpretation takes place. The most important elements of such a context are the actors sending and receiving the business object, the time and place of communication and the environment in which this happens. Often, a context can be briefly described in terms of some business domain.
We see a (financial or information) product as of a collection of services, together with a contract that specifies the characteristics, rights, and requirements associated with the product. This “package” is offered as a whole to (internal or external) customers.
We define a contract as a formal or informal specification of agreement that specifies the rights and obligations associated with a product. The value of a product or service is that which makes some party appreciate it, possibly in relation to providing it, but more typically to acquiring it.
A business object is defined as a passive element that has relevance from a business perspective.
Business objects represent the important “informational” or “conceptual” elements in which the business thinks about a domain. At the enterprise architecture abstraction level, it is more common to model types rather than instances. In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. Sometimes, business objects represent actual instances of information produced and consumed by behavior elements such as business processes. 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, which are most common in the application domains in which the ArchiMate language is applied, 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 20: Business Object Notation
Example
The model below shows a business object Invoice, which aggregates (multiple) business objects Invoice line. Two possible realizations of this business object exist: an Electronic invoice (data object) and a Paper invoice (representation). The business process Create invoice creates the invoice and the invoice lines, while the business process Send invoice accesses the business object Invoice.
Example 11: Business Object
A representation is defined as 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 representation may realize one or more business objects. A meaning can be associated with a representation that carries this meaning. The name of a representation is preferably a noun.
Figure 21: Representation Notation
Example
The model below shows the business object Request for insurance, which is realized (represented) by a (physical) request form. The Invoice business object is realized (represented) by a paper bill.
Example 12: Representation
Meaning is defined as the knowledge or expertise present in a business object or its representation, given a particular context.
A meaning is the information-related counterpart of a value: it represents the intention of a business object or representation (for example, a document, message; the representations related to a business object). It is a description that expresses the intent of a representation; i.e., how it informs the external user.
It is possible that different users view the informative functionality of a business object or representation differently. For example, what may be a “registration confirmation” for a client could be a “client mutation” for a CRM department (assuming for the sake of argument that it is modeled as an external user). Also, various different representations may carry essentially the same meaning. For example, various different documents (a web document, a filled-in paper form, a “client contact” report from the call center) may essentially carry the same meaning.
A meaning can be associated with a representation that carries this meaning. The name of a meaning should preferably be a noun or noun phrase.
Figure 22: Meaning Notation
Example
The model below shows an Insurance policy document that is the representation of an Insurance policy, which is a business object. The meaning related to this document is the Insurance policy notification, which consists of a Policy explanation, an Insurance registration, and a Coverage description.
Example 13: Meaning
Value is defined as the relative worth, utility, or importance of a business service or product.
Value may apply to what a party gets by selling or making available some product or service, or it may apply to what a party gets by buying or obtaining access to it. Value is often expressed in terms of money, but it has long since been recognized that non-monetary value is also essential to business; for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though value can hold internally for some system or organizational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship.
A value can be associated with business services and, indirectly, with the products they are part of, and the roles or actors that use them. Although the name of a value can be expressed in many different ways (including amounts, objects), where the “functional” value of a service is concerned it is recommended to try and express it as an action or state that can be performed or reached as a result of the corresponding service being available.
Figure 23: Value Notation
Example
In the model below, the value Be Insured is the highest-level expression of what the service Provide Insurance enables the client to do; three “sub-values” are distinguished that are part of what Be Insured amounts to.
Example 14: Value
A product is defined as a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
This definition describes financial, services-based, or information products that are common in information-intensive organizations, rather than 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 concept 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 business services or application services,[3] as well as a contract. 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 24: Product Notation
Example
In the model below, a bank offers the product Telebanking account to its customers. Opening an account as well as application support (i.e., helpdesk and the like), are modeled as business services realized by the Customer relations department. As part of the product, the customer can make use of a banking service which offers application services realized by the Telebanking application, such as electronic Money transfer and requesting Account status.
Example 15: Product
A contract is defined as a formal or informal specification of an agreement that specifies the rights and obligations associated with a product.
The contract concept 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 25: Contract Notation
Example
The model below shows a Telebanking contract associated with the product Telebanking account. The contract consists of two parts (subcontracts): the Service Conditions and a Service Level Agreement.
Example 16: Contract
Table 1 gives an overview of the concepts at the business layer, with their definitions.
Table 1: Business Layer Concepts
|
Concept |
Description |
Notation |
|
Business actor |
An organizational entity that is capable of performing behavior. |
|
|
Business role |
The responsibility for performing specific behavior, to which an actor can be assigned. |
|
|
Business collaboration |
An aggregate of two or more business roles that work together to perform collective behavior. |
|
|
Business interface |
A point of access where a business service is made available to the environment. |
|
|
Location |
A conceptual point or extent in space. |
|
|
Business process |
A behavior element that groups behavior based on an ordering of activities. It is intended to produce a defined set of products or business services. |
|
|
Business function |
A behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences). |
|
|
Business interaction |
A behavior element that describes the behavior of a business collaboration. |
|
|
Business event |
Something that happens (internally or externally) and influences behavior. |
|
|
Business service |
A service that fulfills a business need for a customer (internal or external to the organization). |
|
|
Business object |
A passive element that has relevance from a business perspective. |
|
|
Representation |
A perceptible form of the information carried by a business object. |
|
|
Meaning |
The knowledge or expertise present in a business object or its representation, given a particular context. |
|
|
Value |
The relative worth, utility, or importance of a business service or product. |
|
|
Product |
A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers. |
|
|
Contract |
A formal or informal specification of agreement that specifies the rights and obligations associated with a product. |
|
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 (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C13L.
