ArchiMate® 1.0 Specification
ArchiMate is a registered trademark of The Open Group

4                       Business Layer

4.1                Business Layer Metamodel

Figure 6 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 of business services.

Figure 6: Business Layer Metamodel

Note:      This figure does not show all permitted relationships: every element in the language can have composition and aggregation relations with elements of the same type; furthermore, there are indirect relationships that can be derived, as explained in Section 8.5.

4.2                Structural Concepts

The 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.

Two types of entities are distinguished:

*         The active entities that 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.

*         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.

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 [8], [12], 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 [13] 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.

4.2.1               Business Actor

A business actor is defined as an organizational entity capable of (actively) performing behavior.

A business actor performs the behavior assigned to (one or more) business roles. 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 7: 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

4.2.2               Business Role

A business role is defined as a named specific behavior of a business actor participating in a particular context.

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 relation, which is not shown explicitly in the interface notation). The name of a business role should preferably be a noun.

Figure 8: Business Role Notation

Example

In the model below, two business roles (Luggage insurance seller and Travel insurance seller) are involved in a collaboration that results in a Combined insurance selling service. The left hand illustrates the delivery of a Luggage insurance selling service via a business interface. The right hand shows how a business process, Take out insurance, is assigned to the Travel insurance seller and realizes the Travel insurance selling service.

Example 2: Business Role

4.2.3               Business Collaboration

Business collaboration is defined as a (temporary) configuration of two or more business roles resulting in specific collective behavior in a particular context.

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) collective of roles within an organization which perform collaborative behavior (inter­actions). 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 9: Business Collaboration Notation

Example

The model in the model below illustrates a possible use of the collaboration concept. In this example, selling an insurance product involves the Sales department and a department specialized in that particular type of insurance. The example also shows that one role, in this case the Sales department, can participate in more than one collaboration.

Example 3: Business Collaboration

4.2.4               Business Interface

A business interface declares how a business role can connect with its environment.

A business interface specifies how the functionality of a business role can be used by other business roles (provided interface), or which functionality the business roles requires from its environment (required interface). A business interface exposes a business service to the environment. The same business service may be exposed through different interfaces.

A business interface may be part of a business role through a composition relation, 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 10: 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

4.2.5               Business Object

A business object is defined as a unit of information that has relevance from a business perspective.

Business objects represent the important “informational” or “conceptual” elements in which the business thinks about a domain. Generally, a business object is used to model an object type (cf. a UML class), of which several instances may exist within the organization. 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 may be accessed (e.g., created, read, written) by a business process, function, a business interaction, a business event, or a 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 11: 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 5: Business Object

4.3                Behavioral Concepts

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” [14]. A business function offers functionality that may be useful for one or more business processes. It groups behavior based on, for example, required skills, capabilities, resources, (application) support, etc. Other methods sometimes call this a business capability. 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 [13], 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 [13] and the “initial state” and “final state” concepts as used in, for example, UML activity diagrams. How­ever, 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.

4.3.1               Business Process

A business process is defined as a unit of internal behavior or collection of causally-related units of internal behavior intended to produce a defined set of products and 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 more than two business roles are (interactively) involved, only one business role is involved with a business process. However, a (complex) business process may consist of sub-processes assigned to different business roles.

There is a potential many-to-many relation 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”.

Figure 12: 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. Also, during the take out process, the Process request sub-process makes use of an application service Transaction entry.

Example 6: Business Process

4.3.2               Business Function

A business function is defined as a unit of internal behavior that groups behavior according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization.

A business function describes 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”.

There is a potential many-to-many relation 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. 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”.

Figure 13: Business Function Notation

Example

The model below illustrates the use of business functions, as well as the relation 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 contact function uses or manipulates the Customer info object. Also, the Financial settlement function makes use of a Billing application service and realizes a Collecting premium business service.

Example 7: Business Function

4.3.3               Business Interaction

Business interaction is defined as a unit of behavior performed as 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 multiple roles in collaboration.

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 14: 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

4.3.4               Business Event

A business event is defined as something that happens (internally or externally) and influences behavior (business process, business function, business interaction).

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 15: 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

4.3.5               Business Service

A business service is defined as the externally visible (“logical”) functionality, which is meaningful to the environment and is realized by business behavior (business process, business function, or business interaction).

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.

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 16: 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) that is used by the insurer. Each business service should be of value to its environment, which may or may not be explicitly modeled. The value of the Travel insurance selling service to an external customer is that the customer is insured.

Example 10: Business Service

4.4                Informational Concepts

In contrast to the structural and behavioral concepts, which are mainly concerned with the operational perspective on an enterprise, the informational concepts focus on what we could call the “intentional” perspective. They provide a way to link the operational side of an organization to the business goals, and to the products that an organization offers to its customers. We also classify the product concept itself, together with the related contract concept, as informational concepts.

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 [10], the communicational aspect plays a central role in the context of business transactions.

A representation is the perceptible form of the information carried by a business object, such as a document. As such, it can be seen as the realization of the associated business object. If relevant, representations can be classified in various ways; for example, in terms of medium (e.g., electronic, paper, audio) or format (e.g., HTML, PDF, plain text, bar chart).

A meaning is the contribution of the representation of a business object to the knowledge or expertise of some actor, given a particular context. In other words, meaning represents the informative value of a business object for a user of such an object. It is through a certain interpretation of a representation of the object that meaning is being offered to a certain user or to a certain category of users. A meaning can very well be a reformulation or transformation of parts of the object representation in such a way that the role of the meaning is immediately clear within the user's world, but essentially lies in interpretation by individuals, in context.

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.

4.4.1               Representation

Representation is defined as the 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, PFD, RTF, etc.). A single business object can have a number of different representations, but a representation always belongs to one specific business object.

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 17: 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 11: Representation

4.4.2               Meaning

Meaning is defined as the knowledge or expertise present in the representation of a business object, given a particular context.

A meaning is the representation-related counterpart of a value: it represents the functionality of a 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 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 18: 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 12: Meaning

4.4.3               Value

Value is defined as that which makes some party appreciate a service or product, possibly in relation to providing it, but more typically to acquiring it.

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 19: 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 13: Value

4.4.4               Product

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.

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,[2] 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 20: 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 14: Product

4.4.5               Contract

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 21: 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 15: Contract

4.5                Summary of Business Layer Concepts

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

A named specific behavior of a business actor participating in a particular context.

Business collaboration

A (temporary) configuration of two or more business roles resulting in specific collective behavior in a particular context.

Business interface

Declares how a business role can connect with its environment.

Business object

A unit of information that has relevance from a business perspective.

Business process

A unit of internal behavior or collection of causally related units of internal behavior intended to produce a defined set of products and services.

Business function

A unit of internal behavior that groups behavior according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization.

Business interaction

A unit of behavior performed as a collaboration of two or more business roles.

Business event

Something that happens (internally or externally) and influences behavior.

Business service

An externally visible unit of functionality, which is meaningful to the environment and is provided by a business role.

Representation

The perceptible form of the information carried by a business object.

Meaning

The knowledge or expertise present in the representation of a business object, given a particular context.

Value

That which makes some party appreciate a service or product, possibly in relation to providing it, but more typically to acquiring it.

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.



return to top of page


Downloads

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 C091.


Copyright © 2008-2009 The Open Group, All Rights Reserved
ArchiMate is a registered trademark of The Open Group.