An Integrated Notation for Business Process Models

Introduction

A business process is a standard way of organizing work in a business context. It consists of a number of tasks designed to produce a product or service (Rummler & Brache, 1995). Business processes cross functional boundaries in that they involve members of different departments; common examples are developing a new product, ordering goods from a supplier, and processing and paying an insurance claim (Davenport & Short, 1990).

Over the last years, various notations have been proposed to define business processes; they differ in the viewpoint adopted (Bruno, 2011). Probably, the most popular viewpoint is the activity-centric one, whose standard representative is BPMN (Business Process Model and Notation) (OMG-BPMN, 2011). It considers business processes essentially as orchestrators of operational activities, which encompass human tasks and automated ones (Weske, 2007). The former are carried out by the participants in the process with the help of graphical interfaces, while the latter are implemented by services. Orchestration is achieved by means of control-flow elements which enforce rigid precedence relationships: a business process is like a master distributing the work to the participants in the process.

In recent years, the notion of Process-Aware Information System (Dumas, van der Aalst, & ter Hofstede, 2005), which advocates a tighter integration between the areas of information systems and business processes, has brought about a shift of interest from the activity-centric perspective to the artifact-centric one. The latter emphasizes the identification of the key business entities (called artifacts) and of their life cycles, which show how the artifacts evolve over time through the execution of the tasks. The major benefit is the right level of granularity, which facilitates communication among the stakeholders and helps them focus on the primary purposes of the business (Chao et al., 2009). In this chapter, terms artifact and business entity (or simply entity) will be used interchangeably.

The major criticism raised against the activity-centric approach is the emphasis placed on the tasks and the control-flow elements, while the artifacts are not considered as first-class citizens. As a matter of fact, the data flow in the activity-centric approach is based on process variables and there is no automatic mapping between artifacts and process variables. Moreover, this perspective seems to be more suitable for automated processes than for human-centric ones, as it lacks an adequate representation of the situations in which the choice among different courses of action depends on a human decision. The artifact-centric approach has the potential for coping with such issues owing to the emphasis placed on the artifacts on which human decisions are grounded. This approach, however, is not free from critical aspects; in particular, the handling of tasks operating on two or more artifacts calls for some form of coordination of their life cycles.

In order to overcome the above mentioned issues, this chapter proposes a notation, named ARTS (ARtifacts and TAsks), which integrates tasks and artifacts and emphasizes human choices. In a nutshell, ARTS follows the case handling approach (van der Aalst, Weske, & Grünbauer, 2005) and therefore the goal of a business process is to define the life cycle of a specific entity type, called primary entity type. When a primary entity is generated, a new instance of the process governing its life cycle is started, and the primary entity follows the path which is determined by the tasks defined in the process. However, a process is not required to manage a single entity in that other entities may be produced during its execution; these entities are linked to the primary entity and are called subordinate entities. It often happens that subordinate entities have their own life cycle and then the process may be in charge of a number of life cycles.