Skip to Content
Author's profile photo Former Member

The Four Paradigms of Distributed Process Management

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


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).


 Matrix describing the four different paradigms of distributed process management


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.

Distributed Process Management Paradigm: Central Definition/Central Execution 

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.

Distributed Process Management Paradigm: Central Definition/Decentral 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).

Distributed Process Management Paradigm: Decentral Definition/Central Execution 

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.

Distributed Process Management Paradigm: Decentral Definition/Decentral Execution 

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.


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


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.


[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,

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Gabriel SERME
      Gabriel SERME
      Hi Joern,

      I think you are proposing a new and innovative approach to reach various stakeholders that are not use to BPM, by hidding the complexity.

      Have you thought about different platform to use your system? Cause you are mentionning a prototype with Google wave, and (i) google wave is dying (ii) there is no mobile interaction possible with google wave.

      Author's profile photo Former Member
      Former Member
      Well, yes different platforms are possible (e.g. SAP Streamwork) as long as they support (near) realtime collaboration. I will soon release another Blog entry where I describe the concept of collaborative modeling/distributed execution in more detail.

      ad (i) no google wave is not dying, it is currently in the process to be released as opensource ( and I expect several different servers that are able to federate with each other. Some of the technology of google wave has been ported to other products (e.g. google docs). I expect that the open version of google wave will develop much faster and will be incorporated by other vendors.

      ad (ii) there is mobile interaction possible via the google wave data api ( you can develop any client you want even mobiles (in fact this is also possible with SAP Streamwork Integration API)

      Author's profile photo Former Member
      Former Member
      And how will you manage the conflicting states of an activity in different Shared Activity Workspaces, because I assume that activities can change their states independently after sharing.
      Author's profile photo Former Member
      Former Member

      yes so after sharing the activity state updates are propagated optimistically do everyone who has the shared activity. This allows integrating it into different plans (or processes). In our approach everyone can change the state (of course this could be also restricted) and this may cause conflict. We do not expect that this conflict occurs often, but it may happen. This can also happen with the "traditional means" (fax, e-mail etc.). We have developed some mechanisms that the conflict can be detected and also handled automatically. Of course, we cannot rely here on traditional mechanisms for distributed systems, because we have humans involved here. It is also difficult for a system to reason what can be the correct state (even if it would have all the information available), because it may not be even clear for the people at a given moment. We submitted these mechanisms to a conference and I will keep you updated in the blog about it. We are also applying our approach to other scenarios besides crisis management (in the end we hope to improve coordination in rather unstructured processes). Are you working in a similar area? Have nice holidays,


      Author's profile photo Former Member
      Former Member

      sorry for my late answer. We submitted a solution to this problem to a conference and it has been accepted for publication:

      Franke, Jörn; Charoy, François; Ulmer, Cédric: Handling Conflicts in Autonomous Coordination of Distributed Collaborative Activities, 20th IEEE International Conference on Collaboration Technologies and Infrastructures (WETICE'2011), Paris, France, 27-29 June, 2011.

      I would be very happy to discuss with you this topic. Please send me an email if you are interested.

      Best regards,