Today companies outsource part of the service provisioning to other companies that are not part of their core competence. Companies can use current workflow management systems to control the progress of the service process within one organisation. However, with business-to-business e-commerce, service processes extend beyond organisational boundaries and the workflow management paradigm should be extended to incorporate specific inter-organisational aspects. This problem is investigated in the CrossFlow project. In this paper the CrossFlow concepts are applied to a logistics scenario and it shows the applicability of the CrossFlow paradigm in practice.
consumer B C
A F
D’ E’ contract invoke monitor control results provider
D
E • Dynamic vs. pre-defined service outsourcing The co-operation between partners can be based on dynamic service outsourcing paradigm with service consumers and service providers. Compatible business partners find each other through a matchmaking facility. If the dynamic matchmaking is not needed, the business partners can pre-define their fixed outsourcing. • Contract-based service specification A detailed service specification in the form of a contract is the basis for a tightly linked co-operation implementing the service provision from service provider to service consumer. The definition of the interaction in the contract is independent of the specific enactment technology of the organisations. • Advanced influence on service provider The service consumer can influence the progress of processes at the provider at a fine grain and a high semantic level, enhanced by the availability of a set of advanced Co-operative Support Services.
A broad spectrum of Co-operative Support Services (CSS) is relevant for cross-organisational workflow management, like remote process monitoring and control, cross-organisational transaction management, automatic service remuneration, trust and security management, etc. The design of these services is such, that they can be selected and combined in a modular way, depending on the application context. In the context of the CrossFlow project, three areas of advanced Co-operative Support Services are addressed: • Quality of Service (QoS) monitoring allows to track the progress of outsourced services, both online during service execution and off-line to analyse aggregate information. • Level of Control (LoC) enactment provides means for high-level cross-organisational transaction management and consumer-controlled process control over outsourced services (e.g. stop, start, abort). • Flexible Change Control (FCC) allows for flexible service enactment, choosing between alternative paths during service enactment. 3
The LOGIS – TELCO scenario is derived from the real life co-operation between TELCO Telecom and LOGIS Logistics. Part of the delivery of equipment from TELCO Telecom to customers is carried out by LOGIS Logistics. This involves purchases by telephone or by Internet (e-commerce). The most interesting part of the scenario deals with the handling of cellular phone orders. LOGIS takes care of the warehousing, distribution, delivery and payment, based on orders from TELCO. In CrossFlow terminology, TELCO acts as the service consumer whereas LOGIS is the service provider. The details of the scenario will be described with the help of a flow diagram.
No customer requests service start order order complete? GSM al owed? Yes
activate GSM number
No
Yes fetchnGumSMbesrerial include GSM number and wrap up parcel send and deliver parcel The flow diagram is divided into two sides, a TELCO side and a LOGIS side. It represents a single order for telecom equipment. Each order starts and ends with the consumer TELCO.
The control flow starts when a TELCO customer requests a service, be it either a telecom connection or equipment. On order entry, customer and order data are checked for completeness. After that the order data is checked at LOGIS. If it is not OK, LOGIS refuses the order and TELCO has one more chance of completing the data. If this succeeds, LOGIS will accept the order after all; otherwise the order is cancelled. If the requested equipment concerns a GSM (cellular) phone, the left branch at LOGIS will be taken; otherwise the right branch will be chosen. Note that this branch is straightforward; we will only discuss the left branch in more detail. This part of the diagram shows the assignment of a phone number to the physical telephone. To this end, LOGIS provides TELCO with a unique identifier of the physical phone (GSM serial number), which is used by TELCO to assign a phone number to. The phone number is included in the parcel to be delivered. This way, the customer is ready to use the phone immediately after delivery. After delivery, LOGIS arranges the billing (not detailed in the diagram) and a proof of delivery is returned to TELCO. TELCO finishes the order and may contact the customer to check his satisfaction. 4
In this paragraph we apply the CrossFlow concepts to the logistics scenario presented above. This way we identify strengths and weaknesses of the CrossFlow approach with respect to our application. We will discuss the applicability of the matchmaking and contract establishment facilities, the contract definition and the cooperative support services. 4.1
Contract establishment is closely linked to the different parties involved in the end-to-end service provisioning. Looking carefully at the scenario we identify five rather autonomous organisational departments (see dashed boxes in Figure 2): • • • • •
TELCO Sales, LOGIS Order Entry, TELCO GSM, LOGIS Order Processing,
LOGIS Delivery.
TELCO Sales receives the order from its customer and communicates status information and order changes. LOGIS Order Entry gets the order from TELCO and may improve on the quality of the order data to LOGIS standards. TELCO GSM handles GSM subscriptions, LOGIS Order Processing performs the actual order picking and packaging and LOGIS Delivery takes care of final delivery and payment.
The different parties have different roles in the scenario. For example, TELCO Sales has a consumer role and submits its order to the LOGIS Order Entry, hence establishing a ‘Consumer to Provider relationship’. The LOGIS Order Entry department may ask TELCO Sales to complete the order data, hence TELCO Sales acts here in a provider role, mirroring the relationship.
In the table below, a complete list of the relationships involved is given: LOGIS Order Entry asks TELCO Sales to complete order data LOGIS Order Processing synchronises with TELCO GSM to activate GSM subscription LOGIS Order Processing outsources delivery of parcel to other organisational unit Following the CrossFlow approach, the different consumer – provider relationships should be reflected in different contracts. We highlight two aspects here: applicability of dynamic outsourcing and role symmetry. 4.2
CrossFlow foresees a marketplace where parties establish co-operations dynamically when opportunities arise. When we look at the scenario we see that LOGIS has customised its processes to the processes of TELCO, offering advanced interaction between both parties. This means that it is very difficult for TELCO to find a suitable partner that matches the specific interaction pattern. If TELCO wishes to co-operate with other logistic partners as well, this would require either a new process definition for this new party, or it would require TELCO to simplify its process interaction. Within the CrossFlow context, this would typically imply restrictions on the interactions that occur during exchange of GSM serial number and phone number. A solution to the problem is given in Figure 3. 4.3
At a high level, we see two organisations co-operate in order processing: TELCO and LOGIS. TELCO maintains a contact with its customer that placed the order. Therefore it is natural for TELCO to know the status of the order process and TELCO should be able to influence the progress of the process. However, in Figure 2 we see, that the role of individual departments within TELCO and LOGIS may change between consumer and provider. According to the CrossFlow paradigm, a consumer may influence progress of the process at the provider side, but not vice versa. Therefore, when for example LOGIS Order Processing acts as consumer and TELCO GSM as provider, TELCO is not in control of the process. This may not be desirable, because TELCO wants to control the progress at all times. One solution would be to view TELCO GSM as a separate company that co-operates with LOGIS. TELCO GSM then acts as a third party in the scenario out of control of the TELCO Sales department. In that case, LOGIS would then be able to request GSM subscriptions at will, without explicit control flow between TELCO Sales and TELCO GSM (see Figure 3). Whether this should be allowed is a business decision. Summarising we conclude that the CrossFlow paradigm is not suitable to support intermediate interaction between departments of different companies as is. 4.4
The CrossFlow paradigm is based on dynamic outsourcing. In the previous paragraph we already mentioned, that dynamic outsourcing is difficult in our case, because processes at TELCO GSM and LOGIS Order Processing are tightly integrated. LOGIS must first deliver the product identifier, before TELCO can allocate a GSM phone number. This phone number must be returned to LOGIS to include it into the phone parcel. This interaction implies execution dependencies between both parties. Particularly, for LOGIS therefore it may not be possible to guarantee certain delivery deadlines, because it is dependent on the speed of the TELCO GSM process. Within CrossFlow these dependencies between consumer and provider are classified into the following classes [LAGN+99]: The black box represents a provider process with just one activity. No interaction is defined. The glass box provides the consumer the ability to look at multiple activities of the provider process. However, no incoming or outgoing control flow is defined. The open box classes provide synchronisation of outgoing (outward) control flow (from provider to consumer) and incoming (inward) control flow. The open box – outward class preserves the independence of the execution at the provider and therefore the provider can guarantee the contractual obligations. Incoming control flow (consumer to provider) could hinder the provider to fulfil its tasks according to the contract. The broken box class includes both incoming and outgoing control flow. In CrossFlow it is decided not to include incoming arrows so as to preserve the autonomy of the provider.
However, in our scenario we indeed have identified a broken box class: the interactive processes between TELCO GSM and LOGIS Order Processing. To conform to CrossFlow, we had to do some process redesign. Particularly, we had to divide the flows into strict outsourcable units, removing some interacting flows. The result is shown in Figure 3. Note that it is not desirable to adapt business processes because of technical limitations. Another solution would be to keep the control flow exchange between parties implicit. In that case one could include send and receive of messages explicitly in the activities themselves. Clearly, this is not a nice way of modelling control flow. 4.5
CrossFlow includes three Co-operative Support Services as described earlier: Level of Control (LoC), Quality of Service (QoS) and Flexible Change Control (FCC). Next we describe the applicability of all three services. 4.5.1
Level of Control Level of Control provides the consumer with the ability to influence the process enactment at the provider side. The primitives include start, stop, change, rollback and abort. The rollback primitive is associated with the CrossFlow transaction model, called the X-transaction model [VDGK00]. The X-transaction model is based on the SAGA model [Garci87], where each activity is executed atomically and isolated and has a compensating activity associated with it. A rollback is here performed by executing the corresponding compensating activities of passed activities in reverse order [VDG99]. The X-transaction model was inspired by the WIDE project [GPS99].
All activities and complex decisions are transformed into single steps as shown in Figure 3. Since compensating activities are defined for each step, the exception handling like ‘unwrap parcel’ and ‘put equipment back in stock’remain implicit in the workflow process definition. The activity ‘check order data’at TELCO remains a valid exit point to cancel the order. At this point the primitives allowed in the provider process are yet to be defined. 4.5.2
Quality of Service Quality of Service is defined as constraints on the delivery times of LOGIS. Also the process status of LOGIS can be monitored (called on-line monitoring), so that TELCO can see what the status is of the process. Important for TELCO is whether the LOGIS activity ‘delivery and payment’ has succeeded. Off-line monitoring can be used to estimate the average performance of the LOGIS process. In [Kling00] it is shown that continuous-time Markov chains can be used to estimate throughput times. 4.5.3
Flexible Change Control Flexible Change Control is concerned with the flexible enactment of the workflow specification. In this case, we look at the LOGIS side. In [Kling00] three constructs are proposed to model flexible workflow: alternative (either A or B is executed, i.e. [A, B]), non-vital (A may not be executed, i.e. Anv), optional order (B follows A, but their order may be interchanged, i.e. {A, B}). These constructs are used to give the scheduler the opportunity to choose between high quality (and cost) execution paths or low quality (but efficient) alternatives. Looking at the LOGIS scenario, we may include an alternative construct at the delivery activity. Here we could extend the single activity with the choice to include the conventional delivery or express delivery. Non-vital activities could include the send ‘proof of delivery’, because this activity provides status information that is redundant with the process status. For the optional order construct we could not identify application within this scenario. cancel customer requests service start order check order data check type of equipment pick order The scenario shows how business-to-business e-commerce is applied in the logistics domain and that close cooperation is essential for delivering high quality advanced services to customers. In this context CrossFlow brings a paradigm to control the business-to-business outsourcing. The main aspects of CrossFlow include dynamic service outsourcing, contract-based service specification and advanced influence on provider processes. When applying the CrossFlow paradigm to the scenario we find that dynamic outsourcing has limited applicability. The TELCO and LOGIS processes are tightly integrated and not easy to outsource. Although one could think of TELCO and LOGIS as two parties, separate contracts for individual departments seem natural. Another difficulty with the CrossFlow paradigm is the process interaction required between TELCO GSM and LOGIS Order Processing. As CrossFlow does not support the Broken Box paradigm, the business process should be redefined. This is not desirable in practice.
The definition of the Co-operative Support Services is explained in this paper, and suggestions for their application to the scenario are given. Refinement of the definition is left for future work.
CSSE00 Garci87 GPS99 Kling00 KWA99 LAG+99 VDG99 VDGK00 We would like to thank the members of the Crossflow team for lively discussions. Special thanks go to Jochem Vonk, Paul Grefen and Marjanca Koetsier at the University of Twente.
Grefen, P.; Aberer, K.; Hoffner, Y.; Ludwig, H. CrossFlow: Cross-Organizational Workflow. Submitted to CSSE 2000 Garcia-Molina, H.; Salem, K. Sagas, Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, USA, 1987 Grefen, G.; Pernici, B.; Sanchez, G. (eds.) Database support for Workflow Management - The WIDE Project, Kluwer Academic Publishers, Boston, 1999 Klingemann, J. Flexible Change Control. CrossFlow Deliverable D8a, 2000 Klingemann, J.; Wasch, J.; Aberer, K. Deriving Service Models in Cross-Organisational Workflows. RIDE Workshop, 1999 Ludwig, H.; Aberer, K.; Grefen, P. et al. Outsourcing Re-Visited, CrossFlow internal deliverable, 1999 Vonk, J.; Derks, W.L.A.; Grefen, P. LoC Model, CrossFlow Deliverable D10a, 1999 Vonk, J.; Derks, W.L.A.; Grefen, P.; Koetsier, M. Cross-Organizational Transaction Support for Virtual Enterprises, submitted to CoopIS 2000 Abstracts of the CrossFlow deliverables can be downloaded directly from www.crossflow.org. Full version of the deliverables can be requested via this site as well.