In this blog entry we describe our research on different paradigms of distributed process management that have emerged over the last years. It is part of our research within Public Services team at the SAP Research Center (Sophia Antipolis) / SAP Research FRANCE.
We present the four basic paradigms underlying distributed process management including two novel promising paradigms that emerged at SAP Research.
Four Different Paradigms of Distributed Process Management
Overview
We have developed a matrix categorizing paradigms for distributed process management into two categories (see following figure): Modeling of the process and execution of the process. Modeling can be done individually or collaboratively. This can be seen on different levels of granularity (e.g. people or organizations). The execution of the process can take place either centralized (on one system) or distributed (on several/multiple systems connected via a network).
 |
We see that four different paradigms emerge from this matrix. We describe these paradigms now and provide examples for them.
Individual Modeling/Centralized Execution
These are standard workflow systems (e.g. Netweaver BPM or SAP Business Workflow). The following figure provides an example for this paradigm. The process designer models the process and deploys it on a centralized server for execution by a workflow engine.
 |
Individual Modeling/Distributed Execution
Many approaches have been proposed in this area (e.g. [3-5]). The basic idea is that one entity defines a public process and this process is split into different pieces. The different entities then execute their part of their process in a distributed manner. Although the body of knowledge is very mature in this area and different research prototypes exist, it has not yet found its way into commercial products. The problem faced here is that there needs to be one central deciding entity who defines what the public process is (i.e. the organizations part of the process cannot act autonomous) - this is more a business/governance problem than a technical problem. In the following figure we illustrate how this paradigm works: A workflow designer defines a process and the parts of the process are distributed to different servers for execution.
 |
Collaborative Modeling/Centralized Execution
This is a new paradigm. It has recently emerged in form of the SAP Research Prototype "Gravity – Collaborative Business Process Modelling within Google Wave" which allows different distributed modelers to model the process via Google Wave or SAP Streamwork collaboratively and to import the model into the SAP Netweaver BPM engine to execute it centralized on a SAP Netweaver BPM server. Many interesting use cases have been described (e.g. M&A). The following figure provides an example for this paradigm. Process designers collaboratively model the process and the process is deployed for centralized execution on a workflow server (e.g. SAP Netweaver BPM).
 |
Collaborative Modeling/Distributed Execution
This is a new paradigm. It is part of our research and has also been implemented in Google Wave. The idea is that different entities create activities and share activities with other entities. They also define dependencies/constraints (e.g. temporal ones) between their own activities and the shared activities. For example, in a crisis response scenario, the police commander can model that if “Protection of Residential Area from the Flood” by the fire fighters fails then “Evacuation of Residential Area” by the police starts its execution. This is very interesting for heterogonous and autonomous working organizations (e.g. in crisis management), because it is not required that different entities agree on a common public process. (Shared) Activities can change their state (i.e. they are executed in a distributed manner) and this may violate dependencies to these activities defined by different organizations in different models. This approach overcomes the problems of the individual modeling/distributred process execution approach.
 |
The figure illustrates this paradigm using a crisis response management scenario. People can share activities and their current state with the Shared Activity Workspaces (SAW, comparable to distributed servers) of other organizations. Shared activities are illustrated with dotted borders. The other organizations can define dependencies/constraints (e.g. temporal ones) to the shared and their own activities. For example, the military commander has shared the activity “C” with the fire fighter commander. The fire fighter commander creates a dependency to his/her own activity “A”. When activity “C” changes its state (e.g. initiated by the military) then this may violate dependencies in the SAW of the fire fighters. Sharing takes place on a social basis (i.e. from person to person) and it is not required to share activities. For example, the military commander and medical staff do not share activities.
Conclusions
We think that all paradigms are important and it depends on the process and the environment which paradigm should be used. One organization will probably use all four paradigms. We see a big need for providing software for all paradigms, in particular the last two, because not all paradigms are equally well supported by software.
We are looking for your comments!!!
What do you think of these paradigms for distributed process management?
The following people work on this project
Jörn Franke, Public Security, SAP Research Center (Sophia Antipolis), France / LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France
François Charoy, LORIA-INRIA-CNRS, UHP, Université de Lorraine, Nancy, France
Cédric Ulmer, Public Services, SAP Research Center (Sophia Antipolis), France
Acknowledgements
This work results from the collaboration between Public Security, SAP Research FRANCE and the SCORE group at LORIA-INRIA-CNRS of the Université de Lorraine, Nancy, France. The research was partially funded by means of the German Federal Ministry of Education and Research under the promotional reference 01ISO7009 (see [6]) and the French government within the RescueIT project [7]. Another part was funded by the CIFRE PhD funding scheme of the French government.
References
[1] Franke, Jörn; Charoy, François: Design of a Collaborative Disaster Response Process Management System, 9th International Conference on the Design of Cooperative Systems (COOP'2010), Aix-En-Provence, France, 19-21 May, 2010.
[2] Franke, Jörn; Charoy, François; Ulmer, Cédric : Coordination and Situational Awareness for Inter-Organizational Disaster Response, 10th IEEE International Conference on Technologies for Homeland Security, Boston, WA, USA accepted
[3] Frederic Montagut, Refik Molva: Enabling pervasive execution of workflows. CollaborateCom 2005
[4] Walid Fdhila, Ustun Yildiz, Claude Godart: A Flexible Approach for Automatic Process Decentralization Using Dependency Tables. IEEE 7th International Conference on Web Services (ICWS 2009), July 6-10, 2009, Los Angeles, CA, USA : 847-855.
[5] Wil M. P. van der Aalst, Process-oriented architectures for electronic commerce and interorganizational workflow, Information Systems, Volume 24, Issue 8, December 1999, Pages 639-671
[7] Schaad, A.; Ulmer, C. & Gomez, L. Rescueit - Sécurisation d'une chaine logistique internationale, Workshop Interdisciplinaire sur la Sécurité Globale, 2010, http://www.sichere-warenketten.de/
5 Comments
