Product-Based Workﬂow Design for Monitoring of ......Product-Based Workﬂow Design for Monitoring of Collaborative Business Processes Marco Comuzzi and Irene T.P. Vanderfeesten

Product-Based Workflow Design for Monitoring

of Collaborative Business Processes

Marco Comuzzi and Irene T.P. Vanderfeesten

School of Industrial Engineering, Eindhoven University of TechnologyP.O. Box 513, 5600MB Eindhoven, The Netherlands

{m.comuzzi,i.t.p.vanderfeesten}@tue.nl

Abstract. Monitoring of cross-organizational processes requires the def-inition and implementation of monitoring processes that can deliver theright information to the right party in the collaboration. Monitoringprocesses should account for the temporal and aggregation dependenciesamong the monitoring information made available by the set of collabo-rating parties. We solve the problem of designing monitoring processes incollaborative settings using Product-Based Workflow Design (PBWD).We first discuss a methodology to apply PBWD in this context and thenpropose an architecture to implement the methodology using a service-oriented approach.

Keywords: Monitoring, business process design, cross-organizationalprocesses.

1 Introduction

Continuous monitoring of a business process can be defined as the set of method-ology and tools to collect and disseminate relevant information about the processexecution to interested stakeholders simultaneously with, or within a reasonablyshort period after, the occurrence of relevant events in the process [6]. Continu-ous monitoring has straightforward benefits, such as the opportunity for processproviders to detect anomalies in (almost) real time and apply control actionson-the-fly.

Research on (continuous) monitoring in cross-organizational processes hasusually taken an information-centric perspective, focusing on the definition ofmonitoring requirements for the collaborating parties and their evolution [6,11],the design of architectures and tools to capture monitoring information [17], thedetection of contract violations, given the available monitoring information [3], orthe verification of the compliance of execution logs to a process specification [18].

Although the information-centric view can suffice for intra-organizational pro-cess monitoring, where all monitoring information is produced in a given busi-ness domain, in cross-organizational settings researchers stress the importanceof process- and communication-oriented mechanisms to transmit relevant infor-mation to interested parties across the collaborative network [7,11]. In otherwords, once the monitoring information is captured and made available by the

H. Mouratidis and C. Rolland (Eds.): CAiSE 2011, LNCS 6741, pp. 154–168, 2011.c© Springer-Verlag Berlin Heidelberg 2011

Product-Based Workflow Design 155

Factor(bank)4Contractor 1

Business process1.Consumer places an order with supplier2.Supplier requests financing with factor (selling invoices)3 Factor verifies credit rating of consumer7

Supplier(hub)

Consumer1

2 3

56

3.Factor verifies credit rating of consumer4.Factor pays the supplier5.Supplier and contractors produce goods6.Supplier sends goods and invoices to consumer7.Consumer pays Factor (e.g. after 30 days)

Contractor 2

Fig. 1. Factoring example

collaborating parties, a process must be built to allow a specific party to retrieve(or be delivered) the monitoring information in the right way. Such monitoringprocess should account for the temporal and aggregation dependencies amongmonitoring information.

Let us consider the running example of a business network for factoring inthe manufacturing industry (see Fig. 1), constituted by a supplier, a set of con-tractors (two in our case), a consumer, and a factor. The supplier, in particular,acts as the coordinating hub of the set of contractors, which execute the processrequired to deliver the product ordered by the consumer. Factoring is a financialtransaction whereby a business (supplier) sells its account receivables (invoices)to a third party financial institution (factor) in exchange for immediate payment.Factoring allows consumers to obtain financing at an interest rate, i.e. the oneprovided by the factor, lower than the one they could obtain directly from thesupplier [10]. In this context, continuous monitoring may help reducing the risksassociated to the collaboration, e.g. the risk that the supplier will not deliverthe goods as promised or the risk that the consumer will not be able to pay.Therefore, continuous monitoring may help to further increase the benefits thatthe involved parties achieve through the collaboration.

In this scenario, the supplier wants to monitor when the consumer has madethe payment to the factor and when the factor has received such payment. Ifthe consumer does not pay, in fact, the supplier should not agree to furthertransactions in the future involving the same consumer. Note that (i) paymentconfirmations are not conveyed to the supplier in the process depicted in Fig. 1and (ii) a temporal dependency exists between monitoring information, i.e. if thesupplier checks the factor acknowledgment of the payment without knowing if theconsumer has actually sent out the payment, he or she may have an inconsistentview on the process (and may take wrong corrective actions accordingly).

The factor, similarly, wants to monitor the progress and quality of the processon the supplier side to reduce its own risk. The consumer, in fact, may not besatisfied with the goods, e.g. because of late delivery or poor quality, and, as aconsequence, may not be willing to pay the factor according to established terms.This information may be delivered either by the supplier, or being reconstructedthrough more detailed progress information made available by the contractorsand aggregated correctly. Again, note that progress information is not conveyedto the factor in the business collaboration depicted in Fig. 1.

The latter example also shows that there could be different alternatives for aparty to obtain the required monitoring information and each alternative may

156 M. Comuzzi and I.T.P. Vanderfeesten

be characterized in non-functional terms, e.g. in terms of cost and quality. Forinstance, progress information made available by contractors may be of higherquality and cost, whereas the supplier may only have limited visibility on theprogress of an order once this is outsourced to contractors, and therefore mayprovide such information at a cheaper price.

In this paper, we propose a methodology to design monitoring processes in col-laborative business settings. The methodology considers as input the monitoringinformation made available by the collaborating parties and builds monitoringprocesses embedding temporal and aggregation dependencies among monitoringinformation. Moreover, monitoring information in our methodology can be de-scribed also in non-functional terms, e.g. by cost, quality, and availability. Amongthe set of possible alternatives, the proposed methodology allows the selectionof the monitoring process satisfying also the party non-functional requirements,e.g. the minimum cost monitoring process or the highest quality process, givena budget constraint.

The design of the monitoring process for cross-organizational business pro-cesses is framed as a PBWD (Product-Based Workflow Design, [16,20,22]) prob-lem. PBWD is an analytical method for automatically deriving business processspecifications from the set of information products involved in the process andtheir dependencies. In the monitoring of collaborative processes, informationproducts are represented by the monitoring information made available by theactors involved in the collaboration.

The paper is organised as follows. Related work is discussed in Section 2, whileSection 3 introduces the background on PBWD and explains its novel applica-tion to the problem of cross-organizational process monitoring. The architectureto integrate the PBWD design of monitoring processes in a service-oriented en-vironment is presented in Section 4, while conclusions are eventually drawn inSection 5.

2 Related Work

Monitoring of cross-organizational business processes has been investigated, froma requirements engineering perspective, in [7] and [11]. In order to achievea successful collaboration, both papers stress the importance of process- andcommunication-oriented mechanisms to transmit relevant information to inter-ested parties across the network. Similarly, [5] considers the need to define ex-ternal information requirements, i.e. information required by a consumer fromits providers to correctly monitor and enforce a multiparty contract.

From the design and implementation perspectives, the CrossFlow [8] andCrossWork [9] projects consider architectural support for cross-organizationalbusiness processes. Both projects investigate issues such as the design of flexiblearchitecture to support monitoring [9] and the definition of specific monitor-ing points in electronic contracts [8]. Monitoring, however, is still consideredinformation-centric, i.e. the dependency among monitoring information prod-ucts produced by various sources or the aggregation of monitoring informationfrom several parties are not considered.


Research on Web service-based business processes has also extensively inves-tigated the issue of monitoring. Web service-based processes are intrinsicallycross-organizational, since each orchestrated Web service can in principle be ex-posed by a different organization. In this context, we can distinguish betweenintrusive and non-intrusive monitoring [2,13]. The former involves the interleav-ing of service and monitoring activities at runtime, whereas the latter separatesthe business from the monitoring logic, since information relevant for monitoringcan be captured non-intrusively while a process is executing, e.g. interceptingservice operation calls and responses or from the log of the process engine [13].Cross-organizational settings require non-intrusive monitoring, since it wouldnot be feasible to implement a different instrumentation to satisfy the moni-toring requirements of each different party with which an organization has tointeract. Furthermore, while the aforementioned approaches only consider themonitoring of performance variables, such as response time and availability, orsimple conditions describing the behavior of a service, in this paper we take abusiness perspective, since PBWD considers business-related information thatis deemed relevant by the user of a process.

The innovation of the approach presented in this paper concerns also theaggregation, according to user-specific dependencies, of monitoring informationto design a customized monitoring process. Web service-based process monitor-ing considers also aggregation of monitoring information from multiple sources[2,13]. However, monitoring information, such as the timestamps of service callsor process variables, are meaningful only at a technical level, and they requirefurther translation before becoming meaningful to and, therefore, relevant for aprocess user [12]. PBWD considers only informational products meaningful ata business level and, therefore, enables us to design monitoring processes usinginformational products that do not need translation.

3 Using PBWD for Collaborative Process Monitoring

This section introduces some background on the PBWD approach and showshow PBWD can be used to generate monitoring processes. PBWD is a scientifi-cally grounded method for business process (re)design. The focus of this methodis on the design of processes that deliver informational products, the so-calledworkflow processes. The PBWD methodology takes the structure of the informa-tional product, which is described in a Product Data Model (PDM), as a startingpoint to derive a process model. Informational products are, for instance, a deci-sion on an insurance claim, the allocation of a subsidy, or the approval of a loan.Based on the input data provided by the client or retrieved from other systems,the end (informational) product is constructed step-by-step. In each step newinformation is produced based on the specific data available for the case.

Over recent years, PBWD has shown to be a successful business process(re)design method [15]. For instance, the annual reporting process for mutualfunds at a large Dutch bank was successfully redesigned using PBWD. The in-sights in the informational product, achieved by PBWD, led to a 50% decreasein throughput time [20].


1. Monitoringrequirementselicitation

3. Serviceoriented

implementation

2.1 DesignProduct DataModel (PDM)

2.2 Selectoptimal path

2.3 Generateprocessmodel forl d h

2. PBWD design of monitoring process

elicitation implementationModel (PDM) selected path

Fig. 2. Methodology for PBWD of monitoring processes

PBWD is particularly well-suited for achieving a process-centric view on mon-itoring in cross-organizational processes because of two reasons:

– Clean-sheet approach to process design: PBWD builds process models di-rectly from the specification of the informational products involved in theprocess and their dependencies. This approach is a perfect fit for monitoringcross-organizational business processes, since the monitoring process mustbe built from the monitoring information made available by the collaborat-ing parties. Note that, in highly dynamic collaborations, partner selectionis late-bound, and collaborating parties are selected dynamically as they be-come available [9];

– Cost- and quality-aware process design: PDMs, i.e. available informationalproducts and their dependencies, can be enriched with information aboutthe cost of producing an information product or its quality for the interestedstakeholders. PBWD can then derive various process specifications for thesame PDM that differ for their overall costs and quality. The possibility totune the costs and the quality of the process is an essential feature to derivethe most suitable monitoring process for a given stakeholder. When a processis not mission critical, for instance, the monitoring process can be designedby maximizing its quality given a budget constraint, whereas in contextscharacterized by severe quality requirements, for instance in highly regu-lated industries, such as healthcare, monitoring processes can be designedby minimizing the monitoring costs while guaranteeing a given required levelof quality.

Fig. 2 shows the steps of the methodology for creating monitoring processes usingPBWD for a specific stakeholder in the collaboration. After having analyzedthe monitoring requirements of the stakeholder, the application of PBWD tomonitoring processes design involves three steps.

First, the Product Data Model (PDM) of the stakeholder is designed. ThePDM, which is the starting point for the PBWD method, is similar to the conceptof a Bill-of-Materials (BoM) [14] used in manufacturing environments to manageand control production processes. Since (digital) information is more flexiblethan physical products, however, the PDM contains more complex structuresthan a BoM, such as re-use of information or alternative paths to produce aninformation element.

Second, among the set of all paths in the PDM that can lead to the correctproduction of monitoring information, the path which satisfies the non-functionalrequirements of the stakeholder is selected. As discussed later, we consider thecost, (data) quality, and availability dimensions to specify non-functional re-quirements.


In the third step, a process model is generated for the chosen path.Eventually, the last step in the methodology concerns the implementation of

the monitoring process. In this regard, we discuss an architecture for the imple-mentation of the methodology in a service-oriented environment. This discussionis made in Section 4.

From now on, the paper will focus on the application of PBWD to designmonitoring processes to satisfy the monitoring requirements of the consumer(stakeholder) in the running example depicted in Fig. 1. In order to decrease itsown risk, the consumer is interested in monitoring (i) the status of the paymentand (ii) the progress of requests on the supplier side. Monitoring informationon the payment can be reconstructed as a combination of information on whenthe factor sent out the payment and information on when the supplier receivedthe payment. If for instance, the factor has sent out the payment, but this hasnot been acknowledged by the supplier in a reasonably short period, then thepayment may not have been successful.

Monitoring information on the progress of an order can be provided either bythe supplier or directly by the contractors. The supplier has only a low-qualityview on the order progress, e.g. the supplier may only report that the orderhas been sent to contractor 1, but he cannot access the details of the internalenactment of contractor 1’s process. More detailed monitoring information canbe provided directly by contractors.

3.1 The Product Data Model

Fig. 3 summarizes in a PDM the information products available to satisfy themonitoring information requirements of the consumer. A PDM is constitutedby information products and operations. Information products in the PDM aredepicted by circles, while the operations performed on the input elements toproduce the output are represented by hyperarcs. Each operation has zero ormore input elements and has exactly one output element, i.e. the informationproduct obtained through the combination of its input elements. A PDM maycontain alternative paths to produce a certain information element. Hence, wedefine a path as any sub-graph of the PDM. A complete path is a sub-graph ofthe PDM containing the root element.

In our example, the correct monitoring information for the consumer (MON)is obtained combining information on the delivery of the payment (PAY) andinformation on the progress of the request (PRO). The monitoring informationPAY can be obtained either as information on when the factor has sent outthe payment (PF ), information on when the supplier has received the payment(PS ), or a combination thereof. The progress report (PRO) can be obtainedeither from the supplier (SPx ) or from the contractors (Eyx ). Note that x rep-resents the quality of the provided monitoring information, i.e. High or Low(x ∈ {H, L}), whereas y identifies the contractor (y ∈ {1, 2}). The supplier andcontractors 1 and 2 can provide two different types of monitoring information,that is, more or less accurate (see SPH and SPL or E1H and E1L).


MON

OP1

OP10

PAY PRO

OP2 OP5 OP8

OP9

PF PS SPH SPL E1H E1L E2H E2L

OP2

OP3OP4 OP5

OP6 OP7

PF PS SPH SPL E1H E1L E2H E2L

OP18OP17OP16OP15OP14OP13OP12OP11

Fig. 3. Factoring monitoring product data model

Table 1. Constraints on example monitoring product data model

Operation C Q A Operation C Q A

Op01 0 1 1.0 Op10 0.5 0.5 1.0Op02 0.6 0.3 1.0 Op11 0.2 1 0.9Op03 0.8 0.8 1.0 Op12 0.7 1 0.7Op04 0.1 0.7 1.0 Op13 1 1 0.7Op05 0.1 0.4 1.0 Op14 0.8 1 0.9Op06 0.1 0.2 1.0 Op15 0.5 1 0.63Op07 0.8 1 1.0 Op16 0.3 1 0.7Op08 0.6 0.7 1.0 Op17 0.3 1 0.7Op09 0.6 0.7 1.0 Op18 0.1 1 0.8

Operations in the PDM signify the production of an information product.In particular, leaf operations (Op11 to Op18 ) signify the production of moni-toring information made by the supplier, contractors, and the factor, while theother operations signify the combination of data elements to produce the parent.In this respect, for instance, Op07 signifies the combination, made by the con-sumer, of high quality monitoring information from contractors (E1H and E2H )to produce the PRO data element, whereas Op03 signifies the combination ofpayment information from the factor (PF ) and the supplier (PS ) to produce thepayment monitoring information PAY.

We express a path by listing its set of operations. For instance, the path{Op11, Op02, Op13, Op05, Op01} is complete, since it leads to the production ofthe root element MON.

Apart from the functional structure, a PDM also contains additional infor-mation concerning the non-functional aspects of operations. Three dimensionscharacterize an operation from the non-functional point of view:

– Cost (C). Represents the cost of executing the operation. In other words,for leaf operations, it is the cost sustained by an actor to provide the cor-respondent monitoring information product, whereas for other operationsit is the cost for the monitoring stakeholder (consumer in our case) to


combine the leaf information products to obtain the parent product. Costsare summative, i.e. the cost of an information product is the sum of the costsof operations executed to obtain such an information product [1];

– Quality (Q). Represents the quality of the information product perceivedby the stakeholder of the monitoring product model. Quality of monitor-ing information should be intended as fit for use, i.e. the ability of a pieceinformation to satisfy the monitoring information requirements of its user[23]. Fit for use quality of an information product is aggregated using theminimum value of data quality over all operations required to create theinformation product [1];

– Availability (A). Represents the probability that an operation produces itsoutput element(i.e., the output element becomes available after the executionof the operation). Availability is aggregated multiplying the availabilities ofall considered operations [1].

Table 1 shows the values assigned to the non-functional dimensions for the PDMof Fig. 3. Note, for instance, that the high quality progress status information,i.e. obtained through operation Op13 or Op15, is more costly than the corre-sponding low quality information, i.e. the one obtained through Op14 and Op16,respectively. This because a supplier needs to capture more information from theinfrastructure executing the process to provide high quality monitoring informa-tion. Note also that the cost for the consumer of combining monitoring informa-tion produced by other parties is very low. We assume, in fact, that monitoringinformation is made available digitally and, therefore, its aggregation is almostcostless. Concerning availability, note that aggregation operations executed bythe consumer, e.g. Op07 or Op03, have always highest availability, whereas theavailability of the leaf operations may not be optimal, since it depends on theavailability of the infrastructure in which monitoring information is captured bythe supplier(s) or the factor.

Apart from the cost, quality, and availability, other properties can be alsoconsidered. Ardagna and Pernici [1], for instance, consider execution time andreputation in addition, while Vanderfeesten et al. [21] also consider duration ofexecution.

3.2 Optimal Path in the PDM

After the design of the PDM, the next step in our methodology (see Fig. 2)is the selection of the optimal path. As explained in the previous section, thePDM may accommodate several alternative paths to produce the end product.The objective of this step is therefore to select a complete path that satisfiesthe requirements of the considered stakeholder, in terms of cost, quality, oravailability of the monitoring information, or a combination thereof.

In order to select the optimal path, different constraints may be considered.In this paper we use the following scenarios to illustrate our approach: (i) opti-mal path considering the availability dimension only (A-path), (ii) optimal pathminimizing costs given a minimum quality level (Cq-path), and (iii) optimal


Table 2. Values for the different dimensions (Cost, data quality, availability) for eachpath in the example product data model

Path Operations TotalCost

TotalQuality

TotalAvail-ability

1 Op01 Op02 Op11 Op06 Op14 1,7 0,2 0,812 Op01 Op02 Op11 Op05 Op13 1,9 0,3 0,723 Op01 Op02 Op11 Op08 Op15 Op18 2,0 0,3 0,434 Op01 Op02 Op11 Op10 Op16 Op18 1,7 0,3 0,505 Op01 Op02 Op11 Op07 Op15 Op17 2,4 0,3 0,386 Op01 Op02 Op11 Op09 Op16 Op17 2,0 0,3 0,447 Op01 Op03 Op11 Op12 Op06 Op14 2,6 0,2 0,578 Op01 Op03 Op11 Op12 Op05 Op13 2,8 0,4 0,509 Op01 Op03 Op11 Op12 Op08 Op15 Op18 2,9 0,7 0,3010 Op01 Op03 Op11 Op12 Op10 Op16 Op18 2,6 0,5 0,3511 Op01 Op03 Op11 Op12 Op07 Op15 Op17 3,3 0,8 0,2612 Op01 Op03 Op11 Op12 Op09 Op16 Op17 2,9 0,6 0,3113 Op01 Op04 Op12 Op06 Op14 1,7 0,2 0,6314 Op01 Op04 Op12 Op05 Op13 1,9 0,4 0,5615 Op01 Op04 Op12 Op08 Op15 Op18 2,0 0,7 0,1716 Op01 Op04 Op12 Op10 Op16 Op18 1,7 0,5 0,3917 Op01 Op04 Op12 Op07 Op15 Op17 2,4 0,7 0,1518 Op01 Op04 Op12 Op09 Op16 Op17 2,0 0,6 0,34

path maximizing quality given maximum costs and minimum availability level(Qc,a-path). We chose these type of constraints to exemplify our methodology.In the general case, however, the selection of the optimal path should be seen asthe optimization of a utility function. Stakeholders can define the utility func-tion, for instance, as the weighted sum of partial utility functions on individualdimensions [1].

From the PDM of Fig. 3 and the operation properties of Table 1, we derive18 complete paths for the monitoring process that may all serve the need formonitoring the consumer order fulfillment process. These paths are reported inTable 2. Among the available complete paths, we now discuss the above men-tioned optimal ones:

A-path. The path with the highest availability, i.e. the highest probability of de-livering the required end product in the form of monitoring information (MON ),is path 1. It produces the end product (MON) by executing operations Op01,Op02, Op11, Op06, Op14. The total availability of this plan is 0.81.

Cq-path. A cost optimal path given a minimum quality level is the monitoringpath with the lowest cost that satisfies a quality requirement set by the consumer.Suppose the consumer sets the threshold for the quality level to 0.5. Then, paths9, 10, 11, 12, 15, 16, 17, and 18 are to be considered. The path with the lowestcost is selected from this subset. The cost optimal path given a minimum dataquality level therefore is path 16, with quality 0.5 and cost 1.7.

Qc,a-path. The third scenario concerns the determination of the quality optimalpath given maximum costs and a minimum level of availability. If the consumerhas a budget constraint of at most 2.0 and wants to be for at least 50% surethat the monitoring information is delivered, then the highest quality possible


Op01

Op02 Op06

Op11 Op14

(a)

Op01

Op04 Op07

Op12 Op15 Op17

(b)

Op01

Op02 Op10

Op11 Op16 Op18

(c)

(d)

(e)

(f)

Fig. 4. (a) PDM of the A-path (path 1); (b) PDM of the Cq-path (path 16); (c) PDMof the selected Qc,a-path (path 4); (d) Process model for path 1; (e) Process model forpath 16; (f) Process model for path 4

is achieved by paths 2 and 4. Since there are two optimal paths and we want tohave just one prescriptive process model, it has to be decided which one of thepaths is best. In general, if more than one path satisfy the given constraints, thenseveral approaches can be chosen to select an optimal path. These include: (i)random selection of one path among the identified optimal ones, (ii) selection (bythe monitoring stakeholder) of one of the optimal paths by ranking the criteria,or (iii) selection of the path involving the lowest number of operations. As anillustration, we choose the second case and we define the cost as being the second


most important criterion after the quality. From paths 2 and 4 we now selectthe one with the lowest cost (path 4).

3.3 Derivation of Process Models

After the determination of the optimal path in the PDM with respect to acertain criterion, a process model can be generated for the monitoring process(see Fig. 4). Several algorithms have been proposed to transform the PDM into aprocess model executable, for instance, by a workflow management system [22].We use the algorithm described in [19] to automatically generate a process modelfor the optimal path of the PDM. This algorithm is implemented in the ProMframework for process analysis [20]. The resulting process models of our threeoptimal paths are discussed below. These process models are represented in thePetri Net language. The transitions (squares) represent the operations in thePDM and are named after the output element of the operation, e.g. transitionMON indicates the operation that produces data element MON based on theinput elements PAY and PRO.

A-path. Fig. 4(d) shows the process model for the optimal path with respect tothe availability. There are two parallel branches in the process model that can beexecuted concurrently: (i) a branch in which first the element PF is determinedfollowed by the element PAY, and (ii) a branch in which SPH is determinedfollowed by PRO. Once both elements PAY and PRO are determined, the finalelement MON can be produced. Note that the black activity at the left handside of the process model is a ‘silent’ activity, i.e. it is added only for routingpurposes but does not process information. Using this process, the consumerretrieves monitoring information on the progress of its request only from thesupplier and information on the payment only from the factor.

Cq-path. Fig. 4(e) depicts the process model for the optimal path Cq. Againthere are two parallel branches in the process model, both providing input toproduce MON. On the one hand, PAY is obtained using PS first. On the otherhand, PRO is determined by E1H and E2H, which can be determined in parallelas well.

Qc,a-path. Fig. 4(f) shows the process model for the optimal path Qc,a. It issimilar in structure to the process model of Fig. 4(e), but it uses elements PF,E1L, and E2L in place of PS, E1H, and E2H, respectively.

4 Implementing the Methodology

In this section we discuss the last step of the methodology proposed in this paper(see Fig. 2), i.e. its implementation in a service-oriented environment.

We take a service-oriented approach to the definition of the product data andthe implementation of monitoring processes (see the architecture in Fig. 5(a)).The combination of PBWD and service orientation for design and execution ofmonitoring processes, respectively, can address the need for structural and oper-ational dynamicity in business networks [9]. Concerning network structure, the


Business Network

Process UserProM Toolkit

ProcessExecution

MonitoringService A

onito

rAPI

Provider AProM Toolkit

PetriNet2BPELplugin

WS BPELSpecification

4.DEPLOY

Mr

Provider B WS BPELEngine Product Data Model

( ) l

Petri Netmodel

3.DESIGN5.USE

ProcessExecution

MonitoringService B

AdHo

cMon

itor (PDM) plugin

Monitoring Servicesdescriptions 2.RETRIEVE

MonitoringProcessExecution

MonitoringService C

onito

rAPI

Provider C(functional & quality)

1.PUBLISHg

ServiceRegistry

Mo

(a)

(b)

Fig. 5. (a) PBWD-based monitoring process creation architecture; (b) The ProMtoolkit, showing a PDM, the relative process model, and the WS-BPEL exportfunctionality

actors in the network can be dynamically replaced. Suppliers of spare parts inan automotive industrial district, for instance, can be dynamically substitutedby the car manufacturer as new suppliers providing more convenient or higherquality options become available. Concerning network operations, the networkbusiness processes can be reconfigured on-the-fly as new business opportunitiesarise. Insurance companies, for instance, may decide to outsource part of theirclaim management process only on a temporary basis, e.g. to manage an ab-normal amount of claims resulting from a possible fraud. Both scenarios requirethe dynamic set-up or update of monitoring processes as the network dynami-cally evolves. This is addressed by our methodology at design time, by adopting


PBWD, and at runtime, by using a service oriented approach, where servicesproviding monitoring information can be dynamically orchestrated in the moni-toring processes obtained through PBWD.

The elementary monitoring information products are the monitoring infor-mation that can be made available by actors in the business network to otheractors for monitoring purposes. e.g. the progress information made available bythe supplier or the factor in our running example. In the information systemor process engine executing a process to be monitored, monitoring informationcan be captured from various sources and through different mechanisms, suchas (i) native APIs of the actor’s ERP system, e.g. SAP monitoring architecture,workflow or BPEL engine and (ii) ad-hoc instrumentation, e.g. through the de-velopment of event captors or other online process inspection techniques [2].

Irrespectively of how monitoring information is captured, the process providercan make such information available to users by exposing a Web service [6] im-plementing, for instance, a different operation for each leaf element in the moni-toring product data model. The cost, quality, and availability of the monitoringinformation (see Table 1) can be then specified in a policy document [4], thatcan be attached to such service before its publication.

In a service-oriented architecture, process providers publish their monitoringservices in a service registry (STEP 1 in Fig. 5(a)) and process users browse theregistry to get service descriptions and build their monitoring PDM (STEP 2).Note that, in Fig. 5(a), process provider and user should be intended as roles,since an actor in the business network can act at the same time as a provider ofprocesses and a user of processes contributed by other actors.

The architecture depicted in Fig. 5(a) supports also the creation of an exe-cutable monitoring process. Specifically, a process user in the business networkinterested in building a monitoring process retrieves the required monitoringservice description from the registry. Service descriptions are then used to builda monitoring product data model using the ProM toolkit (STEP 3). Currently,as discussed in the previous sections, the algorithms for obtaining monitoringprocess models (STEP 3), expressed as Petri nets and satisfying given qualityconstraints, have been implemented as plugins of the ProM toolkit. ProM alsoprovides a plugin for the translation of models from Petri nets to (abstract)WS-BPEL specifications (see Fig. 5(b)). The abstract WS-BPEL specificationis bound by the monitoring stakeholder to the required monitoring services inthe registry, in order to make it executable, and deployed in a process engine(STEP 4). When in execution, a monitoring process will use the monitoring ser-vices originally published by actors in the business network, according to theaggregation and dependency constraints specified in the monitoring PDM andthe derived monitoring process model (STEP 5).

In respect of the scenario depicted in Fig. 5(a), most of the steps of ourmethodology, such as the definition and retrieval of monitoring services from theregistry, the binding of the WS-BPEL specification obtained through ProM toactual services in the registry, and the deployment of the WS-BPEL specificationin the process engine, are still executed manually. Future work will concern the


implementation of an integrated approach in which the aforementioned activitiescould be fully automated.

5 Conclusions

This paper presents an innovative application of PBWD, that is, the product-based design of monitoring processes in collaborative business networks. Theinnovation brought about by this paper is twofold. On the one hand, given a col-laborative scenario and available monitoring information, we propose a method-ology to design from scratch a monitoring process that matches the process user’srequirements, in terms of cost, (data) quality, and availability of monitoring in-formation. On the other hand, we discussed an architecture for implementingthe proposed methodology.

A first area of improvement for this work concerns the implementation ofthe architecture reported in Fig. 5(a) and, specifically, the connections betweenthe implemented ProM’s plugins and the service-oriented process execution en-vironment. Future work will also concern the extension and refinement of theproduct-based generation of monitoring processes. In particular, we plan to con-sider additional non-functional dimensions, such as reputation, and more com-plex utility functions for capturing the monitoring stakeholder requirements.Constraints describing monitoring products can also become dependent on thetype of monitoring information and the type of stakeholder requiring it. Hence,we want to investigate the issue of provider and user profiling for automaticallydesigning more customized monitoring processes. Also, while this paper consid-ers the monitoring requirements for a stakeholder at the process level, we areplanning to consider also instance-level monitoring requirements, i.e., monitor-ing requirements that can change with every different instance involving a givenstakeholder. Finally, from the modeling perspective, we want to investigate theopportunity of specifying monitoring processes as choreographies, e.g. in BPMN2.0, for capturing more complex dependencies among monitoring information.

References

1. Ardagna, D., Pernici, B.: Adaptive Service Compostion in Flexible Processes. IEEETransactions on Software Engineering 33(6), 369–384 (2007)

2. Baresi, L., Guinea, S., Nano, O., Spanoudakis, G.: Comprehensive monitoring ofBPEL processes. IEEE Internet Computing 14(3), 50–57 (2010)

3. Baresi, L., Guinea, S., Pistore, M., Trainotti, M.: Dynamo + Astro: An integratedapproach for BPEL monitoring. In: Proc. ICWS (2009)

4. Cappiello, C., Comuzzi, M., Plebani, P.: On automated generation of web servicelevel agreements. In: Krogstie, J., Opdahl, A.L., Sindre, G. (eds.) CAiSE 2007 andWES 2007. CAiSE, vol. 4495, pp. 264–278. Springer, Heidelberg (2007)

5. Chiu, D.K.W., Karlapalem, K., Li, Q., Kafeza, E.: Workflow view based E-contractsin a cross-organizational E-services environment. Distrib. Parallel. Dat. 12, 193–216(2002)


6. Comuzzi, M., Vonk, J., Grefen, P.: Continuous monitoring in evolving businessnetworks. In: Proc. CoopIS, pp. 168–185 (2010)

7. Daneva, M., Wieringa, R.: A requirements engineering framework for cross-organizational erp systems. Requirements Engineering 11, 194–204 (2006)

8. Grefen, P., Aberer, K., Hoffner, Y., Ludwig, H.: CrossFlow: cross-organizationalworkflow management in dynamic virtual enterprises. Comput. Syst. Sci. & Eng. 5,277–290 (2000)

9. Grefen, P., Eshuis, R., Mehandijev, N., Kouvas, G., Weichart, G.: Internet-basedsupport for process-oriented instant virtual enterpises. IEEE Internet Comput.,30–38 (2009)

10. Kappler, L.: The role of factoring for financing small and medium enterprises.Journal of Banking and Finance 30, 3111–3130 (2006)

11. Kartseva, V., Hulstijn, J., Gordijn, J., Tan, Y.-H.: Control patterns in a health-carenetwork. European Journal of Information Systems 19, 320–343 (2010)

12. Kotsokalis, C., Winkler, U.: Translation of service level agreements: A generic prob-lem definition. In: Dan, A., Gittler, F., Toumani, F. (eds.) ICSOC/ServiceWave2009. LNCS, vol. 6275, pp. 248–257. Springer, Heidelberg (2010)

13. Moser, O., Rosenberg, F., Dustdar, S.: Non-intrusive monitoring and service adap-tation for ws-bpel. In: Proc. WWW (2008)

14. Orlicky, J.: Structuring the Bill of Materials for MRP. In: Production and InventoryManagement, pp. 19–42 (December 1972)

15. Reijers, H.A. (ed.): Design and Control of Workflow Processes. LNCS, vol. 2617.Springer, Heidelberg (2003)

16. Reijers, H., Limam, S., van der Aalst, W.: Product-Based Workflow Design. Jorunalof Management Information Systems 20(1), 229–262 (2003)

17. Robinson, W.: A requirements monitoring framework for enterprise systems.Requirements Engineering 11, 17–41 (2006)

18. Rozinat, A., van der Aalst, W.: Conformance checking of processes based onmonitoring real behavior. Information Systems 33(1), 64–95 (2008)

19. van der Aalst, W.: On the Automatic Generation of Workflow Processes based onProduct Structures. Computers in Industry 39, 97–111 (1999)

20. Vanderfeesten, I.: Product-Based Design and Support of Workflow Processes. PhDthesis, Eindhoven University of Technology, Eindhoven, the Netherlands (2009)

21. Vanderfeesten, I., Reijers, H., van der Aalst, W.: Product-Based Workflow Support.Information Systems (2011) (to appear)

22. Vanderfeesten, I., Reijers, H., van der Aalst, W., Vogelaar, J.: Automatic Supportfor Product Based Workflow Design: Generation of Process Models from a ProductData Model. In: OTM 2010 Workshops, pp. 665–674 (2010)

23. Wang, R.: A product perspective on total data quality management. Communica-tions of the ACM 41(2), 58–65 (1998)

Documents

Product-Based Workﬂow Design for Monitoring of ......Product-Based Workﬂow Design for Monitoring of Collaborative Business Processes Marco Comuzzi and Irene T.P. Vanderfeesten