This technological problem is also addressed by enterprise application inte- gration systems, where adapter technology is in place to cope with this issue, as discussed in Chapter 2.
In addition, the granularity with which legacy systems provide functional- ity often does not match the granularity required by the business process. In particular, legacy systems often realize complex subprocesses rather than in- dividual activities in a business process. Sometimes, the processes realized by legacy systems and the modelled business processes are not immediately com- parable. These issues have to be taken into account when software interfaces to existing information systems are developed.
One option to solving this problem is developing software interfaces that make available the functionality provided by legacy systems with a granularity that allows reuse of functionality at a finer level of granularity. The granularity should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture, and documentation, as well as the availability of knowledgeable personnel, the required effort can be very high. If the need for finer-grained granularity and efficient reuse of functionality is sufficiently high, then partial or complete reimplementation can be an option.
Figure 3.39 shows a high-level business process management systems ar- chitecture model consisting of components and relationships. The architecture model contains theBusiness Process Environment, a Business Process Mod- elling subsystem, aBusiness Process Model Repository, aProcess Engine, and a set ofService 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, i.e., the agents do not share memory, but are distributed. These messages are sent along the arcs shown in Figure 3.39.
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 repre- sented by an activity instance. A property of gateway instances is that the process engine executes them, whereas activity instances are executed by ser- vice providers, requiring nonlocal communication.
AnalyzeOrder
SimpleCheck
AdvCheck
N1 N2
N3
N4
N5
N6 N7
e1
Initialization of activity instances and gateway instances
i2 i3 i4 i6 e2 b2 t2 b3 t3 s5 e4 b4 t4 b6 t6 n7
Skipping AdvCheck(n5) n1
Fig. 3.40.Process model and events of process instance
The events that occur within a process engine during the enactment of a process instance are shown in Figure 3.40. The first event that occurs repre- sents the occurrence of the initial event in the process model. Lete1 be this event.
The process engine detects that there is a process model defined 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 eventsi2 throughi6. When the instances are initiated, the AnalyzeOrder activity instance can be started, resulting in eventb2. 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 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.
AnalyzeOrder n1
SimpleCheck Business Process
Environment
Process Engine
Service Provider 1
Service Provider 2
b2
b4 t4
n7
t2
s5
Fig. 3.41.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 Figure 3.41. 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 process environment, the process engine instantiates a process instance, including its activity instances. Then, the process engine determines the first activity in- stance 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 events5) and the SimpleCheck 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 theexclusive 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 Grady Booch (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 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 Defini- tion Language of the Common Request Broker Architecture is discussed. Rei- jers (2005) discusses tradeoffs between generalization and specialization in resource allocation.
Process Orchestrations
Business process models specify the activities, with their relationships, that are performed within a single organization, i.e., they specify process orches- trations. A process engine acts as a centralized agent to control process or- chestrations. Process orchestrations provide a detailed view on the activities 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.2 provides 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 Section 4.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 Section 4.5. Graph-based workflow languages that also take into account data dependencies between process activities are investigated in Section 4.6.
In the context of service-oriented architectures and service composition, the Business Process Modeling Notation has been proposed as a graphical notation to combine the advantages of a simple and convenient notation and clear semantics. The Business Process Modeling Notation is introduced in Section 4.7.