hypermedia and groupware services are analyzed. One promising approach ... Different dependencies can be managed by different coordination mechanisms.
Towards Comprehensive and Flexible Coordination Support for Cooperative Processes: Software Architectures for Integrating Workflow, Hypermedia and Groupware Services Weigang Wang and Jörg M. Haake GMD – German National Research Center for Information Technology Integrated Publication and Information Systems Institute (IPSI) {wwang | haake}@gmd.darmstadt.de Abstract Efficient cooperation relies on good coordination. Individually, existing workflow, hypermedia, and groupware systems can only manage some types of dependency between activities. Furthermore, these systems provide either formal or informal mechanisms for coordination. We argue that comprehensive and flexible coordination support is needed to manage all types of dependency and to cover the whole spectrum of informal and formal coordination mechanisms. In this paper, possible architectures for integrating workflow, hypermedia and groupware services are analyzed. One promising approach to provide such integrated coordination support is to implement cooperative hypermedia upon a shared information space, and to integrate workflow semantics into cooperative hypermedia. A suitable architecture for such integrated coordination support is identified. A prototype system (CHIPS) based on the architecture is described. Keywords: Software architecture, workflow, process, hypermedia, groupware, coordination, and integration Introduction Business and scientific activities often occur in a group context. Through cooperation, higher productivity and better quality may be achieved with the multiple perspectives applied and the expertise pooled together. While working together does not always guarantee performance advantage, good coordination is the key to achieving efficient cooperation. Coordination is the act of working together harmoniously and coordination theory deals with how dependencies among activities can be managed [5]. There must be some actors performing some activities, which are directed towards some ends or goals. If there is no dependency, there is nothing to coordinate. Basic Dependency Types Malone’ group at MIT has identified three basic types of dependencies: flow, fit, and sharing [6]. Flow dependencies arise whenever one activity produces a resource that is used by another activity. Fit dependencies arise when multiple activities collectively produce a single resource. Sharing dependencies occur whenever multiple activities all use the same resource. All other dependency types are considered as the combination or the specialization of these basic ones. Different dependencies can be managed by different coordination mechanisms. Flow dependencies are the focus of existing process mapping techniques. When the product is information, the fit dependencies can be managed by means of some meta data, such as schemas (or DTD) and templates. Sharing dependencies can be managed by a variety of mechanisms such as concurrency control and access control mechanisms.
Types of Coordination Mechanisms Coordination mechanisms can be classified into three categories in terms of their formalities (i.e., from human in control for managing implicit dependencies to computer in control for managing explicit dependencies): On the one extreme are informal coordination means. This kind of coordination is initiated by individual people using either direct communication tools (such as audio/video and email) or indirect communication means (such as communication through shared artifacts) on an ad hoc basis. On the other extreme are formal coordination mechanisms, such as workflow and floor control techniques, which put computer in control. Here computer control relies on explicitly defined dependencies. In between of the extremes are semi-formal coordination mechanisms, such as role-based and mediator-based approaches. In the role-based approach, dependencies are loosely defined in organization regulations on specifying role-based splitting of jobs. For instance, a conference program committee member is supposed to know what to do and with whom to communicate. The coordination responsibility is distributed among people taking these roles. In the mediator-based approach, coordination is facilitated using a centralized approach. Job regulations are encoded in scripts that a mediator agent uses to direct flow of information, or a human mediator (such as a person who chairs a meeting) may coordinate based on his understanding of the regulations. A Scenario The following scenario provides an overview of how different coordination mechanisms might work for a cooperative process. One of the major business activities of the XYZ Company is the production of project proposals (offers). Typically, an offer-preparing process is initiated by the arrival of a relevant call for tender. As a first step, a brainstorming phase starts to generate essential ideas of the proposal. Then an outlining phase decides a proposal production process and a proposal template for its production. Based on the process structure and template, jobs (parts of the document) are allocated to team members. Then, team members work alone or cooperatively to complete their allocated parts. When all parts are completed, managers and engineers may make comments and modify the document. Finally managers fill some administrative entries, approve and send the document. Brainstorming is an unstructured task. Informal coordination means, such as a shared white board can be used for team members to sketch their ideas. Outlining starts as an unstructured task and overtime structures emerge, which can then be turned into a process
definition and a document template as formal coordination mechanisms. Parts of the document can be allocated to team members based on the roles they are taking. During the execution of the process, modification to the process structure (including schedule, job allocation, and the access permission for the roles to certain steps or certain parts of the document) may be needed to couple with changing situations. When such modification occurs, the process structure once as coordination medium is switched back to the content of the cooperative work. The control and data flow from one step to anther may be triggered by the time schedule automatically. Alternatively, a human mediator may take the responsibility to moderate the progress manually. Based on the process and template structure, the parts done by different team members can fit into an integral document. Need for Comprehensive and Flexible Coordination The proper coordination mechanisms for a task (process) correspond to the dependencies involved and the structure of the task at hand. In general, the more explicitly a task is structured the more formal the coordination mechanisms should be.
the whole range of informal-formal coordination mechanisms is required. In short, there is a gap in current coordination support. An integration of workflow, hypermedia, and groupware services may offer a solution to bridge this gap, and thereby to meet the need for comprehensive and flexible coordination. The remainder of the paper is organized as follows: in section 2, possible integration architectures are analyzed and a suitable architecture for our purpose is identified. Section 3 describes a prototype system based on the identified architecture and introduces the techniques that allow for the desired flexibility. Section 4 presents conclusions and future work.
Analysis of Architectural Approaches Figure 1 shows various layered architectures to integrate workflow, hypermedia, and groupware service components. On top of them is supposed to be a user interface component (not shown in the figure). In the following, first, the three architectural components are explained. Then different architectures consisting of these components are analyzed and a suitable architecture for our purpose is proposed.
In practice, tasks (or processes) often have some structured subtasks and some less structured subtasks. The structure of a task (or its subtasks) may change over time. Different tasks (subtasks) may involve one or more basic dependency types or different combination of the basic dependency types. Therefore, coordination support that can comprehensively manage all the dependency types and that can flexibly cover the whole spectrum of informal and formal coordination mechanisms is needed. Only with such support, a set of discrete tasks and their corresponding coordination mechanisms can be integrated into a wellcoordinated cooperative process orchestrating team members towards a common goal. Problem Analysis on Current Coordination Support The target domain of our analysis is information systems for business and scientific workers whose work items (or products) are information objects (documents or hyperdocuments). In terms of dependency types, flow dependencies can be managed by workflow systems. Fit dependency management can be supported by typed hypermedia systems with schema and template capabilities. Sharing dependencies can be managed by the shared information space of groupware systems. However, a system that can offer comprehensive support for all the dependency types and all their possible combinations is still missing. Informal and semi-formal coordination mechanisms can be provided by groupware systems (including cooperative hypermedia systems). However, these systems usually lack the support for more formal coordination. The more formal coordination mechanisms are provided by workflow management systems, but workflow management systems generally lack the support for informal coordination. A flexible system that can provide
Figure 1. Architectures for integration Groupware is often used as a general term referring to any system for computer-supported cooperative work. In this regard, many workflow and hypermedia systems are also groupware. To avoid terminology confusion, in this paper, another term 'groupware service' is used to refer to the essential services that make a system groupware. The groupware service component provides a shared information space for basic information accessing, sharing and exchanging. It provides a group context and offers group awareness and notification support for team members to coordinate their work. It also provides an interaction environment (i.e., various kinds of sessions) for on-line collaborators to focus on a particular part of the information space. The hypermedia service component provides flexible means to create, manage, and utilize multimedia information organized into graph structures. Traditional linear documents can be considered as a special case of hypermedia.
The workflow service component handles planning, scheduling, and controlled execution of activities that are performed by a team. The need and potential benefit for integrated support is often coincidentally identified by workflow, hypertext, and CSCW communities. However, each community often tends to use its own system as a basis of the integration. Hypermedia Service as a Basis The integration architectures illustrated by Figure 1 (a) and (b) are seen in some systems created in the hypermedia community. The architecture of Figure 1 (a) has been used to extend single-user hypermedia systems to multi-user systems by adding a session management service to a hypermedia service layer. Examples are KMS [1] and NoteCards [13]. To our knowledge, there are no full-fledged workflow systems based on the architectures in Figure 1 (a) or (b). However, some workflow-like features, such as guided tour [7], story boarding [4], and token passing [2] have been integrated in some hypermedia systems for computer-controlled navigation or process simulation. As the groupware service is built on the hypermedia service, usually only some portions of hypermedia data and services can be offered for sharing. The systems based on these architectures may be sufficient for some simple asynchronous cooperation. They are usually limited for synchronous cooperation. Situations that need to have more shared aspects at real-time or to have tighter coupling of shared behaviors are difficult to achieve. This reduces flexibility. Workflow Service as a Basis This approach is often taken by the workflow community. Similar to the hypermedia at bottom cases, their cooperation support is limited. Hypermedia links are incorporated to access background information. Groupware tools are used for some shared activities in a workflow process, while the process of defining workflow schemata is not shared. Workflow process definitions are still created by individual users. This approach is for example suitable for coordinating activities that are carried out in heterogeneous environments. Groupware Service as a Basis This approach is often taken by the CSCW community. With a shared information space as a basis, the potential for shared aspects is unlimited. Figure 1 (e) describes a cooperative workflow system with embedded hypertext referential links. This allows integration of background information, but still no highlevel hypertext structures, such as composite nodes, are offered. The main problem of this approach lies in its strict separation of workflow structures and the artifacts on which the workflow operates. Only the latter is represented by the hypertext. Figure 1 (f) shows a cooperative hypermedia system built on a shared information space and using high-level hypermedia structures to model processes. Both
hypermedia and workflow structures are shared. Hypermedia schema and templates can be extended for workflow definitions. This is the most flexible approach among the six. Alternatives The above analysis focuses on the layered relationship among the three components, i.e., which component is more general or fundamental, and thereby should be placed at a deeper layer for others to build on. It can be noticed that the structures as illustrated by Figure 1 are strictly layered ones. Only the services of their top layer components are available. This, for many applications, is too much restrictive. Figure 2 (a) (c) (e) show alternative nested architectures, in which in addition to integrated services some original services of some layers are also accessible from user interface. Figure 2 (b) (d) (f) depict some other alternative architectures that have tighter integration that may blur the division between some layers. More alternatives may be observed when different implementation technologies are used. For instance, the bottom-up integration of the three blocks may constitute a class hierarchy and the integrated services are provided in one computing process. Alternatively, between layers may be a client-server relationship or the layers work together using a component-based approach, with the possibility to have multiple variant components at each layer.
Figure 2. Alternatives The most suitable integration architecture that matches our requirements might be a combination of Figure 1 (f), Figure 2 (c) and Figure 2 (d). This combination offers the advantage of Figure 1 (f) and it makes the groupware and cooperative hypermedia services directly available. Thus, high-level hypermedia structures can be offered, workflow structure and hypermedia structure can coexist, and they can be transformed into each other. The basis of the architecture is a groupware service layer (a shared information space), which can be created using any good cooperative application platform. An implementation of this approach is presented in the next section.
The CHIPS System To test our proposed approach, a prototype system (CHIPS) has been implemented. CHIPS stands for Cooperative Hypermedia Integrated with Process Support [3, 16].
CHIPS Architecture and Techniques The CHIPS architecture is illustrated by Figure 3. At the bottom is a groupware service layer, which provides means for representing shared artifacts and maintaining consistent replicas and accessing shared objects. Most of the shared objects at this layer are primitive objects for composing higher level objects at a higher layer. There are also some shared objects, such as persistent session objects, directly accessible from an application’s user interface. This layer is built on our COAST cooperative application toolkit [11].
Figure 3. Architecture of the CHIPS system Using these groupware services, the hypermedia structure service provides shared hypermedia objects. Together, these two layers enable the provision of cooperative hypermedia. Task-specific semantics (attributes and operations) can be attached or removed from hypermedia objects. In this way, this layer becomes a cooperative hypermedia based activity space [12, 15], that supports various high-level hypermedia-based task-specific knowledge structures. In our approach to more formal coordination, a process space is created based on the activity space layer. This process space (3rd Layer) provides flexible process support services. By incorporating process computational semantics (as a special kind of task-specific computational semantics) into the hypermedia data model, workflow-like coordination can be provided. Using the objects provided by these layers, application specific session objects register the participating users of a session, define the coupling of the shared aspects of participating browsers, and provide a user interface for manipulating shared object spaces. The implementation of the CHIPS system takes an objectoriented approach, which maps the architecture to a class hierarchy (bottom-up). Services provided at a lower layer are inherited and/or modified at a higher layer. A common model for hypermedia structure service and workflow service is developed. Workflow process structures are represented as hypermedia structures (composite nodes) with workflow related computational semantics (such as time and state attributes for task nodes, and date flow and control flow computations for process links) [16]. To make this possible, the attribute list, the computation attachment technique, the object prototype technique and the example-based schema definition method are used [15, 16]. The attribute list and computation attachment techniques allow task-specific
computational semantics to be added to or removed from an object, for instance, to change a hypermedia node to a workflow task node and vise verse. The object prototype technique allows to create new object instance from an existing object instance and to inherit some of attribute values from the existing object. This makes it possible to define new object types (prototypes) or to change object behaviors that are local to an object instance or global for all instances of the same type at run-time. The examplebased schema definition method allows users to define new document types or process templates by sketching example documents [15]. Cooperative Session Browsers CHIPS provides different cooperative hypermedia browsers to enable groups to define activity space schemas (e.g. for shared information spaces, tasks and processes) and to execute group processes. A short description of the most important tools of the CHIPS system is given in the following. A cooperative schema editor allows users to define task or process schemas by crafting an example structure. After the example is created, a schema is automatically created by the system. Users can create an activity space instance directly from the schema. Alternatively, they can use a copy-as-template function to create a properly initialized copy of the whole example. Another cooperative tool is the so-called flexible editor, which switches off constraint checking and allows unconstrained manipulation of the hypermedia structure. This is an important feature since it facilitates the definition of emergent structure. For example, a process structure can be created gradually with continuous modifications, until a desired emergent pattern appears. Then this process pattern can be turned into a process definition that is used to create new instances or to replace an existing process definition that is identified to be inadequate. An activity space browser is used to instantiate, modify, and enact processes. With it, users can navigate through the hypermedia workspace, modify it, and activate tasks ready for enactment. Once a task node is enabled, the corresponding input objects are provided by the system and users can modify the content cooperatively. In addition, it is possible for users to switch back into process definition mode if they feel the necessity. They can modify the process structure if they have the necessary access permissions. The system takes a role-based approach to access control. The essence of role-based access control is that permissions are assigned to roles rather than to individual users. Users acquire these permissions by virtue of being assigned membership in appropriate roles. In CHIPS, the user authorization is specified using two independent tools: an editor that assigns users to roles and a dialogue box which assigns access permission for objects to roles. The tool for permission-role assignment can be activated upon any objects presented in the above-described browsers.
Comprehensiveness of Dependency Management The `flow dependency’ management as a formal coordination mechanism is supported by activity spaces with process semantics. The `fit dependency’ can be managed by means of hypermedia schema and templates or any document structures cooperators agree. Because these structures make the relationship between the parts and the whole of a document (or a process structure) explicit. Sharing dependency management and the informal coordination means are supported by groupware services such as the coupling of some behaviors between cooperative browsers (such as shared scrollbar) and the access control and concurrency control on shared workspace. Access control helps to specify the range of sharing (private space for individuals, group space for people taking certain roles or public space for all). The required access permission to a workspace may change over time. This can be supported by specifying different access permissions to different workflow steps (task nodes) for that workspace (the content of the task nodes). To have fine-grained `sharing dependency’ management, in CHIPS, access control can be applied to any addressable object and its operations. Concurrency control supports more fine-grained management of the sharing dependencies in real time. Flexibility in Combining and Switching Mechanisms With the flexible modeling (schema definition) capabilities of the system, activity spaces with different combination of the workflow, hypermedia and groupware services can be defined. The CHIPS system deals with processes and information structures as two views on a unified data model. This enables smooth transitions between these two views, and supports cooperative work on defining and manipulating process and information structures. The hypermedia representation of processes, especially the composite structure of nested nodes with their own content structures can provide different coordination support for differently structured subtasks. The possibility to transform between hypermedia with and without process computational semantics supports emerging process structures and the adaptation of the existing process structures. Many application examples of the CHIPS system are provided in [3, 16]. To show the time-based nature of the flexible process support, a series of screen pictures is given at our web site (http://www.darmstadt.gmd.de/concert/projects/chips.htm l). Readers with a PC can access a ScreenCam movie to see CHIPS at work.
Related Work The generic process approach to coordination support of [6] is very similar to our activity space based process support. Both of them provide a set of inheritable building blocks for tailored coordination support. While Malone’s work provides a general and theoretical foundation for coordination support, our work focuses on concrete software environment for coordination support.
Open hypermedia systems aim at opening hypermedia services to any system that understand the standard protocols of these services. Their architecture resembles the CHIPS architecture, with shared hyperbase components at bottom, hypermedia structure service components in the middle, and client applications on the top [9]. The hypermedia based workflow service is proposed as one of such hypermedia structure services. Proposals are also made for adding session management to the hypermedia structure service. It remains to be seen if the hyperbase layer can serve as a shared information space that is sufficient for implementing the kind of flexible coordination mechanisms proposed in this paper. There have been many development efforts on merging workflow and groupware [8]. The basic approach taken by the workflow community is to add some groupware services to existing workflow systems for informal coordination or exception handling [10], such as the recent work in the Exotica project to integrate FlowMark and Notes [8]. In some of such integrated systems, embedded hypertext links are used for accessing background information. The CHIPS system integrates process support capabilities (i.e., more formal coordination support) into cooperative hypermedia. This approach leads to a system dealing with process structures and information structures as two views on a unified data model, permitting smooth transitions between these two views. Unlike an extended workflow system, which still maintains the strict separation between process and document data, such a system can provide much more flexibility.
Conclusion and Future Work There is gap in current coordination support. This is reflected in the incomprehensive capability for handling all the basic dependency types and their combinations, and the lack of flexibility to cover the whole range of informal and formal mechanisms. The integration of workflow, hypermedia, and groupware services can bridge the gap. To have more comprehensive coordination support, cooperative hypermedia systems and cooperative workflow systems should be built upon a shared information space. To have more flexible coordination support, the integration of hypermedia and workflow systems should be based on cooperative hypermedia. A promising architecture for integrating workflow, hypermedia, and groupware services is the one we employed for the CHIPS system. One lesson learned from our analysis is that flexible coordination support can not be implemented as add-ons. A shared information space should be considered as a basis of any flexible cooperative systems. Next, we plan to transfer our shared information space into a Web-based shared information space. We will develop an interchange format (a generic XML DTD [14]) for our cooperative hypermedia-based activity space data model. We will develop a set of Web-based session browsers to access our hypermedia based activity space. In this way, we will make the CHIPS-like system widely accessible to the real world.
References 1.
2.
3.
4.
5.
6.
7.
Akscyn, R., McCracken, D., and Yoder, E. KMS: A distributed hypermedia system for managing knowledge in organizations. In Commu. of the ACM, 31, 7, (1988), 820-835 Furuta, R., and Stotts, D. Interpreted collaboration protocols and their use in groupware prototyping. In Proc. of ACM CSCW'94 (Oct., 1994), pp. 121-313 Haake, M.J. and Wang, W. Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support, Proceedings of ACM SIGGroup Group'97, pp. 341-350, Nov. 1997 Harada, K., Tanaka, E., Ogawa, R., and Hara, Y. Anecdote: A multimedia storyboarding system with seamless authoring support., Proc. of ACM Multimedia'96, (Nov., 1996), pp. 341-351 Malone, T., and Crowston, K What is coordination theory and how can it help design cooperative work systems? In Proc. of CSCW'90 (1990), pp.357-370 Malone, T., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., J. Quimby, J., Osborne, C., and A. Bernstein, A. Tools for inventing organizations: Toward a handbook of organizational processes, (January 1997), Accessible at http://ccs.mit.edu/ccswp198 Marshall, C. C., and Irish, P. M. Guided tours and online presentations: How authors make existing hypertext intelligible for readers. In ACM Hypertext’89 Proceedings (1989), pp. 15-26
8.
Mohan, C. Tutorial: State of the art in workflow management research and products. In a tutorial presented at ACM SIGMOD’96, (June 1996)
9.
Nürnberg, P. J., Leggett, J. J., and Wiil, U. K.. 1998. A research agenda for open hypermedia. Proceedings of ACM Hypertext'98
10. Nutt, G. The evolution towards flexible workflow systems. Distributed Systems Engineering Journal, Special Issue On Workflow Systems, 3, 4 (Dec., 1996), 276-294 11. Schuckmann, C., Schümmer, J., Kirchner, L., and Haake, J. Designing object-oriented synchronours groupware with COAST. In Proceedings of ACM CSCW’96 (Nov. 1996), pp. 30-38 12. Streitz, N., Haake, J., Hannemann, J., Lemke, A., Schuler, W., Schutt, H., and Thüring, M. SEPIA: a cooperative hypermedia authoring environment. In Proceedings of ACM Hypertext’92 (1992), pp. 11-22 13. Trigg, R., Suchman, L., and Halasz, F. Supporting collaboration in Notecards. In Proc. of CSCW'86 (Dec., 1986), pp.1-10 14. W3C. World Wide Web Consortium home page. (1998), Available via http://www.w3.org/ 15. Wang, W. and Haake, M.J. Supporting User-defined Activity Spaces Proceedings of ACM Hypertext'97 pp 112-12, April, 1997 16. Wang, W. and Haake M.J. Flexible Coordination with Cooperative Hypermedia, Proceedings of ACM Hypertext'98, pp. 245-255, June, 1998
