cscw requires open systems

CSCW requires open systems Leandro Navarro*, Wolfgang Prinzt and Tom Rodden

Applications designed to support the work of groups will becoming increasingly important to future distributed systems. This paper considers the role of distributed systems within the development of cooperative systems. In particular we focus on the need to provide open Computer Supported Cooperative Work (CSCW) systems and their impact on distributed systems. The work currently being undertaken in Open Distributed Processing (ODP) is used to highlight significant trends for future open CSCW systems. It is shown that the CSCW and ODP community share mutual interests and have complementary aims and goals that are being developed from different perspectives. Within the paper we provide a brief introduction to CSCW, highlighting the requirements CSCW places on distributed systems. The development of an environment to support open CSCW systems is introduced and briefly described. Finally, the relationships between requirements and models for Open CSCW systems and the Basic Reference Model of ODP are discussed.

Keywords: computer supported cooperative work, Open Distributed Processing, MOCCA environment, distributed cooperative applications

The advent of powerful low cost personal computing has ensured that computer systems and tools are available which help users perform the tasks associated with their profession. Such systems have penetrated large segments of normal work practice, and personal access to computer systems is no longer unusual. However, most of these computer systems and tools have often been considered in isolation, both in terms of other tools and the existence of other people using similar computer-based tools. Given the widespread availability of modern networking technology and the reliance of the success of most projects on the cooperative activities of people, this historical focus has limited the support provided by computer tools.

Computer Supported Cooperative Work (CSCW)

*Dep. d'Arquitectura de Computadoss, Universitat Politrcnica de Catalunya, 08034 Barcelona, Spain *GMD. Schlol3 Birlinghoven. 5202 St. Augustin, Germany $ Computing Department, Lancaster University, Lancaster LA1 4YR, UK

has emerged as an identifiable research area which focuses on the role of the computer in group work j. The research being undertaken poses a number of questions. How can computers be exploited to maximize the synergy of groups? What kinds of software should be developed? How do we define group work? To tackle these issues the research undertaken by the CSCW community combines a wide variety of disciplines, each contributing a different set of skills. Many issues surrounding the support of groups remain unclear. However, what is apparent is that we are moving away from the traditional individualistic view of computer systems towards a group oriented perspective. Subse- quently, computer systems can no longer be considered in isolation but as part of a community of machines applying applications designed to support the work of groups.

Distributed systems play a central role in many cooperative systems, and it is likely that CSCW will provide a significant application area for distributed systems 2. Similarly, the needs of CSCW will play a significant role in shaping many features of future distributed systems. It is therefore imperative that future distributed systems developers are aware of the requirements of CSCW applications. This is particularly true in the case of open systems.

Many existing CSCW applications have tended to ignore the existence of others. In the same way that user isolation limited the usefulness of personal computers, it is important that CSCW developers avoid a blinkered outlook in the development of their systems and attempt to develop 'open" CSCW systems.

The distributed computing community have been examining the provision for open systems for some time, and much of this work is reflected in the work of Open Distributed Processing (ODP) 3. The observation that CSCW systems are both distributed and open in nature is of particular importance to ODP. We believe that both the CSCW and ODP community share mutual interests and have similar aims and goals which have emerged from different perspectives. ODP standardization considers the portability, interworking and distribution problems of distributed computer systems. In contrast, CSCW has a focal point on the use

288 0140-3664 /93 /050288-10 © 1993 Butterworth-Heinemann Ltd computer communications volume 16 number 5 may 1993

of computers to support groupwork which need to be open to both users and other systems. For CSCW systems, we believe that the term 'open' involves more than just the ability to share information by the usage of the same standards. Furthermore, it requires that applications are aware of the existence of the other applications and their resources (documents, spread- sheets, etc), a user applies in his cooperative work. This provides mechanisms for a semantical integration of various applications in a cooperative process, like a distributed project proposal editing or a pre-conference organization. This semantical integration cannot be provided by the applications themselves, it requires a CSCW environment that provides the functionality to represent and interpret the dependencies between resources and applications. Within the MOCCA* project we have started with the description of such an environment. The intention of this paper is to raise questions for the developers of future standards. These questions highlight important areas of future research for both the CSCW and standards communities.

CSCW SYSTEMS

The term 'CSCW" was originally coined by Greif and Cashman I in 1984 as a shorthand way of referring to the interests of a number of researchers involved in the use of computers to support user groups. The area has evolved over the last five years to combine the understanding of the nature of group working with the enabling technologies of computer networking, systems support and applications. It is now recognized that CSCW is inherently a multi-disciplinary research topic, and requires the application of a number of disciplines including sociology, organizational science, psychology and computer science. Readers are referred elsewhere 4's for a more complete review of CSCW research.

The wide variety of CSCW systems developed to date reflect the many different views of cooperation which currently exist within CSCW. Two principal characteristics can be used to describe CSCW systems:

1. The form of interaction supported CSCW systems are primarily concerned with supporting a number of users cooperating to address a particular problem, or range of problems. The nature of this cooperation can be distinguished by the way in which the group members interact. People either interact and cooperate synchronously or asynchronously. Syn- chronous interaction requires the presence of all cooperating users, while asynchronous cooperation occurs over a longer time period and does not require

*The MOCCA project is a working group partly funded by the European Community within the framework of the Cost-14 CoTech programme.

CSCW requires open systems: L Navarro et al.

the simultaneous interaction of all users. Synchronous systems are characterized by desktop conferencing systems 6 such as Shared X 7. The majority of asynchronous systems are based around either message systems ~9 or computer conferencing systems t°.

2. The geographical nature of the system CSCW has traditionally considered the case of geograph- ically distributed groups. More recent research has complemented this emphasis by considering the support of face-to-face (or co-located) meetings. As a result, cooperative systems are often considered as being either remote or co-located. In this classification the division between remote and co-located is as much a logical concept as a physical measure, and is concerned with the accessibility of users to each other rather than their physical proximity. Co-located systems often exploit purpose built meeting rooms such as the COLAB ~ at Xerox PARC. Remote systems include more sophisticated distributed applications such as multimedia conferencing systems t2.

The two characteristics of interaction and geographical location are often used as the basis of a simple classification space for CSCW systems (see Figure 1). This space allows the technical characteristics of the various classes of system (or groupware) within CSCW to be categorized and is often referred to as the groupware time space matrix 13. Although this is a useful categorization, we want to stress that only CSCW systems which comprehend the whole matrix provide a sufficient user support. It is obvious that this cannot be provided by one single application. Such a system requires the integration of various (CSCW) applications into an environment that provides inter- operability and semantical integration based on the utilization of standards. Later we will show how a CSCW environment and a standard infrastructure provided by ODP, for example, are related.

NEED FOR OPEN CSCW SYSTEMS AND A CSCW E N V I R O N M E N T

Role of an environment for CSCW applications

Despite the many different forms of CSCW systems developed to date and the recent emergence of 'groupware" as an identifable product, there are still very few CSCW systems or technologies in widespread use. Most systems are either confined to the research laboratory or are used only in small scale experiments addressing single ~artificial' tasks. Possible reasons for this noticeable failure of CSCW applications have been investigated by a number of researchers 2°" 21. While the majority of the problems involving the introduction of CSCW are of a psychological or sociological nature, a number of technical limitations exist. It is important to

computer communications volume 16 number 5 may 1993 289

Siune Place

Figure 1

Figure 3

Different Places

Same Time Different Times

,**oF** II A ync onou I Interaction Interaction

sy c o.o s jR Distributed Distributed Interaction Interaction

The groupware time space matrix

consider that CSCW systems will not be accepted while these fundamental human factors are ignored. Never- theless, the technical problems of the widespread use of CSCW applications are of a sufficiently debilitating nature to require attention.

The current generation of CSCW applications provide diverse models and mechanisms aimed at supporting either a particular cooperative activity or class of activities. These applications are often unaware of the existence of other applications 22 and provide few mechanisms for working in conjunction with other applications (Figure 2). Thus, users of a given CSCW application are presented with a particular interpretation of cooperative work, and can only work within the confines of that closed world.

The reality of supporting cooperative work is that a wide range of CSCW applications, each exhibiting a distinctive model of cooperation, need to work in unison. Consequently, the role of the environment in which CSCW systems exist becomes a crucial factor for the future success of CSCW applications. A central aim of such an environment is to provide interoperability and a semantical integration between a variety of applications, ensuring that CSCW applications can work in harmony rather than in isolation of each other (Figure 3).

We see the provision of a CSCW environment as a means of realizing more 'open' cooperative systems. As CSCW applications become more widely available, it will become increasingly necessary to focus on an open approach that allows the integration of applications into a CSCW environment to provide an open CSCW

Figure 2 Independent CSCW applications

Role of a CSCW environment


system. Such a system should aim to allow a multiplicity of approaches and paradigms to co-exist. In addition, the problems of developing open CSCW systems are compounded by the strong inter- relationship between CSCW systems and the activities of the organization in which they exist. CSCW applications do not exist in isolation but are an integral part of the activities which take place within the organization in which they are embedded.

For example, the management of a large scale engineering project (e.g. building the Channel Tunnel) can be undertaken as a cooperative activity. The overall task may involve an ongoing programme of sub- activities such as team progress meetings, the joint production of reports, monitoring and interviews, as well as more ad hoc, informal communication between project members.

These sub-activities can be interrelated in a variery of ways, for example:

• Each person may be involved in many activities. • Activities may use common resources. • Activities may share common information. • Activities can have well-defined temporal relation-

ships.

There are also many differences between activities. For example, some have well defined goals and fixed deadlines while other are ongoing. They may also utilize different underlying communication technologies. Activities do n o t occur in isolation, rather the general picture is of many interrelated activities taking place within a world of shared resources, people and information.

As a result, cooperative working needs to be considered in terms of numerous related activities occurring within an organizational environment. It is important that a CSCW environment allows these activities to be interrelated. However, it should be stressed that we do not foresee the development of open CSCW systems allowing a standard model of either cooperation or organizations. In contrast, open CSCW systems will allow a greater diversity of cooperation techniques to work together.

290 computer communications volume 16 number 5 may 1993

Existing CSCW environments and toolkits

The need to allow a number of different cooperative facilities to exist has already been recognized by a number of researchers within the CSCW community, and CSCW application platforms have emerged which address the provision of technical solutions for particular cooperative domains. These infrastructures provide a set of existing facilities which can be reused by developers in the construction of new applications. Examples of these platforms include development and application toolkits like DistEdit tS, Liza i6 Strudel 17 and Oval 18, or distributed application platforms such as Rendezvous~ 4 or 'Y" ~ 9.

Similarly, runtime environments exist which provide services to extend the functionality of existing applications so that they can be used by cooperative groups. Perhaps the best example of this approach is in real-time conferencing systems. Shared window and conferencing environments such as Shared X 7 and Rapport 12 allow a number of applications to be shared across different displays. In essence, these systems provide facilities which manage interaction to allow users to simultaneously see the output from applications while co-ordinating input to avoid the application being confused.

All these platforms and environments are targeted at narrow domains, and provide a collection of services which solve particular technical difficulties for developers. These are presented either as a runtime environment with a set of particular system calls or a collection of shared libraries or objects to be exploited by developers. We wish to contrast these endeavours within CSCW by adopting a wider perspective and considering the infrastructure to support open cooperative applications and the implication for CSCW and ODP.

O P E N C S C W S Y S T E M S R E Q U I R E M E N T S

The identification of a range of requirements for a CSCW application environment provides the starting point for the development of open CSCW systems. The requirements* presented here are by no means complete, but are intended to illustrate requirements which are characteristics and distinctive of CSCW systems. We believe that these requirements will directly impact future distributed systems.

Two categories of requirement are important for the provision of open CSCW systems. The first class of requirement is those which are generally shared by most open applications. However, what is important to CSCW systems is the manner in which these general

*Many of these requirements were either informed or confirmed by a n international developers workshop 23 held as part of ECSCW'91, the Second European Conference of CSCW, and attended by over 40 developers.


requirements are met. Meeting these requirements will necessitate a re-examination of the support provided by existing standards. Additionally, CSCW presents a set of unique requirements which will require the development of novel techniques. Each of these different sets of requirements are considered below.

General requirements

CSCW systems share similar demands to existing applications which have already influenced the development of open systems. However, the manner by which these needs are met are often peculiar to CSCW. This section briefly examines information sharing and communication as two examples of this form of requirement. The particular needs of CSCW are presented and compared to the forms of support currently provided for open systems.

Support for information sharing The sharing of information is an essential precursor to cooperative working. It is important that patterns of sharing are adopted within the environment which enable effective cooperation to take place. The environment needs to provide a set of services which encourage the cooperative sharing of information. These services should include:

• Services for the access and exchange of information between different applications running on different platforms and used by different users; including where applicable mobile portable computers.

• Maintaining a knowledge of people, resources and ongoing activities, for example by the integration and utilization of standard information repositories like the X.500 directory service 24.

• Mechanisms for modelling the organizational context in which the cooperation takes place and based on this appropriate access control mechanisms.

• Services that provide awareness on the ongoing actions in a shared information space. This service should supply the user with information about the actions that occurred in an information space that he is sharing with other people. The user is then better informed about the current status of the cooperative work.

A number of standard initiatives have examined the role of information within group work. For example, researchers have examined the relevance of the X.500 directory service to CSCW applications 24. More recently, working groups have considered the development of standards to allow the sharing of conference structures across groups 25.

This effort has focused on the structure of the information being shared and how this structure can be represented across applications. Equally important for CSCW is the means by which this information is


CSCW requires open systems: L Navarro et aL

shared between users. For example, standards have failed to address the problems of either access control, locking or transactions. These issues are central to the needs of CSCW applications and yet are missing within current standards initiatives.

Support for communication Communication plays a vital role in cooperation, and it is important that this role is reflected within a CSCW environment. Subsequently. a CSCW environment will need to provide a range of communication services which should include:

• Support for a wide range of media, including telefax and where applicable paper communication.

• The provision of many different forms of communication, including both real-time and asynchronous communication.

• Support for interchange of cooperation across communication media.

Traditionally, communication support for CSCW has been provided by asynchronous OSI communication standards such as X.400. However, even though these provide a useful basis they do not allow a sufficiently diverse range of communication styles for many CSCW systems. Accordingly, most CSCW applications adopt and augment these basic services for their own purposes 9. Communication standards have merely provided a technical infrastructure which enabled the exchange of structured information. The representation and control of cooperation within the system has normally been layer on top of the message standard being exploited, often within closed applications.

Specific CSCW requirements

In addition to the new demands placed on general infrastructure support, CSCW as an application domain presents a unique set of requirements for the developers of open systems support. These requirements centre around the need to support a wide range of work practice. Thus CSCW systems need to incorporate some concept of activity. An activity is understood as a cooperative process of interactions between people. Such processes typically involve the use of several applications like mail, texteditors, fax, workflow- systems, shared editors, etc. To supply a comprehensive user support, CSCW systems should provide means to describe activity-specific dependencies and interrela- tions for the use of the various applications. However, this needs to be done in a flexible manner to allow the evolution of new working styles. Thus open CSCW systems need to support for activities and tailorability. In addition, the new concepts which arise within CSCW extend the set of transparencies of importance to open systems. The following sections briefly review each of the issues in turn.

Support for activities CSCW systems have a strong relationship with the various organizational activities which they support. It is essential that a CSCW environment provides mechanisms for representing the various relationships between these activities. Additionally, the environment needs to provide a set of services to allow the management of these different activities within the environment. These services might include:

• managing the membership of activities • sharing resources between activities • scheduling activities and monitoring the progress of

activities • mechanisms for negotiating the responsibility for

activities • mechanisms for negotiating the division of com-

petence within activities • coordination of activities.

These services need to be provided in a neutral manner to allow as wide a range of CSCW applications as possible to be supported by the environment. No single model of cooperation is assumed, but rather services should be provided to allow a range of different models to exist in unison.

Support for tailorability Cooperative working is essentially a dynamic activity, and thus CSCW applications need to be malleable and taiiorable. As a result, systems and the environment supporting them need to be tailorable both by developers and users. This has two important consequences: first, the environment needs to provide a set of services akin to a developer's toolkit to enable this tailorability; second, and more importantly, perhaps, is that the traditional divide between users and developers becomes less clear, with users having similar powers and status as system developers. An investigation of the limits and bounds of this tailorability and possible notations, languages or services to support this tailorability will be an important area of research for future CSCW developers.

Support for transparency Cooperative activities are carried out by a 'distributed group': people who are located at possibly different places, employed at different organizations, working at different times, using different user-group interfaces, having slightly different goals, having different under- standings of the activities, language, competence, culture, etc. The CSCW environment should provide some degree of transparency to facilitate people cooperating from different coordinates, to reduce complexity by hiding some dimensions that are unnecessary for the cooperative activity. Significant dimensions include: organizational (organizational awareness), temporal (integration of synchronous and asynchronous), linguistic, cultural and physical units (distributed working) 26.


A number of different forms of transparency are important to CSCW systems.

• Transparency of organization means that activities need not be dealing with the whole complexity of the possibly different organizations involved. Inter- organizational connections should/could hide the complexity of different organizational (particular of each enterprise) and inter-organizational (free market or other) policies. Another transparency aspect is that widely distributed CSCW systems can provide means for the establishment of virtual organizations which exist only by the definition of shared electronic workspaces and high-speed communication links.

• Transparency of time deals with the mode of work, synchronous or asynchronous. The result of applying this transparency is that interaction will be independent of the mode we are using.

• Transparency of view means that applications can be interested or not in the way users view data. This transparency will not be used in WYSIWYG activities.

• Transparency of activity means that a set of objects cooperating in one activity needs not be aware of other unrelated objects present in the distributed environment. These unrelated objects can be located in a different location or in the same location but participating in other activities. This helps activities not to be disturbed by other unrelated activities.

This section has highlighted a number of requirements which are central to the development ofa CSCW environment. The MOCCA project investigates these requirements, and aims to develop mechanisms by which these requirements can be met.


Information Organisatio~ /

Distributed Communication Architecture

Rooms metaphor

Figure 4 MOCCA viewpoints on CSCW

Figure 4 illustrates the different MOCCA viewpoints. The Distributed Architecture considers how the models can be used to specify components of an open, distributed CSCW platform. The Organizational View- point considers the organizational context required for CSCW in terms of a set of resources. The Information Viewpoint examines the definition of shared information, relationships between information objects and the global naming of information, while the Communication Viewpoint groups together mechanisms of interaction dealing with the information resources. The Rooms metaphor provides the users conceptual map of the global environment, and addresses the issues of location, navigation and social interaction.

Starting from each viewpoint, a model that describes the objects as they appear in the respective viewpoint can be defined. In this paper we concentrate on the architecture viewpoint, which is illustrated in the following section.

MOCCA, A C S C W E N V I R O N M E N T

A distributed CSCW environment satisfying all of the above requirements represents an extremely complex system, and is impossible to consider in its entirety. Consequently, MOCCA has identified a number of perspectives from which to view the environment, where each perspective offers an abstract view of specific environment functionality. More formally, the perspectives can be refined to a set of 'models ' which collectively specify the environment. Adopting an object-oriented paradigm, the environment consists of a set of objects representing people, applications, organizations, resources and relationships between these objects. Each object may appear in several models, being viewed differently in each. Applications and their resources (documents, messages) are inte- grated into the environment by so called object adaptors.

General MOCCAarehiteeture

As the result of the initial exploration of the set of models identified above, a set of cooperative support functions have been identified. The general MOCCA architecture decomposes these common functions into a set of loosely connected managers which provide appropriate portions of cooperative support. These managers are intended to abstract over the services provided by existing OSI and ODP platforms.

The main characteristics of this architecture derive from the separation between application specific and domain specific matters:

• portability of applications, static (source code) or dynamic (object migration) to other contexts providing a compatible set of transparencies

• integration, by a common interpretation of information and events circulating among objects



• inter-organizational operation, by federation mechanisms providing support for bi-lateral agreements or electronic markets

• evolution, by adding new managers that modify existing functions or provide new functions as the nature (or our understanding) of the cooperative work being supported alters.

Two of the managers currently identified by the MOCCA environment are aimed at supporting the manipulation and storage of information. Most cooperation involves the sharing of information which often provides a focal point for the cooperation taking place. Subsequently a central repository, an information store, for shared information as in an environment plays a significant role in a cooperative environment. This is augmented within a cooperative environment by the provision of an organizational database which allows organizational information to be shared.

In addition, active support within the environment is provided by three active components, the domain manager, the activity manager and the security manager. The general architecture is presented in Figure 5.

The function provided by the Domain Manager is visibility. Objects can be classified into domains to reduce the number of visible objects to those of interest. Domains are also a unit of policy: different policies will be associated with different domains. Domains are also a unit of cooperation: cooperative activities take place in a domain (or a set of domains), thus domains reflect how the 'cooperative space" is structured.

The Activity manager allows activities generated or supported within an application to be registered outside the application in the MOCCA environment. Other applications interested in that activity can also register their interest in the status of that activity with the Activity Manager. For example, an application may wish to publicize that it is involved in the development of a production plan for a bridge. To do so an application would construct an activity entry in the Activity Manager. This entry may describe the purpose

~o~y coet~ ~ A Set of managers defines a ~ I ,~c!n~ofa ~ I cooperative envttonmenL

OSI / ODP Computational Platform )

Figure 5 MOCCA architecture

of the activity, their state, participants, resources allocated, etc.

The Information Store provides common storage services to the objects living in the environment. It should be able to store information elements, structures, rules and complex objects. Requirements for con- current access and quality (e.g. accuracy, reliability, consistency, availability, lifetime, etc.) will be diverse, ranging from critical long-term data, to short-term state information data.

One key function of the Information Store is to provide inter-operability among different objects by sharing a common service access point and information representation. The service will be used not only by Managers, but also by application related objects.

The organizational database contains information about the organization in which the environment is set. The organizational database represents an organization in terms of the resources used within it, the employees working for it, the roles they play, organizational relationships, and the organizational procedures and policy exploited within the organization.

The organizational database allows information regarding organization members" expertise and interests to be stored and queried by systems. This information will often map onto underlying structures and services such as those provided by X.500. Finally, the organizational database allows organizational roles and policy to be stored and accessed by a number of different cooperative systems.

One important concern in a inter-organizational- distributed-cooperative environment is security. The security manager object groups all functions related to security. Security is concerned with ensuring that the resources of the system are available to those who are allowed to use and/or access them, and are not available to others, including non-intentional access.

Organizations are responsible for describing a security policy which allows measures to be taken against possible threats to the security of the distributed system (e.g. unauthorized disclosure, contamination, misuse of resources, repudiation, denial of service).

Additional managers may be included in the future as new common functionality is available and required. For example Mermaid 27 provides a control scheme for distributed multimedia shared applications based on a replicated architecture: a copy of the application runs at every site. It provides communications functions for maintaining an identical state across copies in a replicated architecture. This function could be supported by a new manager.

M O C C A prototypes Some of the concepts previously outlined have been proved by the development of prototype systems at several institutions. These include the following:


• The ORGWIS project at GMD has developed into a prototype of an organizational knowledge base and a multimedia organizational browser that reflects the organizational model into a system.

• The Grace project at Nottingham University has developed a prototype system for large scale information sharing systems based on a combination of X.400 and X.500.

• The MOCCA Hypercard Demonstrator produced at Nottingham University, intended to communicate the key ideas of the environment from a user's perspective. The demonstrator shows how the Rooms metaphor might be applied to a large scale text conferencing system, and includes mock-ups of Rooms, a Map Tool, an Organizational Browser and a Toolbox which controls which applications can be used in which rooms.

• The Whitewalls prototype at Lancaster University demonstrates a system for tailorable synchronous CSCW interfaces based on the notion of a shared whitewall across which users can move, and of which they can filter different kinds of information.

• The ETC prototype at Catalunya University (UPC) demonstrates the realization of some common environment mechanisms needed by CSCW applications and managers over a distributed system platform. To construct an open distributed system, we have used a BRM-ODP based architecture: ANSAware 3.028.

O D P AND C S C W

In the previous sections we discussed the need for open CSCW systems and the requirements which we believe need to be met by both applications and distributed systems support. The aim of open systems has been examined by many researchers within the distributed computing community particularly in the context of ODP. This section briefly relates open CSCW systems to the ongoing work of ODP.

The following sections investigate how the current views of ODP meet the requirements of CSCW and how the work being undertaken in the development of open CSCW systems relates to ODP. It is important to emphasize that ODP should not simply be regarded as a framework for the development of open CSCW systems. It is our beflief that the concepts and models being investigated within CSCW are relevant to ODP and have a significant input to make in its future development.

Impact of CSCW on ODP

Rather than dealing with the complexity of distributed systems, ODP considers systems from five different


viewpoints (Enterprise, Information, Computation, Engineering and Technology). Each viewpoint represents a different set of abstractions of the original

• • " ~ 9 system, i.e. a simplified view. The ODP design trajectory- prescribes that the design outline should start with the selection of a viewpoint that is most appropriate for the design and architecture of the application considered. For CSCW applications this is either the enterprise or information viewpoint. However, the ODP visibility and transparency aspects within the computation viewpoint are also of interest.

Enterprise and information viewpoint: activities, roles and sharing The support for activities required by CSCW systems highlights aspects which are strongly related to the enterprise viewpoint within ODP. The current view in ODP is that enterprise and information modelling results in a set of requirements and restrictions for the computational model. This model is a structuring of the functions identified in the higher models in terms of computational objects.

It seems sensible, given the more active nature of organizational components in CSCW systems, that the results of enterprise modelling should be used for more than simple input to the development of other viewpoints, It is important for the management of open CSCW systems that knowledge central to enterprise modelling is supplied by an appropriate service. Perhaps, within future ODP systems aimed at supporting CSCW applications, the organizational knowledge base considered in the MOCCA environment will be associated to the trader, containing or dictating among others the trading policy.

The ODP community should also be conscious of the problem that the office procedure/information system developers had to deal with. These were mainly the problems of being too rigid and procedural in the description of organizational activities and information flow. Systems developed often forgot the human factor, and the fact that employees often do not behave as prescribed in the organizational handbook. (Some people are convinced that this is the only reason why large companies survive.)

In fact, the modelling of organizational structures and activities plays a significant role in the CSCW context. Therefore, the various models for the description of office procedures as well as (group) activities 5 developed in that context are a valuable source for the development of information and enterprise models.

Computation viewpoint: visibility and transparency aspects The concept of user tailorability is central to CSCW systems, and as a result a need exists for system visibility and transparency to the user. Of course, this is mainly directed towards CSCW application developers, but it also has a relevance for the underlying distributed system. Within ODP these concepts are reflected by the



so called aspects of visibility and transparency. They play a central role in the computational viewpoint, and become central in the discussion of distribution transparency.

The decisions involved in providing selective distribution transparency are important, and ODP has considered the need to fully discuss the advantages and disadvantages of selective transparency. However with CSCW systems, selection mechanisms should not only be provided for application designers and developers. The user-centred view of CSCW systems means that the user should be allowed to select their own required transparency.

It is important that ODP investigate mechanisms of providing user tailorability of transparency, and provides appropriate presentation techniques to allow transparency and its tailoring to be described to the u s e r .

Relation of CSCW and O D P

ODP and CSCW have different aims and requirements, they look to the "real world" from different perspectives, and try to solve different problems. As a result, they build different models of the 'real world" (related, but with different taxonomies). One describes all possible distributed systems, the other describes all possible CSCW systems. To satisfy the aims, in each case choices are made. These choices will prescribe which of all possible systems will qualify as open. Both ODP and CSCW choices are compatible, implying that both 'Reference Models' will be interrelated 26.

The next stage will be to define standards for the functions, mechanisms, information etc, identified in the model. Our view is that all possible Open CSCW Systems can be considered as a subset of Open Distributed Systems, which means that specific environment standards will be a subset (or a specialization) of specific ODP standards.

Open systems do not necessarily need to conform to all ODP standards (some of them may be domain- specific), which means that we will find CSCW and non-CSCW systems, whether they conform or not with an environment's standards. As a result, environment standards provide some additional CSCW capabilities, but this does not compromise the goals of ODP standardization.

Our approach to open CSCW systems has been based on the development of an environment to support a number of different CSCW systems. This approach is similar to that adopted by the ODP community, who have also exploited the development of an ODP environment to describe much of their work. A suitable ODP context for the development of a CSCW environment is shown in Figure 6.

The CSCW environment is located between the basic ODP environment and CSCW applications. However,

I o o , , . . = . o . , I Figure 6 ODP and CSCW environments

even applications which are not typically regarded as CSCW applications, like document processing systems, might use the CSCW environment when they are used in a cooperative context. In that way a CSCW environment augments ODP with CSCW-specific functions and requirements. This means that the ODP environment will support all open CSCW systems, but open CSCW systems will be a subset of ODP systems.

Even though a set of similarities between ODP and the approach towards open CSCW systems has been identified, a difference regarding the intention of ODP and the approach of open CSCW should be mentioned. It is the aim of ODP to mask distribution and to obtain portability and interworking, i.e. to overcome heterogeneity between hardware, operating systems, networks, programming languages, storage services, administra- tion and management. In contrast, the central aim of an open CSCW environment is to overcome heterogeneity between different classes of cooperative applications. However, both these approaches are strongly interdependent and it is likely that future work on both CSCW and ODP will mutually inform each other.

Relation of CSCW and O D P architectures

The current MOCCA architecture is based on two main models: the Basic Reference Model of ODP, and the MOCCA Environment model. The objective of the MOCCA architecture has been the provision of a service platform that provides a functionality which is common to most CSCW applications. The object- oriented architecture that has been chosen can be further refined and implemented over several distributed processing platforms. While we have used (internally to the project) the ANSAware IDL language to describe the functionality of our managers, that may be easily translated into other interface definition languages. Difficulties may arise due to current limitations in the degree of development of platforms, but those obstacles will dissolve in the future.

On the assumption that the BRM-ODP is generic enough to support any distributed processing environment (such as OSF-DCE and OMG-DOM in addition to ANSAware), our architecture may be implemented in terms of any of those object-based computational platforms. A problem to solve in the future would be the


inter-operability among those distributed processing architectures.

CONCLUSIONS

This paper has presented a brief introduction to CSCW, and has examined the need for open CSCW systems as well as their requirements. The MOCCA project was introduced with the aim to develop an environment which will support open CSCW systems. It was shown that the experience and approach of ODP can be a valuable tool in realizing open CSCW systems in the future. Similarly, the ODP standardization effort can benefit both from the experience of CSCW application developers and the requirements which CSCW systems place upon their distributed platform.

The MOCCA group will continue its work on a CSCW environment. Future work will focus on the details and interrelation of the models outlined in this paper. The ODP work will be observed and included in our work where applicable. We are looking forward to a very interesting and exciting decade of new distributed CSCW applications, and we hope that our efforts towards open CSCW applications will be realized.

ACKNOWLEDGEMENTS

The authors are indebted to their colleagues within the MOCCA project for much of the work described in this paper, and would like to thank them for their help and support in the development of the concepts described. In particular, we want to thank Uta Pankoke-Babatz for her helpful comments on this paper.

REFERENCES

1 Bannon, L and Sehmidt, K "CSCW: Four characters in search of a context', in J M Bowers and S D Benford (Eds), Studies in Computer Supported Cooperative Work, North-Holland. Am sterda m ( 1991 )

2 Rodden, T and Blair, G "Distributed systems and CSCW: the problem of control'. Proe. ECSCW'91, Amsterdam. Netherlands (25-27 September 1991)

3 ISO/IEC JTCI/SC21 WD7 (N309-N315), Drafts of standard documents on Open Distributed Processing.

4 Ellis, C A, Gibbs, S J and Rein, G L'Groupware some issues and experiences' Comm. ACM. Vol 34 No 1 (January 1991)

5 Prinz, W 'Survey of group communication models and systems', in U Pankoke Babatz (Ed), Computer Based Group Communication, the AMIGO Activity Model. Ellis Horwood, Chichester (1989) pp 127-180

6 Lauwers, J C and Lantz, K A 'Collaboration awareness in support of collaboration transparency: Requirements for the


next generation of shared window systems'. Proc. CHI '90, Seattle, WA (5 April 1990)

7 Gust, P 'Shared X: X in a distributed group work environment', 2nd Ann. X conf. Boston, MA (January 1988)

8 Malone, T W and Lai, K "Object Lens: A spreadsheet for cooperative work'. Proc. CSCW88. Portland. OR (September 1988)

9 Pankoke-Babatz, U (Ed) Computer Based Group Communication, the AMIGO Activity Model, Ellis Horwood, Chichester (1989)

10 Palme, J 'COM/PonaCOM conference system design goals and principle' in B Shaekel (Ed), INTERACT '84 (1985)

11 Steflk, M, Foster, G et ai. 'Beyond the chalkboard: computer support for collaboration and problem solving in meetings'. Comm. ACM. Vol 30 No 1 (January 1987)

12 Abuja, S R, Ensor, J R and Horn, D N 'The Rapport multimedia conferencing system', in R B Allen (Ed), COIS88: Proceedings Conference on Office Information Systems. Palo Alto, CA (23-25 March 1988)

13 Johansen, R 'Groupware: Computer Support .for Business Teams~ The Free Press. NY (1988)

14 Patterson, J F, Hill, R D , Rohall, S L and Meeks, W S "Rendezvous: An architecture for synchronous multi-user applications', Proc. Conf. on Computer Supported Cooperative Work (CSCW '90). Los Angeles, CA (1990) pp 317-329

15 Knister, MJ and Prakash, A 'DistEdit: A distributed toolkit for supporting multiple group editors', Proc. Conf. on Computer Supported Cooperative Work (CSCW '90). Los Angeles. CA (1990) 343-357

16 Gibbs, S J "LIZA: An extensible groupware toolkit' Proc. SIGCHI Human Factor~ in Computing Systems. Austin, TX (1989) 29-35

17 Shepherd, A, Mayer, N and Kuehinsky, A "Strudel - An extensible electronic conversation toolkit'. Proc. Conf on Computer Supported Cooperative Work (CSCW '90). Los Angeles. CA (1990) 93-105

18 Malone, T W and Lai, K Y "Experiments with Oval: a radically tailorable tool for cooperative work' Proc. Con(. on Computer Supported Cooperative Work (CSCW '92). Toronto, Canada (1992)

19 Popescu-Zeletin, R, Tschammer, V and Tschiehholz, M "Y" distributed application platform'. Comput. Commun.. Vo114 No 6 (1991)

20 Grudin, J "Why CSCW applications fail: problems in design and evaluation of organizational interfaces'. Proc. Conf. on CSCW. Portland, OR (1988)

21 Markus, M L and Connolly, T 'Why CSCW applications fail: problems in the adoption of interdependent work tools', Proc. Conf. on CSCW. Los Angeles. CA (1990)

22 Kreifelts, T et al. 'Experiences with the DOMINO office procedure systems', Proc. ECSCW'91. Amsterdam, Netherlands (25-27 September 1991)

23 Rodden, T 'ECSCW'91 developers workshop report', SIGCHI Bulletin (in press)

24 Prinz, W and Pennelli, P "Relevance of the X.500 directory to CSCW applications', in D Marca and G Bock (Eds) Groupware Software for Computer-Supported Cooperative Work, IEEE Press, NY (1992)

25 Benford, S "A standard for OS1 group communication', Int. J. Comput. Networks & ISDN Syst. (to appear)

26 Navarro, L 'An environment for open distributed group communication', position paper, Int. Workshop on ODP Berlin, Germany (8-11 October 1991)

27 Ohmori, T, Maeno, K, Sakata, S, Fukuoka, H and Watabe, K 'Distributed cooperative control for sharing applications based on multiparty and multimedia desktop conferencing system: MERMAID', Proc. 12th Int. Con(. on Distributed Computing S.vst. IEEE Press, NY (1992)

28 ANSAware 3.0 Implementation Manual, Document RM.097.01 (1991)

29 Popien, C, Spaniol, O and de Meer, J 'Systementwurf mit Open Distributed Processing' Praxis der lnformationsverarbeitung und Kommunikation, No 4 (1991)


cscw requires open systems

Documents