R&D3, and a last one in building construction and design at CUI4), in ... team by formalizing a process to reach an objective and then enacting it. Figure 1. .... unstructured data, as critical events for notification are, ... Finally, both parties agree on the idea that no approach .... one hand explain process monitoring decisions to.
Asynchronous Coordination of Virtual Teams in Creative Applications (co-design or co-engineering) :Requirements and Design Criteria. C. Godart, C. Bouthier, P. Canalda, F. Charoy, P. Molli, 0. Perrin LORIA-INRLA, Campus Scientifique, BP239, 54506 Vandoeuvre. France
H. Saliou
J.C. Bignon, G. Halin, 0. Malcurat
France Telecom R&D, Lannion, France
Crai, 2, rue Bastien Lepage, 54001 Nancy, France
objective is to define a model of cooperative work allowing the partners of a building construction to coordinate their efforts in an efficient way. We are mainly interested in building constructions of middle size, which implicate several small and middle size enterprises (SME). Such enterprises cannot afford the cost of outsourced plan armor, process management, and other services as currently offered, and as a consequence are hardly interested in using new and lower cost technology, like Internet, to support their interconnections. The paper is organized as follows. Section 2 makes some hypothesis on the organization of cooperation in a virtual team. Section 3 discusses the concept of coordination to introduce the idea that a good coordination is a subtle mixture of explicit coordination, which supposes explicit process modeling and enforcement, and implicit coordination, which supposes auto-coordination, based on group awareness. Section 4 provides requirements and design criteria for these two dimensions and their integration. Finally, section 5 concludes.
Abstract This paper reports on asynchronous coordination of a virtual team in a virtual enterprise. It confronts two approaches : explicit coordination based on explicit process modeling, and implicit coordination, based on group awareness, to finally conclude that a good coordination is a subtle mixture of both approaches. For each approach and for the combination of both, requirements and design criteria are given and a study of the state of the art is done.
Keywords :coordination, workflow, awareness, virtual team, virtual enterprise
1. Introduction This paper reports on the thoughts of a virtual team', composed of three research teams (one in computing at LORIA', one in telecommunications at France Telecom R&D3, and a last one in building construction and design at CUI4), in a common project about virtual team coordination. More precisely, the topic of this project is the coordination of a virtual team in the context of a virtual enterprise' in the field of building construction, and the
2. Initial hypotheses Our objective is the coordination of Virtual Teams. As advocated above, we are particularly interested in coordination in the context of SMEs, which communicate through Internet for co-conception andlor cooperative engineering applications purposes. This section provides the basic concepts on which ow cooperation model is organized : object sharing, explicit coordination and implicit coordination.
' A Virtual Team is a group of people distributed in space and time. LORIA : Laboratory of Research in Computer Sciences and its Applications (http://www.loria.fr) France Telecom R&D : France Telecom Research & Development CRAI : Research Center in Architecture and Engineering (http://www.crai.archi.fr) A Virtual Enterprise is a virtual team distributed in organizations.
0-7695-0960-6/01 $10.00 0 2001 IEEE
This work is partially sponsored by France Telecom R&D (CTI No 98 1B 124) and CNRS and Region Lorraine (BDI grant).
135
Explicit coordination makes the hypothesis that it is possible to coordinate a virtual team by formalizing a process to reach an objective and then enacting it.
Figure 1. Explicit coordination Quickly at the beginning of the project, everybody agreed on the central role of object sharing, and especially document sharing, for team coordination. Complementary, two main approaches was brought to the fore: on the one hand, explicit (and directive) coordination which supposes explicit process modeling and enforcement and on the other hand implicit (and permissive) coordination which supposes auto-coordination, based on some kind of group awareness. Thus, our initial hypotheses were: the exchange of documents (form, texts, forms, pictures, code sources ...) and the exchange of information about documents are essential ingredients of virtual teams coordination. These documents are either stored in cooperation spaces shared between partners, or in workspaces when they are being modified by one or several partners. To modify a document, a partner checks it out of a shared space into its proper workspace. To make visible a modification, it checks the modified document fiom its workspace into a shared space. Of cause, object space managers must provide partners with effective concurrency control, partners of a Virtual Team (can) coordinate by agreeing on a explicit process model, which defines activities and activities synchronization (i.e., a workflow), and by enforcing the respect of this process. These activities access existing documents as input and modify and create documents as output. That is what we call in this paper explicit coordination (cf. Figure 1. Explicit
punctuates the life of documents, such as creation, versioning, merging, access, access tentative, transfer fiom a shared space to a workspace, or reciprocally ... The idea is that this awareness induces actions (edition of document, discussions,. ..) which allow partners autocoordination. That is what we call implicit Coordination (cf. Figure 2. Implicit coordination). We had a priori no global preference for the fvst approach or the other (even if the position of partisans of the two different approaches were initially rather antagonistic). We considered that they corresponded to two distinct management approaches. And our initial objective was to study each approach, from the point of view of efficiency and acceptability, first of all individually, and second comparativelyto each other.
coordination).
partners of a Virtual Team (can) coordinate themselves by notifying the principal events which 136
Feedback
/ \ direct synchronous document exchange ... auto-coordination
Implicit coordination makes the hypothesis that good group awareness, due to the communication about the objective it generates is sufficient to assume auto-coordinationof a virtual team.
Figure 2. Implicit coordination
3. Explicit coordination
coordination
vs.
implicit
0
0
3.1. At the very beginning, the points of view were very contrasted and the partisans of the two
a good knowledge of the work in progress and an effective process tracking, effective capitalization of the know-how and reuse from a project to another.
Pro implicit coordination position. Partisans of implicit, or auto-,coordination had also some good arguments. Implicit coordination approach : does not allow an important investment in modeling, even if critical events, on which awareness is based, have to be described, 0 is dynamic and flexible (as process are not really modeled, they can be changed easily), 0 better fits the current way people work, 0 does not request an enterprise to make visible its know-how to cooperate with another, 0 is a good anti-stress for the SME responsible managers connected to Internet, especially if awareness is based on group communication.
approaches had really antagonistic positions. Partisans of explicit coordination said that it is not realistic to want to coordinate a large-scale process implicating potentially tenth or more partners and tenths of participants without a strict process. At the opposite, partners of implicit coordination said that autocoordination based on a good awareness is sufficient and that explicit process enforcement can be disturbing and subsequently would not be accepted. And this was not matter of origin. We found partisans of both approaches in the different communities: computing, telecommunications and architecture. In fact both parties had good arguments.
Reciprocally, they argued that process modeling approach : 0 requests apriori an important modeling effort, 0 is not currently efficient to manage the subtlety of interactions as they occur in creative applications, hence risks to lead to rigid processes which either will be rejected, or break the synergy yet existing on building sites, 0 is not currently efficient to support interoperability of processes, 0 can be felt as “Big Brother Watching YOU”and increases the stress of people,
Pro explicit coordination position. Partisans of explicit coordination explains that process modeling : already exists, has proved efficiency in work coordination, 0 is an efficient way for enterprise to capitalize their know-how and to resist to market evolution, 0 allows enterprises to interoperate by interconnectingtheir processes, is supported by workflow systems that allow for graphical process modeling, process enactment and process tracking. Reciprocally, they pointed out that auto-coordination cannot allow :
137
0
much information, and information management become itself a stress cause. At the opposite, a good workflow can allow the intemet-user, alone in its office, to feel the presence of some authority and provide him a feeling of security.
imposes SME to make “public” their processes what they cannot accept due to the coopetitive6 context of the market: two enterprises cooperating in a project can be in competition in another at the same time or in the future.
Feedback
---_
5 .
\\.‘.
Discussion, direct synchronous document exchange ... auto-coordination
0A coordination based both on explicit and implicit coordination seems a good way to synthesize the need of, respectively, supervision and free initiative.
Figure 3. integrated coordination
3.2. Fortunately, with time, positions evolved and
Evolution of explicit Coordination partisans position.
became less conflicting.
Partisans of explicit coordination recognized that: 0 current workflow models, if they are efficient when applied to production or administrative applications, are less effective when applied to creative applications as co-design and coengineering ones can be, 0 partners of a virtual enterprise hesitate to make public the details of their processes, what limits also the potential of current workflow models, awareness, and information in general, is a good anti-stress medicine for the internet-user alone in front of its computer.
Partisans of explicit coordination accepted some criticism of partisans of implicit coordination and recognized some qualities to this approach. And reciprocally.
Evolution of implicit coordination partisans position. Partisans of implicit coordination recognized that: 0 although workflows are constraining, it is good to have a guide in a large-scale project. One can observe, at the end of a project, that the following conclusion if often made : “it would have been good to have a written process to guide the project all along its duration”, 0 it is difficult to manage a large amount of unstructured data, as critical events for notification are, 0 notification and group awareness are not a so good anti-stress as it can appear at a first glance: too ~
3.3. Conclusion Finally, both parties agree on the idea that no approach alone can fulfill the requirements of good coordination: a good coordination is a subtle mixture of explicit and implicit coordination. If this approach increases the probability of acceptance by end users, it also introduces a new domain of
~~
Copetitive : cooperating and in competition at the same time.
138
(event management, groupware communication tools ...) and their combination. These services mostly already exist, but are dispersed and implemented into, either various systems which cannot easily interoperate, or high cost dedicated systems. They must be integrated and presented in a homogeneous way
investigation : the relationship between both dimensions of asynchronous coordination.
4. Requirements and design criteria for asynchronous coordination In this section, we deepen the requirements, propose design criteria and quickly analyze the current sate of the art for each component of coordination enlighten above (shared and work spaces, explicit coordination, and implicit coordination). We also deepen the relationship between explicit and implicit coordination and provide some research hints.
State of the art. Numerous solutions exist to store files and objects shared in the context of virtual teams and virtual enterprises. As we introduced above, we place us in the context of SME who want to cooperate over Internet. Thus, we limit our analysis here to lightweight solutions and we do not consider heavy software like Data Base Management Systems, heavy Version and Configuration Management Systems or specialized Software like Plan Armors in the domain of building construction. Nevertheless, a lot of responses exist on Internet : Teamscope [2], SourceForge [3], BSCW [4], CVS with Thinderbox and Bugzilla [5] ... Most of them provide an effective way to share files over Internet and in general, they provide additional integrated groupware tools. Without entering in the detail of each system, we can consider that no system provide all the services basically required for an integrated coordination of a virtual team. As example, one system is missing an efficient version management, when another is missing an easy to use user interface. Moreover, we think that all these systems are missing an efficient event manager. Consistency is also weakly supported. We can also underline a lack of standardization,even if an initiative like WebDav [ 6 ] ,if it succeeds, acts in the right direction.
4.1. Shared spaces and work spaces management Requirements and design criteria : Spaces must store files to allow users to continue to work with their favorite tools. The unit of storage and retrieval is the file. This does not
prevent to use a (relational or object) database system, but the interface between database management system and file management system must be as transparent as possible to users, Version management is essential in the applications we consider. File is the unit of versioning. In this context, a shared space or a workspace is a view of one or several graphs of versions. check+ check-out model [ 11 is a good basis to manage exchange between shared and work spaces. Partners need to preserve their autonomy and confidentiality. At least efficient obligatory and
discretionary access rights must be provided and controlled. Distinguishing between shared and work spaces also contribute to this objective. Event management in association with version management is essential for efficient notification and group awareness. Mechanisms to manage consistency of sharedfiles are required. These mechanisms must be as simple to use as current transactions while allowing the flexibility requested by the applications we consider.
4.2. Explicit coordination Our point of view is that the workflow approach and current workflow systems are a good starting point, but need some adaptations to take into account the applicationswe target.
Requirements and design criteria : a process as a combination of process fiagments. Our experience points out that it is not realist to model large scale co-design and co-engineering processes as a whole, in a monolithic manner. Better is to allow process fragments modeling, each kagment corresponding to a point of view and/or a role ... and to provide means to combine such fragments in a coherent global process. This is especially true when modeling is ascending, integratingpre-existing processes existing.
Shared space managers must provide an adaptable easy to use user interface. Even the
more current primitive used in version management (check-in, commit ...) are difficult to integrate for most end-users. It is also matter of vocabulary. More generally, shared space managers should provide and integrate the basic mechanisms requested for implicit and explicit coordination
fragments of adaptive processes to manage diferent variants of the same initial process. Even
139
if modeling is done based on process fragments, it is not realistic to think to model everything a priori. In most cases, only tentative processes can be defined. Then these processes can be modified, adapted to specific situations, taking advantage of experience and experiments to better fit the reality of the work site. This is due to, on the one hand the complexity of the considered processes, and on the other hand to actual usage : typically, in building construction, dynamic evolution of processes and bypassing are current practices, fragments of abstract workjlows. Previous items argue in favor of process models with the ability, on the one hand to abstract concrete processes, on the other hand to detail, specialize, instanciate such abstract fi-agments. This requirement comes also from some applications in the context of virtual enterprises where some partners accept to make visible some aspects of their processes, but without too much details in order to preserve their processes fi-om concurrency spying. This argues also for the ability to generalize a concrete process in an abstract one. fragments of cooperative processes. The main WFMS define a process as a sequence of activities. A process is seen as a black box, able to exchange results (mainly documents) at the beginning and at the end of the process execution. This principle, by disallowing interactions between activities, is not consistent with the idea of co-design and concurrent engineering. It is necessary to surpass this boundary and to allow activities to exchange information when executing.
-'
0
A lot of standardization work has been done on this topic by workflow systems vendors [13]. This includes interoperability of workflow systems which is a first response to the need of process fiagmentation. Of course this work does not include the advanced topics we just make a list of and which are still in the domain of research.
4.3. Implicit coordination Requirements and design criteria : events and information to be notified must be structured. The applications we consider
implicates tenths of participants and hundreds of activities. Anybody cannot and must not be aware of anything. This is not only a problem of confidentiality as it can appear, this is mainly a problem of selectivity an quality of information : the right information must be transmitted to right person at the right time. 0
participants must be structured in communication and information groups. This is directly related to
the above issue. It is necessary to partition the set of participants in groups, based on their roles, their space of intervention ... Multi-membership, i.e. the possibility for one participant to be associated to several groups, is an essential component of communication and group interactions. divergence between participants must be measured and controlled. It is necessary to control
the disorder which may be introduced by the permissiveness of the approach and to maintain this disorder under an agreed limit. New measures must be developed: they can be grounded on version differences as calculated in version management systems, number of versions between this used by a user and the last one, number of shared objects between two participants, number of intermediate results used by a participant ...
orthogonal deJinition of processes and tools to implement activities. One fimdament of process
modeling and especially workflow models and systems is to abstract enterprise logic, description of activities chaining and synchronization from tools implementing activities. Of course, this principle applies also for co-design and coengineering applications.
State of the art. Implicit coordination is mainly based on awareness. Currently, a lot of tools provide awareness (typically tele-presence and a limited form of group management as in ICQ [14] or Yahoo [15]), but it is specific to the embedding tools. Some experimental toolkits exist but are still in the domain of research [ 161 and new research topics start, as example concerning divergence measurement [ 17, 181.
State of the art. A lot workflow products exist on the market [7]. They are widely used in a lot of applications, especially production and administrative application. However, as advocated above, current systems do not apply efficiently for creative application in general and co-design and co-engineering applications in particular. This is due to the needs we just introduced and which are currently studied by researchers: need of adaptability [8], need of abstraction [9, lo], need of interactivity [l 11. This is also related to the interoperability of electronic services [12]. 140
The list of requirements provided has not the ambition to be exhaustive, but to be representative of the problem. The same remark applies for the design criteria we propose. A general conclusion is that the problem of coordination of virtual teams and virtual enterprises is still an open research problem and for several years, even if some useful tools yet exist. The fact that tools yet exist is an opportunity that must be used to make experiments : we would not have been able to write this paper without interactions with potential end-users (architects in the context of our project). Finally, we do not want to conclude without some words conceming synchronous tools, which are important in the objective of team coordination. It is clear that there is a close relationship between synchronous coordination and asynchronous coordination, and especially, we think between synchronous coordination and implicit asynchronous coordination. This is due to the hypothesis of implicit coordination which relies on the idea that a good awareness will induce discussions which themselves will lead to autocoordination.
4.4. Relationship between explicit coordination and implicit coordination As we concluded in section 3, we think that a good coordination is a subtle mixture of explicit and implicit coordination. This implies to deepen how to take advantage of integrating these two dimensions. i.e. how to use one approach to fill the deficiencies of and to enhance the other.
Requirements and design criteria : Notification and awareness to connect process fragments. Implicit coordination can be seen as the
minimum mechanism to integrate process fragments. Especially, multi-membership communication groups can apply efficiently in this objective: a communication group can be created to interconnect two or more process fiagment. 0
Communication groups to bring closer process and process performers. administrators
Communication groups can be defined to, on the one hand explain process monitoring decisions to performers, on the other hand inform administrator on the degree of acceptance of current processes on working sites. Processes as a basis to structure information and communication groups. Communication groups can be organized based on activities, process fragments, roles as defined in workflow model and workflow organizational models. 0
6. Bibliography [I] P. Feiler, "Configuration Management Models in Commercial Environments CMUISEI-9 1-TR-7 ESD-9-TU-7, 1991. [2] Teamscope, http://cscw.msu. eddscope.html, . "
[3] Sourceforge, http://www.sourceforge.net, . [4] BSCW, "Basic Services for Cooperative Work",
Process awareness as a basis of implicit coordination. Process knowledge can be used to
http://bscw.gmd.deA. [5] Bugzilla, http://mozilla.org/tools.htm, . [6] WebDav, http://www.webdav.org, . [7] CP, " Workj7ow Commercial products': http://www.worylowsofiare. com, . [8] M. Reichert, and P. Dadam, "ADEPTflex - Supporting dynamic changes of workjlows without losing control",
improve awareness information quality. In particular, information conceming the state of processes is very useful to connect partners.
State of the art. In some way, most of Groupware tools yet integrate these dimensions, but in a very limited and specific way. As example process awareness in workflow systems thanks to to-dolists, and reciprocally to-do-lists embryo in email servers, enter in this category. At the level of research, we think that the study of the relationship between explicit and implicit coordination needs some specific and enthusiastic new research. The Orbit demonstration is good illustration of an experimental approach of this problem [ 191.
Intelligent Information Systems, 1998. 10: p. 93-129. [9] W.M.P. van der Aalst, "Howto handle dynamic change and capture management information", in 4th IFCIS IC on Cooperative Information Systems (CoopIS). 1999. Edimburgh,
Scotland. [ 101 H. Shuster, D. Georgakopoulos, A. Cichocki, and D. Baker,
"Modelingand composing service-based and reference processbased multi-enterpriseprocesses"2000. [I 11 C. Godart, 0. Perrin, and H. Skaf, "COO : a workj7ow operator to improve cooperationmodeling in virtual processes", in RIDE-VE (Research Issues in Data Engineering -Virtual Enterprises). 1999. Sydney, Australia. [121 tes2000. Technologiesfor E-Services. in VLDB workshop.
5. Conclusion
2000. Le Caire. [ 131 WfMC,
This paper has discussed the topic of virtual teams coordination in virtual enterprises. It emphasizes the idea that a good coordination is a subtle mixture of explicit and implicit coordination.
" Workj7ow Management Coalition", http://www.aiim.org/wfic/mainfiame.htm, . [ 141ICQ, http://www.icq.com. [151 Yahoo Messenger, http://messenger.yahoo. com, .
141
[I61 W. Prinz, "NESSIE: An Awareness Environment for Cooperative Settings", in ECSCW. 1999. Kopenhagen. [ 171 CHI, "workshop on awareness in collaborative systems", http://www.usabilityfirst.com/groupware/awareness/workshop/, 1997. [18] A. Bouazza, H. Skaf-Molli, and P. Molli, "Coordinating virtual teams by measuring group divergence", in GROUP'99 Workshop on Groupware Related Task Design. 1999. Phoenix, USA. [19] T. Mansfield, S. Kaplan, G . Fitzpatrick, T. Phelps, M. Fitzpatrick, and R. Taylor, "Evolving Orbit : A process Report on Building Locales", in GROUP'97. 1997.
142
