Project Topics
Get Complete Project Material File(s) Now! »
Coordination of Activities by People of Different Organizations in Dynamic Situations
The first part of the motivational example deals with coordination of activities in dy-namic situations. The aim of coordination is an efficient and effective use of resources, skills and capabilities to meet a goal. It should be avoided that inaction occurs, double efforts or conflicting actions are performed. Our definition of coordination is based on coordination theory proposed by Malone and Crowston [MC94], which has been also ap-plied to the disaster response context [CSRU08]. Coordination of activities in our context means to relate what has been done, what is currently done and what are the next steps to reach a goal. A dynamic situation in the sense here is characterized by shifting goals. These shifting goals lead to reassessment of the goals and the activities that need to be done. These goals and the corresponding activities are defined by humans based on their judgment of the complex situation. A reassessment of activities has to take into account their relations, i.e. what has been done and what is currently going on.
We illustrate an example for these concepts in Figure 2.1 1. The fire fighter commander in the command center (illustrated on the right of the figure) tells the fire fighters in the field (illustrated on the left of the figure) to protect the residential area from a flood. This can be compared to a goal of the fire fighters in the field. He details this with further instructions to build a dam, transport sandbags and fill sandbags. These are the activities that need to be coordinated towards the goal. During the fulfillment of these activities, some of the fire fighters get injured, because the rain-sodden ground makes it difficult to move. This is reported to the fire fighter commander. The fire fighter commander orders an additional unit to transport the injured fire fighters to a hospital. The goal shifts towards treating the fire fighters first before continuing with building the dam. Later, he decides that the protection of the residential area can continue as planned. The remaining fire fighters in the field are also able to continue with this task. Then, the fire fighter commander receives a request that some firefighting units are needed urgently at another disaster site. The goal shifts again to fulfill this request. This means sandbags cannot be transported and filled anymore by the fire fighters. A replacement needs to be found for them, but this has less priority than the urgent request.
We only described here one example for coordination of activities in dynamic situa-tions. During a real disaster, there will be of course more goals, more activities and more frequent shifts of goals. Particularly, on the inter-organizational level, where there are many organizations, each with their own goals and activities that are related to each other.
Tool Support for Coordination of a Disaster Response in Practice
We research in this paragraph the tools used in practice for inter-organizational co-ordination of activities in the disaster response by the disaster managers, such as police men and fire fighters, within the SoKNOS project [DPZM09]. This will help us to unders-tand better their functionalities and limitations. The main aim of the SoKNOS project was to investigate technical integration of systems of different organizations in a disaster. Integration should facilitate exchange of information between different organizations to provide a better overview of the situation. The use case was a large-scale flood based on previous flood disasters in Germany. Many organizations have been involved in these disasters. The main integration technology was based on Service-Oriented Architectures (SOA) [Erl05] and Service Component Architectures (SCA) [MR09]. Within the SoKNOS project, several interviews have been conducted with partners in the project (e.g. Tech-nische Hilfswerk (THW), University of the Police, Dortmund Police, Fire Brigade of Berlin and Cologne [DKU+08]). A half-day workshop has been carried out in January 2009 with some of them (University of the Police, Fire Brigade in Berlin and Cologne) on the topic of inter-organizational collaboration in a disaster response. Inter-organizational collabo-ration does not only include public safety organizations, but also private organizations responsible for public safety (e.g. Deutsche Bahn or churches). This workshop helped us to better understand the limitations of inter-organizational collaboration involving human actors.
An important artifact for coordination of the disaster response is a plan [GH05, Qua86], which can also be understood as a “resource for action” [Suc87], i.e. reasoning and reflec-ting on it based on the situation faced [Bar97]. It is used by public safety organizations, humanitarian aid organizations or private companies. One major challenge for any res-ponse plan is that a disaster is by definition something new and difficult to predict. This is contrary to the response procedures for an emergency, which can be planned in more detail. Going back to the motivational example, it is difficult to plan that the fire fighters are injured or that the military has to provide sandbags for the fire brigade. Several ele-ments of a disaster response plan based on the plans made available by disaster managers in the SoKNOS project are described in Table 2.2. This list is not exhaustive, because the available plans are not representative of all possible plans, but the list provides a suf-ficient overview to understand the artifact. Disaster response plans are not detailed (cf. also [Suc87, Qua86]) and contain generic activities. There are few relations between acti-vities documented in plans, because they are subject to the concrete situation faced when using the plan [Dek03]. It is very costly to develop detailed plans for disasters that may never happen. Furthermore, there is still the risk that plans become too specific, which may lead to the case that plans become rendered useless if the situation in a disaster is slightly different from the plan. This means they cannot specify all situations that may apply [Suc87]. It is impossible to anticipate every situation [Qua86] and adaptation as well as development of new plans can be necessary [Wei00, Suc87]. It would also be very costly to maintain detailed plans and adjust them to the object of risk of a disaster. For example, demographics of a community change and this affects how the community can be evacuated. Another example is that the response procedures of other organizations can change over time. Some disaster response plans in the SoKNOS project were codified as law applying to several response organizations (e.g. several different firefighting organiza-tions in Germany, cf. FwDV 100 [fwd]) or that have been adapted by other organizations (cf. DRK-DV 100 of the German Red Cross [Rot00]). In this case, they deal with very generic aspects of organizational structure and response in disasters.
When activities are conducted then there needs to be a way to track their progress. For instance, the fire fighter commander in the motivational example needs to keep track of the activities for protecting the residential area from the flood, for transporting injured fire fighters and the activities of the military. Tracking is also used to monitor deviations between the plan and what has been done. Furthermore, other activities – not anticipated in the plan or performed by others – need to be described in order to be coordinated. Whiteboards [WPT06, GC10, BCSR07, MPBW07, Dra03] can be used for this purpose, when people need to share a common overview of the activities. New technologies allow sharing of Whiteboards over wide geographical distances using the Internet. Since it is a shared artifact, access to it needs to be managed to prevent it becoming useless. For instance, in the case of several people wanting to adapt the content of the Whiteboard to the situation [MPBW07]. Whiteboards only have an information sharing function.
Second problem : Coordination by People of Different Organizations
On the inter-organizational level we need to consider coordination by people of auto-nomous organizations. This means that not all information can be shared with everybody. This leads to different partial views on the situation. Current tools used for coordination also have limitations in this case : all information, such as who are the receivers of infor-mation related to an activity, is hidden in different unrelated messages, which may even contain conflicting information. This can also potentially limit coordination effectiveness, because it is difficult for the users to have a partial shared view on the activities and their relations.
When we go back to the second part of the motivational example, we can identify seve-ral issues arising in this context. For example, what happens if the fire fighter commander decides not to protect the residential area from the flood anymore ? He has to inform the military that filling and transporting of sandbags is not needed anymore, otherwise they arrive at the disaster site without any use for them and they could be more useful at other sites. The fire fighter commander may also need to inform the police about this, so that the area is evacuated by them. He may also want to inform other organizations, such as Red Cross, because they may treat people in the residential area. Later, the fire fighter commander may evaluate the situation differently and he decides to protect the residential area from the flood. This has an effect on the evacuation and other processes. Although this is a simplified example, this means that a lot of messages are sent around and some of them even may conflict. For instance, protection of residential area is given up, but then later it is picked up again.
This can lead to confusion of the different organizations involved. For example, one organization may only read the message that protection of residential area is given up and take appropriate actions without considering the follow-up message that the residential area is again to be protected from the flood. Some organizations may also not be informed, e.g. the fire fighter commander forgets to notify the Red Cross that the protection of the residential area has been given up. The problem here is to synchronize the information about activities. Nevertheless, not everything what is currently going on is shared with everybody. For example, the police won’t disclose information about crime investigation related to plundering in the area.
We argue that information system support can help to relate activities of different organizations taking into account that not everything about the activities is shared with everybody. It can thus support creating a partial shared common view on the activities and their relations by the different organizations.
Coordination of Activities in Dynamic Situations
We present in this section four different categories of approaches related to coor-dination of activities in dynamic situations : process-based coordination, artifact-based coordination, rule-based coordination and combinations of them. Process-based coordina-tion is used to make relations between activities explicit by specifying their control-flow. Artifact-based coordination can be compared to coordination of activities mediated via a business artifact (cf. also [Bar98, Bar00]), i.e. the relations between activities are mode-led explicitly between activities and an artifact (e.g. an invoice). Rule-based coordination is used for defining relations between activities implicitly as a set of rules that should be followed during execution of activities. Finally, all these approaches can be combined together in several ways.
We categorize different technical solutions according to their main focus. All the ap-proaches are illustrated via an example from the business domain, because they have been developed primarily for supporting business operations. We discuss advantages and limi-tations of these approaches from the perspective of coordination of activities in dynamic situations given the disaster response context presented in the previous chapter.
Process-Based Coordination
Process-based coordination can be seen under the umbrella of business process ma-nagement [vdAtHW03]. The discipline of business process management is broad [Ham10, vBR10, LD98] and the focus here is its technical dimension. The activities in business processes can be managed and coordinated using a business process management sys-tem (BPMS) or workflow system [DHL01, vdAtHW03, OAWtH10]. The scope of these systems are operational routine business processes that have few predictable exceptions during process execution and the execution frequency of one process is high [DvdAtH05]. Examples for these types of processes are administrative processes, such as travel booking or approval processes.
Processes are fully specified in these systems from a control-flow, resource and data perspective. The control-flow makes the dependencies (relations) between activities expli-cit by describing activity sequences, e.g. activity “B” follows activity “A”. Each activity of the business process is part of a sequence. These sequences or parts of them may also be executed in parallel. Furthermore, alternative sequences can be described. A business process has a clear start and a clear end. The control-flow describes a full specification of all possible activity sequences of a business process. The resource perspective defines who is supposed to execute an activity. The data perspective describes the data that is processed by activities. A workflow system or process management system can support the coordination of a business process by executing automated activities in the process, assigning human resources to activities (asking them for input) and keeping track of the current execution state (what activities are currently executed and have been executed) according to the predefined business process model. More precisely, the process is enfor-ced by the system without possible deviations. The process models need to be correct, otherwise they cannot be coordinated properly by a workflow system.
Recently, the Object Management Group (OMG) published the Business Process Mo-deling Notation (BPMN) standard version 2.0. This standard describes how business processes could be modeled and executed within a workflow system [bpm]. Figure 3.1 illustrates an example for a process modeled using this standard : the loan management process. A customer requests a loan from the bank. The bank clerk enters some data about the loan. A decision is made, if there is a need for an extra check of the loan based on the data of the loan. An extra check means that a background check and history check of previous loans of the customer is initiated. This check is done by the credit bureau. In any case, the manager decides to approve or not approve the loan. The bank clerk has to finalize the loan application in the end.
However, the standard workflow approach is not seen as very flexible and drawbacks have been identified in different work contexts (cf. [BBS95, Gri00, BR10]). For example, the process model describing the relations between activities cannot be changed once the process has started. Furthermore, the process is enforced by the system. This makes coordination supported by workflow systems unsuitable for dynamic situations. This led to the development of a variety of approaches to support flexibility in the coordination of a process, but still based on the same idea of a fully specified process model describing sequential relations between activities (cf. Figure 3.1). These approaches may provide flexibility from a control-flow, data and resource perspective.
Flexible Process Management Systems
The ADEPT approach supports a wide range of extensions to address the limitations of the standard workflow approach [Rin04, DR09]. For example, it allows adding, removing or skipping activities during process execution. The main goal of this approach is to ensure data consistency when performing these operations. Another goal is that the process model remains syntactically correct (e.g. does not contain deadlocks) after performing these operations.
Grigori et al. optimize the scheduling of activities by anticipating which activities can be already executed given their preconditions [GCG01, Gri01]. Thus, it weakens the strict sequential order of activities by supporting overlapping execution of activities. The processing of data streams using a workflow system is similar [BP07, Bio08]. Although the main focus of these approaches is the data perspective, they allow more flexible definition of the relations between activities and can deal to a limited extent with shifting goals. For instance, it is already possible to review a document due to a deadline, although the document has not been completed.
Table of contents :
Chapitre 1 Introduction
1.1 Contributions
1.2 Thesis Outline
Chapitre 2 Context
2.1 Introduction
2.2 Coordination of Activities by People of Different Organizations in Dynamic Situations
2.2.1 Motivational Example : Coordination in the Disaster Response
2.2.2 Background : Disaster Response Management
2.2.3 Summary
2.3 Research Problems and Contributions
2.3.1 Problem Statement
2.3.2 Research Questions and Method
2.3.3 Publications
2.4 Conclusion
Chapitre 3 State of the Art
3.1 Introduction
3.2 Coordination of Activities in Dynamic Situations
3.2.1 Process-Based Coordination
3.2.2 Artifact-Based Coordination
3.2.3 Rule-Based Coordination
3.2.4 Integrated Approaches
3.2.5 Summary
3.3 Coordination by People of Different Organizations
3.4 Conclusion
Chapitre 4 Framework for Coordination of Activities
4.1 Introduction
4.2 Modeling Coordination of Activities
4.2.1 Activity Type
4.2.2 Activity
4.2.3 Temporal Dependency
4.2.4 Summary
4.3 Verification
4.3.1 Translation of a Model into a Temporal Constraint Network .
4.3.2 Checking Satisfiability of a Temporal Constraint Network Using State of the Art Algorithms
4.3.3 Performance Considerations
4.3.4 Summary
4.4 Detecting Deviations from the Model and How Activities Are Executed
4.4.1 Tracking Execution of Activities
4.4.2 Dependency Violation
4.4.3 Unsynchronized Dependencies
4.4.4 Summary
4.5 Example
4.6 Related Work
4.7 Conclusion
Chapitre 5 Inter-Organizational Coordination
5.1 Introduction
5.2 Sharing Activities between Organizations
5.2.1 Activity Workspace
5.2.2 Example for Sharing of Activities
5.2.3 Replicating Shared Activities in Different Activity Workspaces .
5.2.4 Summary
5.3 Verifying an Activity Workspace Containing Shared Activities
5.3.1 Problem Statement
5.3.2 Requirements for Verification
5.3.3 Discussion of Requirements
5.3.4 Protocol for Verification of an AW Containing Shared Activities
5.3.5 Summary
5.4 Detecting Deviations from the Model and How Shared Activities Are Executed
5.4.1 Tracking the Execution of Shared Activities
5.4.2 Conflicting State Changes of the Same Shared Activity
5.4.3 Conflicting Views on the Causal Order of State Changes of Dependent Shared Activities
5.4.4 Detecting Violation of Temporal Dependencies Involving Shared Activities
5.4.5 Detecting Unsynchronized Dependencies Involving Shared Activities
5.4.6 Incomplete Propagation of State Changes of a Shared Activity
5.4.7 Summary
5.5 Related Work
5.6 Conclusion
Chapitre 6 Implementation
6.1 Introduction
6.2 Main components
6.3 Integration into Google Wave TM
6.3.1 Preliminaries
6.3.2 Extension – Architecture
6.3.3 Extension : Persistence of ActivityWorkspaces and Replicating Shared Activities
6.3.4 Gadget – Graphical Modeling Tool
6.3.5 Robot – Distributed Coordination
6.4 Conclusion
Chapitre 7 Evaluation
7.1 Introduction
7.2 Interviews
7.2.1 Selected Comments
7.2.2 Discussion
7.3 Design of an Experiment
7.3.1 Design Details
7.3.2 Data Sources
7.3.3 Validation of the Experiment Design
7.3.4 Discussion
7.4 Conclusion
Chapitre 8 Conclusion and Perspectives
8.1 Contributions
8.2 Perspectives for Future Research
Annexe A Case Study Prototype
A.1 Modeling of Activities
A.2 Modeling of Dependencies
A.3 Sharing of Activities
A.4 State Change of Shared Activities and Dependency Violation
A.5 Concurrent State Changes of the Same Shared Activity
A.6 Verification
Annexe B Allen’s Path Consistency Method
Annexe C Dependency State Machines
Annexe D Acronyms
Annexe E R´esum´e de la Th`ese
Bibliographie
