We will describe here a design approach for supporting teamwork composed of three phases. The first one allows the identification of frameworks adapted to different generic cooperative situations. The second allows the customization of these frameworks to specific situations. The third makes the framework implementation in the team network easier.
To reach this objective, we come up with a typology to identify generic teamwork situations (§ 1). Based on distributed artificial intelligence research, we attempt then to identify frameworks adapted to the different types of situations. We have retained three frameworks covering asynchronous and structured communications between team participants.
We then describe (§ 2) some elements of an architecture supporting the teamwork environment by presenting amongst others its language system and its mechanism for norm or protocol sharing within a team.
It is also necessary to implement the computer-supported cooperative environment on the team workstations and servers. For that purpose, we suggest (§ 3) a software engineering approach allowing the modelling of generic situations, the specification of particular situations and their automatic implementation in a network.
A global schema of the suggested method to build a teamwork support environment is given at the figure 1. The idea presented in this paper were born and experimented in the PLEIADE project (Pigneur, 1992) (Zucchinetti, 1994).
The tenants of the theoretical approach, among whom one counts Flores and Winograd (Flores et al., 1988), define tools based on a theoritical cooperative model assuming they will be useful for all types of organizations. By so doing, they neglect the "situated" nature (Suchman, 87) of the cooperative work and expose their tools to failure in situations for which they are maladjusted.
Followers of an empirical approach, such as (Malone et al., 1987) or (Kreifelts et al., 1993), develop tools and then evaluate their usefulness in a particular situation (generally in the context of the development of their own tool). But they do not express criteria determining the type of situations for which their tools are adapted.
The approach presented in this paper attempts to solve the above-mentioned deficiencies. It tries to detect generic situations in which organizations can be repeateadly found. These situations are then connected with generic frameworks able to bring them an value-added support. These generic frameworks are adaptable to specific teamwork situations.
Reasons explaining the choice of this approach are triple: (a.) using CSCW systems depends strongly on the organizational context (Kling, 1991) and the analysis of the actual situation is therefore essential, (b.) the impact of CSCW applications on the organization structure is strong and difficultly foreseeable and therefore an empirical approach is unavoidable, and (c.) the identification of a situation, its characteristics, and weaknesses conforms to a desirable approach of management.
We propose a situational approach for designing applications which consists of identifying a situation within a typology, selecting the corresponding support frameworks and possibly customizing them to the specifics of the situation.
This approach is similar to one of the thoughts about management expressed by (Mintzberg, 1990).
It does not exist a unique approach to solve all the manager's problems coming from various organizations. Recommendations belong to the context: they have to be used according to specific situations, carved on measure to needs that appear in a given time. [. ..] In the world of management, what's missing is the existence of generic problem categories and a catalogue of their symptoms - i.e. rapid diagnosis methods of problems and their solution recommendations, as there exists, perhaps, in medicine. (Mintzberg, 1990)
We adopted the typology proposed by (Constantine, 1993) because it is detailed enough to extract support frameworks. Indeed, it takes into consideration elements such as the complexity of the task to perform, its repetitive or innovative nature, some contingency factors such as the team cohesion, its stability, its hierarchical structure or the degree of autonomy of its members, and includes objectives such as creativity, adaptability, efficiency or foreseeability.
These factors are grouped into four team families mainly based on the coordination mode that they suggest (see figure 1).
The closed team is characterized by a hierarchical coordination mode, where an executive coordinates activities by taking decisions, delegating actions and controlling results.
The random team is characterized by strong innovative and individual initiatives, favoring change and creativity; the control there is weak. The rather chaotic functioning of this type of team is reflected in its name.
The open team leans on a process of permanent adaptation and adjustment, essential for the coordination of very complex tasks. Feedback on results obtained by the other team members allows the team to discuss the project direction and to adjust its actions.
The synchronous team supposes a harmonious alignment of the team members according to a common vision. Members have a perfect notion of their role and their mission, and they do not have to negotiate in order to coordinate their activities. This type of team is very efficient, but requires a stable context and a repetitive work.
The random and closed teams constitute antitheses, such as the open and synchronous team. These 4 teams are archetypes of situations; one finds also hybrid teams, such as the open structured team. This typology and especially the two axes of its classification (cohesion and autonomy) emerge from most of the teamwork references (Lipnack et al., 1993).
DAI covers several cooperative system types, aiming at different objectives and resting on different coordination mechanisms. We will next put in correspondence the main families of DAI systems with the above-mentioned team types. The careful study of the coordination mechanisms used by these systems allows us to propose asynchronous support frameworks adapted to the different kinds of teams.
The future actions and interactions between agents are specified in advance. Morever, because there exists a global view of the problem resolution, it is possible to optimize the task distribution.
The similarity between the characteristics of multiagent systems and those of the closed team is obvious. It would be very interesting to analyze these systems more deeply in order to bring out frameworks supporting closed team coordination. We can mention works of Bodart and Petitjean (Petitjean, 1994) which come up with sophisticated models for task delegation and the workflow-like support to assist an executive in his cooperative work with his assistants.
Programming this sophisticated control is a difficult task. Each agent has to be aligned on a global vision for the problem resolution, while acting according to partial information [3]. Once this vision has been acquired, the coordination is made on a harmonious and synchronous manner.
All these characteristics are very similar to those of the synchronous team. A more elaborate study of this type of system would certainly provide adapted support frameworks.
Agents enjoy semi-autonomy. In order to gradually decrease inconsistencies, they exchange partial solutions, making adjustments easier. Experimental and high level partial solutions replace plans. They provide indicators of what has been accomplished and what remains to be done. The conflict resolution becomes an integrated part of the problem solving activity. This the agent's mission complexification is balanced by loosening both synchronization and necessary communication for consistency maintenance. More specifically, this method does not need preliminary planning, an impossible task for complex and new problems. One can tell that the global solution finally results from a "bottom-up" development.
The functionally accurate cooperation seems to be an appropriate coordination mode for open teams. Its weak use of negotiation makes it compatible with random teams.
Such is not the case of open systems (Hewitt, 1986) that utilize analogous mechanisms, but make explicitly usage of negotiation mechanisms. Open systems are systems of agents; each managing a micro-theory. These agents upkeep a coherent knowledge inside their micro-theory and use argumentation and negotiation mechanisms to solve inconsistencies with the others' micro-theories. Open systems are the most sophisticated version of a variety of systems, in which the most elementary instances follows an actor model.
The actor model (Agha, 1985) implies a system of agents communicating by dispatching messages. Each actor is a process that can accept requests for task execution, perform tasks, decompose tasks in sub-tasks, send requests to other actors to help them achieve these sub-tasks, and create clones to react to the arrival of concurrent requests. The actor system follows an elementary interaction model between individuals.
Taking into consideration speech acts (Searle, 1969) enriches the exchange, by authorizing the negotiation of tasks between individuals. A task is delegated only if the provider gives its agreement, and not when the client requested by, as in the actor model.
The contract net system (Davis et al., 1983), (Smith, 1980) leans on a task allocation between agents, following a call for bids on a market. The submission of a task within an agent community and the different steps (the offer, the adjudication, the realization and the validation) are defined in a protocol. The coordination mode is the contract, ratified in case of correspondence between the experience, resources and information necessitated by the task, and those possessed by the potential provider.
Because the open team is more carefully examined in this article, we chose the actor model, speech act and contract net in order to obtain the three generic support frameworks designed to open teams.[4]
We borrow from the actor model (Agha, 1985) the idea of service or action offered by an individual to a community and allowed to be required by another member, without preliminary conversation. From the speech act model (Searle, 1969) , we retain the idea of conversation and the possibility for two individuals to negotiate the delegation of a task. The contract net model (Davis, 1983) provides the call for bids mechanism that allows to find, within a community, the best person able to achieve a given task.
A service is an action that an actor makes available to a community of actors. An actor represents the couple formed by the team partner and its workstation. A service is characterized by a description that explains the objective to the actors who wants to use it. The actor performing the service is called the provider and the actor that requires its execution is called the client. One also knows the service parameters; they are given by two types of message: one for the service request and the other for the service result. For a particular service, the types of message describe the specific attributes.
In order to require the execution of a particular service, the client creates a message of the given type, inserts values of parameters, and sends the message to the service provider. If the client is not personally concerned by the result of the execution of the service, another actor (continuation) can be designated to receive the result. When a request is received by the provider, the service is supposed to be performed and the result returned to the client or the continuation.
One can also consult a list of the different services offered in a catalogue, sort of "yellow pages" directory of the organization. This catalogue is constantly updated and contains all indispensable elements for service utilization.
The opening can be made by an actor wishing to delegate a task, but can also result from a spontaneous service offer. It ensues a negotiation on the conditions of the task performance using some offers and counter-offers. Once an agreement is reached, the task is performed and its termination announced. The task client, receiving the task results, can then express its satisfaction or not and provoke, if needed, a new performance.
This support framework allows to manage the conversation and the correct use of the message types according to the state of the task performance.
The framework also allows to manage the actor commitments like the list of tasks the actor promised to perform to other actors and those promised by other ones to the actor.
The call for bids is published within a actor community able to achieve the task. This placement of the task on the market initiates submissions of providers interested to perform the task. The call for bids initiator can then choose among the different submissions and assign the task.
This support framework allows to publish the call for bids inside a given community for a certain activity. The dispatch of the submission, containing the different information requested by the client, is also supported by the framework. Finally, the selection of the optimal offer, according to particular criteria, then the task assignment is made via a notification.
The language system allows the manager to communicate with the other team members, and therefore to cooperate, by respecting norms or protocols fixed in the support framework.
For this purpose it offers the possibility to create and transmit units of information (messages) and to receive them. This architecture distinguishes four types of structures which have to be specified in a framework.
The norm sharing mechanism allows to implement the frameworks on the workstations and servers. This mechanism is justified by the fact that support frameworks are not universally applicable, but specific to some situations. Consequently they concern only a part of the organization members. This is why we propose a mechanism able to install a framework only within a subset of the actors.
We agree with Ching's claim (Ching et al., 1990) that the manager workstation has to contain these three components. Nevertheless, the knowledge and problem processing systems mainly concern decision support systems (DSS). This is why we essentially center on the language system.
The language system offers four basic functions: the creation, dispatch, reception, and stocking of messages. It has three types of interfaces: a man-machine interface, a DSS interface with the DSS modules (KS and PPS ) resident on the personal wokstation and a communication interface with the other workstations. It finally consists of two main memory areas: the message area [5] and the protocol area. The figure 3 gives an overview of the language system.
The protocol area consists of the norms and protocols which an actor has subscribed to. Memory areas represent two different levels of classification. By analogy with databases, one could say that the protocol area defines the messages schema and the message area defines the database instances.
The content structure of a message decomposes it in several fields with a label, as a to-be-filled form.
The intention structure of a message is related to its illocutory force (i.e. the implicitly expressed intention of the transmitter, like a request, a promise or an argument). This intention is obviously declared using a message label.
The flow structure of messages determines the exchanges taking place between participants. It specifies who has the right to tell what and when, i.e. the authorized conversation.
The visibility structure of a message links it to an interest center or a discussion subject. All persons interested in a subject or a discussion receive the messages concerning this subject. This allows to transmit information only to the potentially concerned actors, without having to designate them explicitly.
These types of structures correspond to four dimensions introduced in a support framework. This typology provides primitives to characterize precisely a framework and to anticipate some of their effects.[6]
Language and communication are based on the sharing of common objects, norms, protocols, and common beliefs (Crowston, 1990). A communication between two individuals presupposes a lot of common knowledge:
They cannot even begin to coordinate on content without assuming a vast amount of shared information or common ground - that is mutual knowledge, mutual beliefs, and mutual assumptions. (Clark et al., 1991)Clark and Brennan call the process for establishing a norm or a common context, the grounding. They assert that the maintenance and the coordination of a common norm is crucial for the coherent progress of a conversation.
For our asynchronous and structured communication environment, we say that the sharing of a norm (grounding) is achieved when two actors have at least one identical support framework on their personal workstation (protocol area) and are able to converse respecting the norm or protocol imposed by this framework.
This implies that it is not sufficient to compose a message according to a framework in order to communicate with another team member. It is necessary, beforehand, to be sure that its addressee has the rigth framework installed; if not, the risk is great that the conversation will progress confusely.
This aspect is scarcely taken into account in most of the current groupware applications, except for the work done by Bui and Jarke (Bui et al., 1986), that deals explicitly with the process of norm establishment.
However it is necessary to underline that, if a framework is published, it does not entail that each organization member adheres to it. This is why the publication is accompanied by a mechanism of subscription, that allows to adopt a published protocol. Indeed, the number and the variety of norms or protocols in an organization are potentially high; morever, individuals are interested only in a part of these norms. This is why the system should have a mechanism authorizing the subscription to a protocol by a team, subset of the organization members. Thereby, in order to be able to use a framework, the user needs to have subscribed to it before. The software is then installed on its workstation (in its protocol area) and becomes ready for use.
From the software engineering approach, we are mainly interested in the next steps: (a.) the modelling of generic support frameworks, using a given (meta-)formalism; (b.) the specification of frameworks adapted to an organizational situations, by customization of generic frameworks; (c.) the implementation of frameworks in a network of workstations and servers, by automatic transformation of the specification.
The two main tasks for the development of cooperative systems, the modelling of a generic framework and the specification of a particular framework, are each under the responsibility of individuals possessing particular competences, designated by two distinct roles: the application engineer and the application developer. We borrow the description of these roles from (Becker, 1993) who has refined roles initially described in the European project ITHACA (Profrock et al., 1989). Her description of roles has been established in the context of framework design for individual DSS applications, but is perfectly applicable to our CSCW context.
The application engineer is responsible for designing the generic frameworks in (Becker, 1993). His competences go from analysis to programming.
The application developer is responsible for customizing a generic framework to an actual teamwork situation. His competences are mainly in the area of business applications. This role can be taken by a team member. An application developer does not need to have programming competence. Programming languages, object orientation, network configuration are foreign to his/her cognitive universe. This is why he has ideally to manipulate the generic framework through a high-level man-machine interface hiding the technical problems and guiding the specification elicitation.
By definition, a model is only a partial representation of the real world. In our case, as we have underlined it, the model is focused on information exchange between actors. Therefore it does not describe the information processing by the actors, which consitutes the DSS part of the whole environment (Becker, 1993) and (Bodart et al., 1989). For example, it does not model either the execution of an offered service or the reasoning underlying the attribution in a call for bids protocol.
The specification covers, in our mind, two forms of customization of a generic framework. The first is the instanciation of a generic framework to a particular teamwork situation, in a given area and with a particular team schema. The second is the adaptation of a generic framework, redefining some of its components. This specialized version remains generic, in the sense that it can be instanciated to different other situations.
The specification instanciates the model to a particular situation. This instanciation takes into consideration the context of application of the different structures of message, and integrates the team schema and its actor configuration.
The adaptation of a generic model or its specialization allows to redefine or specialize some of its elements. Usually there is no restriction on this type of specialization. One has to be able to modify the different structures of messages: their content, their intention, their flow and their visibility (see above 2.2). In all cases, the specialization produces a framework which can be used as it is or customized to another situation; any framework, even customized, remains generic.
In this section, we give illustrations of specialization and instanciation for each of the three generic frameworks introduced in section 1.
The framework can be instanciated to many teamwork situations. In any case, the services have to be described with their name, their objective, and the parameters to use them. Defining the parameters means to specify the messages for requesting a service and for receiving the results. It is also necessary to specify the team schema: the team members or actors able to provide the services and those authorized to request the services.
Such a framework can also be instanciated to many teamwork situations. We can instanciate the different message structures in order to precisely describe the specific tasks to negotiate. The team schema has also to be established to declare the team members (with their location), i.e. having subscribed to the specified framework.
This framework could also be instanciated to many specific situations by adapting the different message structure in order to refine the market of tasks. The team schema defines the potential actor market which will receive the calls for bids, corresponding to actors having subscribed to the specific framework and therefore able to take their share of work.
The execution can unfold only in an execution environment: network of workstations and servers. It implies an implementation step in order to transform the framework specification into code. The implementation step strongly depends on the modelling language and process, but also on the target environment. Ideally, the implementation step should be automated.
We also tried to define some limits in terms of architecture for the cooperation support. We therefore presented the communication system offered to the team workstations and servers. We notably detailed the language system with its four functions, its three interfaces and its two memory areas. We also presented and justified a mechanism for publishing and subscribing to the frameworks.
In the last part of this paper, we suggested a method for designing and implementing the software corresponding to the support frameworks. We wanted to develop these software as systematically as possible. Therefore we adopted a software engineering approach with its three main steps: the modelling of generic frameworks using a (meta-)model, the specification of particular frameworks, by adaptation or instanciation of generic frameworks, and the most automatic implementation of frameworks in the target operational environment.
Finally, we have to mention that we have undertaken various experimentations, based on the principles presented in this paper, in order to evaluate different representation languages and different design tactics.
The first experimentation (Zucchinetti, 1994) dealt with the offer of services framework. The generic model has been written with the knowledge-based representation language Telos (Mylopoulos et al., 1993). The implementation has been achieved in the OVAL environment (Malone et al., 1992). The evaluation outlines the following issues: Telos, despite its great richness of expression with its three mechanisms of abstraction and its integrity constraints, appeared to be too complex, especially for the application developer. OVAL has not proven the ideal implementation environment. In addition to inherent weaknesses due to its prototype status, its poverty of expression has constituted a too big handicap: some of the elements expressed in the model were impossible to be translated in OVAL.
The second experimentation (Zucchinetti, 1994) dealt with the negotiation of tasks framework. It tried to correct the weak points of the first experience. A generic model of conversation has been described using a entity-relationship formalism (Bodart et al., 1989). A specification written with the assistance of this model could then be transformed into an application assembling a set of heterogeneous components (Oracle, Eudora, 5PM and AppleScript). The mechanism for sharing norms (see above 2.3) has been implemented more completely than in the first experience (using Oval).The evaluation clearly showed that the adopted approach seems to give excellent results and to be appropriate to the application developer's competences.
Last but not least, partial experimentation (Bloch, 1993) concerning the call for bids framework has been achieved in the context of an enterprise that has adopted Lotus/Notes.