So far, this chapter has discussed the modelling of different aspects of a busi- ness process. This section looks into the representation of a business process management system capable of controlling the enactment of business processes based on business process models.
Fig. 3.38.Business process management systems architecture model
Figure 3.38shows a high-level business process management systems ar- chitecture model consisting of components and relationships. The architecture model contains the Business Process Environment, aBusiness Process Mod- elling subsystem, aBusiness Process Model Repository, aProcess Engine, and a set of Service Providers. The roles of these constituents of the architecture model are characterized as follows.
• Business Process Modelling: The business process modelling subsystem is used for creating business process models, containing information on activities, their operations, and the structure of the business process. This architecture subsystem can be realized by business process modelling tools.
• Business Process Environment: The business process environment triggers the instantiation and enactment of process instances based on process models.
• Business Process Model Repository: The business process model repository holds business process models that are created by the business process modelling component.
• Process Engine: The process engine is responsible for instantiating and controlling the execution of business processes. It is the core component of a business process management system. This component is triggered by the business process environment. It uses process models to instantiate and control the enactment of process instances. To execute a particular activity instance, it calls entities that act as providers of the required functionality.
In a service-oriented architecture, service providers are called to execute individual services that realize business process activities.
• Service Providers: Service providers host application services that realize business process activities. In the architecture model, service providers represent an abstract entity that subsumes not only Web service providers but also knowledge workers that realize particular activities in business processes. The organizational and technical information that the process engine needs in order to determine and access the service provider is also stored in the business process model repository.
These components of the architectural model control the enactment of process instances. To capture the distributed nature of business process executions, the components and the service providers are represented by agents that com- municate by sending and receiving messages, that is, the agents do not share memory, but are distributed. These messages are sent along the arcs shown in Figure3.38.
Gateways are nodes in a process model that are used to guide the process flow. Therefore, for each gateway node the process engine needs to perform some action. This work that the process engine conducts is represented by a gateway instance, just as the work defined by an activity model is represented by an activity instance. A property of gateway instances is that the pro- cess engine executes them, whereas activity instances are executed by service providers, requiring nonlocal communication.
The events that occur within a process engine during the enactment of a process instance are shown in Figure3.39. The first event that occurs repre- sents the occurrence of the start event in the process model. Let n1 be this event.
The process engine detects that there is a process model deployed for this event. Therefore, a process instance is instantiated. For each activity model in the process model, an activity instance is instantiated; for each gateway node, a gateway instance is created, represented by events i2 throughi6. When the instances are initiated, the AnalyzeOrder activity instance can be started, resulting in event b2. After the termination of this activity instance in event t2, the gateway instance is started, represented by eventb3.
After the gateway instance terminates in eventt3, the process engine can decide which path to take. In the process instance shown, the advanced check activity instance is disregarded and the simple check path is taken. Therefore, theAdvCheck activity instance is skipped, represented by events5. TheSim- pleCheck activity instance is started (eventb4) and later terminates in event
Fig. 3.39.Process model and events of process instance
t4. Finally, the execution of the gateway instance and the occurrence of the final eventn7 terminate the process instance.
The event diagrams introduced are extended to capture agents involved in the enactment of process instances. Each agent is represented by a hor- izontal line, on which the events that occur in this agent are drawn. Time proceeds from left to right. In addition to the events directly associated with the execution of activity instances, the begin and end of a computation and the sending and receipt of a message are also represented by events. Message events of agents represented by directed arcs connecting the send event with the corresponding receive event.
Fig. 3.40.Event diagram of business process execution environment
The business process environment, the process engine, and two service providers are the agents represented in the event diagram. Since the operation of the business process modelling component is not the focus of attention, these components of the architecture model are not represented as agents in the event diagram.
An event diagram of a process instance involving the agents of a business process execution environment is shown in Figure3.40. To ease presentation, initialization events and events associated with gateway instances are omitted in that figure.
When the initial event of the process model occurs in the business pro- cess environment, the process engine instantiates a process instance, including its activity instances. Then, the process engine determines the first activity instance to be executed. A service provider is determined for executing this activity, in the example, Service Provider 1.
The service provider receives this message and starts an AnalyzeOrder activity instance, marked by eventb2. Once that activity instance is completed (t2), the service provider returns a message to the process engine. This message typically contains the return value of that invocation. Using this information and possibly other information, the process engine can evaluate the condition associated with the gateway node. Based on the decision made by the process engine on behalf of the gateway, the AdvCheck activity instance is skipped (skip event s5) and theSimpleCheck activity is started.
In order to realize this process instance, the process engine sends an in- vocation message to the service provider responsible for executing the simple check service. Service Provider 2 receives this message and starts the Sim- pleCheck activity, marked by eventb4.
Once this activity instance completes in event t4, the service provider returns a message to the process engine, which then executes the join gateway node (events omitted). The process instance completes with the final event and by sending the respective message to the business process environment, informing it about the termination of the process instance.
As will be detailed in the next chapter for more complex workflow patterns, control flow patterns restrict the ordering of execution events for activities involved in a business process. For instance, an AnalyzeOrder activity can only be started after the initial event has occurred, and aSimpleCheckactivity can only be started after the exclusive or gateway has completed, and so on.
The execution semantics of a process instance based on a process model is described by restrictions on the events and their ordering during the execution of process instances.
Bibliographical Notes
The business process modelling foundation is based on conceptual modelling techniques that are an important basis of computer science. To structure the
field, object-oriented design techniques are used, most prominently structure diagrams and state transition diagrams of the Unified Modeling Language, introduced in Booch et al. (2005). Event diagrams to illustrate and reason about distributed systems were introduced in Lamport (1978).
Functional breakdown of business functions from top-level functions to operational activities was developed in Porter (1998) in the context of value chains. Based on the early foundation of business process management and the functional breakdown of enterprises, Michael Hammer and James Champy brought process orientation to the agenda, introducing a radical approach to business process reengineering in Hammer and Champy (1993). Davenport focuses specifically on the role of information technology in reengineering work procedures in enterprises, as detailed in Davenport (1992).
In this textbook, we have assumed that the relationships between processes at different levels of abstraction are always hierarchical. This is a simplifying assumption which is useful for the purpose of this textbook. However, in real-world process model collections we also see non-hierarchical relationships that include, for instance, overlaps that do violate the hierarchical structure.
The reader interested in behavioural relationships between process models on different levels of abstraction is referred to Weidlich (2011) and Weidlich et al.
(2011).
In the design of software systems, it is tradition to investigate different aspects independently of each other. This approach is also taken in work- flow management, where different workflow modelling perspectives have been identified in Jablonski (1997). A conceptual model of the core entities in work- flow management is introduced in Weske (2000). Data modelling in relational database systems is based on the Entity Relationship approach introduced by Peter Chen in Chen (1976). Data modelling techniques are also discussed in database design, as, for instance, in Ramakrishnan and Gehrke (2002) and O’Neil and O’Neil (2000).
Organizational modelling in the context of business process management was addressed by Russell et al. (2005) in the context of resource patterns.
Interfaces to software systems are discussed in textbooks on middleware tech- nology, including Henning and Vinoski (1999), where the Interface Definition Language of the Common Request Broker Architecture is discussed. Reijers (2005) discusses trade-offs between generalization and specialization in re- source allocation.
Process Orchestrations
Business process models specify the activities, with their relationships, that are performed within a single organization, that is, they specify process or- chestrations. A process engine acts as a centralized agent to control process orchestrations. Process orchestrations provide a detailed view on the activi- ties of processes and their execution constraints. This chapter is organized as follows.
Section 4.1 introduces control flow patterns, a yardstick in process con- trol flow structures. The patterns will be described both textually and more formally using the event-based approach introduced in the previous chapter.
Section 4.2provides a compact introduction to Petri nets. Different Petri net classes are introduced, including condition event nets, predicate transition nets and, coloured Petri nets. An informal perspective on business process modelling is taken in Section 4.3, where event-driven process chains are dis- cussed. This approach is widely used in the business domain to model business processes from a pragmatic, application-oriented point of view.
Workflow nets are an important Petri net class tailored towards express- ing business process models; workflow nets are discussed in Section4.4. While workflow nets are well suited to modelling business processes and analyz- ing some of their structural properties, workflow nets exhibit a number of limitations. These limitations have led to the development of a new process modelling language, called Yet Another Workflow Language, introduced in Section4.5. Graph-based workflow languages that also take into account data dependencies between process activities are investigated in Section4.6.
In the context of service-oriented architectures and service composition, the Business Process Model and Notation has been proposed as a graphical notation to combine the advantages of a simple and convenient notation and clear semantics. The Business Process Model and Notation is introduced in Section 4.7.
M. Weske,Business Process Management, DOI10.1007/978-3-642-28616-2 4,
©Springer-Verlag Berlin Heidelberg 2012
125