Coordinating the complexity of design using P2P groupware

CoDesign, Vol. 1, No. 4, December 2005, 255 – 265

Coordinating the complexity of design using P2P groupware MICHAEL CUMMING*{ and EVREN AKAR{ {Faculty of Architecture, Delft University of Technology, Berlageweg 1, Delft, Netherlands {Faculty of Technology, Policy and Management, Delft University of Technology, Jaffalaan 5, Delft, Netherlands (Received in final form 20 December 2005)

Complexity in collaborative design has technical as well as social aspects. Design team members must learn to manage the technical interdependencies between design tasks, as well as the social processes related to construction and maintenance of design teams. Such activities tend to require constant communication and coordination. One promising approach to team communication and coordination involves use of peer-to-peer (P2P) technologies. Collaboration technologies, or groupware, enable construction of online social groups in which specialised types of information can be exchanged. P2P-based groupware allows design team members to acquire relevant local perspectives from their collaborators in a distributed, nonprescriptive fashion. A P2P approach to design communication and coordination is discussed in relation to theories on structuration, which similarly address issues related to local action and emergent social structure. Keywords: Complexity; Collaboration; Peer-to-peer (P2P); Structuration theory

1. Introduction Collaborative design is an inherently complex cognitive and social activity. For large engineering projects, design teams must be assembled that are capable of solving design problems of a specific, complex type. Individuals or large organisations usually gain relevant experience and expertise when designing design projects that involve similar design issues and problems. Members of design teams who work together usually develop practical understanding of how others work, informed by their shared, recurrent experiences (Fischer, 2004). These prior experiences increase the likelihood of designers having things in common, of sharing common ground (Clark, 1996) (Clark & Brennan,

*Corresponding author. Email: [email protected] CoDesign ISSN 1571-0882 Print/ISSN 1745-3755 online ª 2005 Taylor & Francis http://www.tandf.co.uk/journals DOI: 10.1080/15710880500478361

256

M. Cumming and E. Akar

1991). If these people continue to work together, this common ground is often reused. Yet, even when informed by past, possibly shared experience, collaborative design problems are often inherently difficult to solve. In most non-routine design processes both problem and solution structures evolve (Lawson, 1990). This affects the kind of people needed to work on a design, as well as the content of tasks that these actors are expected to perform. To handle this evolving complexity, there should be flexibility as well as structure in design team and task management. Design management should be flexible enough such that varieties of actors are able to participate, and that these actors can interactively define required design tasks as the team attempts to make sense of a design process (Larsson, 2003). Team and task structures should be informed by the past experience of participating parties, yet should not completely pre-determined by this experience. Collaboration technologies are those designed to support interaction between people (Andriessen, 2002). These technologies involve both computer support tools and groups of people; they form social-technical systems whose success is dependent on social, as well as technical factors. Andriessen notes that the adoption, use, and success of collaboration technology depends largely on three main groups of factors: 1. Whether it is accepted by the users, and is suitable for the task, 2. whether it fits and supports the social context, and 3. whether it is introduced in a proper way and is tailorable to changing demands. P2P-based collaboration technologies are flexible due to their inherently decentralised and non-prescriptive nature, as well as their ability to self-organise into emergent configurations based on the distributed activities of many users. They can also be configured to accumulate forms of common ground that structures the collaborative relations between designers. Currently, opinion is divided about the overall virtues of P2P systems. From a corporate perspective, they can pose real dangers to organisations, such as those from downloaded files that contain viruses, worms, or spyware, the legal liability for the organisation because of pirated, downloaded digital content, and the degradation of communal bandwidth and storage resources through illicit P2P use by employees (Websense, 2005). These are all legitimate concerns, however, it appears that from a technical and economic perspective, the potential value of P2P systems for creating scaleable, self-configuring, and fault-resistant software systems are simply too enticing to ignore (Economist, 2004).

2. Background 2.1

Collaborative design

Collaborative design is such a common way to frame design processes that is difficult even to conceive of an alternative. In design problems of any size, it is seen as the only possible way to design. Collaborative design practice takes place within dynamic and evolving social and technical environments. These involve complex interactions between wide varieties of interested parties. Collaborative design processes tend to be complex by their nature, but are becoming more complex with increasing integration demanded between diverse and possibly novel functional requirements. Increased complexity in design has both social and technical aspects. Not only are the technical problems becoming more difficult—such as learning to work with new materials, or learning to cope with changing regulatory environments—but also the social demands that they bring is changing. People from different cultures, who may have never worked together before, are brought together and expected to quickly bridge their cultural differences and become productive with one another (Cross & Cross, 1996) (Fischer, 2004).

Coordinating the complexity of design using P2P groupware

257

2.1.1 Issues of centralisation and decentralisation. Collaborative design and information systems that support collaborative design have both centralised and decentralised aspects. These aspects relate to what kind of social relations structure inter-personal interactions, as well as technical configurations that may privilege some components over others. Up to now, the tendency has been to build design support systems implemented as centralised systems, such as those that employ client-server network architectures. Situations that favour a centralised approach to design support are ones where one party assumes a central, authoritative role. This, of course can happen frequently in collaborative design. Centralised design process approaches are also encouraged when design collaborators understand appropriate roles they should assume, and when design processes and the conceptual organisation of process and product models are well understood and are unlikely to evolve significantly. Centralised control of design processes tends to encourage shared access to standardised data, especially when there is a requirement for complete data reliability and coherence (Cumming, 2005). Situations that favour a decentralised approach are ones in which the intention of the design team is to design in a highly innovative fashion, or when the design problem presents great conceptual or technical challenges. In such cases suitable, time-tested design approaches may not be available and team members may have little conclusive knowledge about their current design situation. They may also lack experience working together as a design team. Therefore, the whole team—including those working at the peripheral edges of the organisational structure—may need to contribute in order for the group as a whole to formulate acceptable design solutions. This is similar in situation to the coordination of space shuttle missions in which technical breakdowns may occur that require the collective cognitive efforts of everyone on a hierarchical, yet highly adaptive and interactive space mission control team (Cumming, 2003) (Watts, 1996). As social-technical research into use of collaboration technologies shows, it makes sense to match the organisational aspects of design support software with the organisational nature of the processes it is designed to support (Orlikowski, 1992). Organisations with hierarchically configured social structures tend to have organisational cultures in which control is centralised, and those with flattened social hierarchies tend to have more distributed control structures. Such considerations affect the types of collaboration technologies suitable for supporting processes in particular organisations. If centralised control of a design process is suitable as an effective strategy, this suggests that local knowledge will be of less importance to a design process. Distributed P2P support systems, which enable access to local peer-generated knowledge, become more attractive if local knowledge or local sense making is considered important. 2.1.2 Design teams. Design teams, either virtual or real, are seen as the most important context in which collaborative design takes place. Without design teams, it is inconceivable that collaborative design can take place. Support for designers is seen as closely aligned with the issue of support for design teams. To support design teams, it is necessary to be able to form teams in a flexible manner and to enable designers to join these teams easily. This need not be purely a top-down process. How design teams are formed can be a highly interactive process involving negotiation between existing and potential new members. It is possible that design teams can be built incrementally without well-defined pre-conceptions, when designers individually volunteer and are allowed to join, if they fulfil certain standards of expertise. Such emergent team construction processes can be found within open source programming, in which anyone may be able to join a programming team and accept significant responsibilities, if they can demonstrate

258

M. Cumming and E. Akar

to other team members that they have suitable skills and orientations (Benkler, 2004) (Hippel, 2005). One goal when establishing collaborative design teams tends to be the creation of an intellectually resourceful and diverse social body (Bonifacio and Molani, 2003) (Surowiecki, 2004). Another is creation of a social group that is capable of interacting productively with one another. Productive interaction implies the presence of common ground, and of forms of social structure. According to structuration theory, social structure provides both constraints as well as resources to social interactions (Giddens, 1984). Structure is important in collaborative design, since design—despite how creative and open to innovative ideas it might be—is usually a highly structured industrial activity. Actors in multi-disciplinary design teams are chosen for their professional diversity and the ranges of perspectives and experience they can bring in to inform a design process. Diversity and its expression in collaborative design teams are potentially both a barrier as well as an opportunity in collaborative design. When the diversity of design teams is great—when their members reflect a wide range of technical and social expertise—there may be wide social or technical differences in the perspectives of members. Design teams must both work around and exploit these differences in order to achieve design productivity. Diversity may separate designers, but it also may allow them to conceive of innovative solutions to design problems by allowing them to pool their intellectual and creative resources. According to Campbell’s ‘fish-scale’ model on interdisciplinary competence, it is unrealistic to expect individual actors to have a depth of understanding that covers broad fields. Rather, teams with many centres of competence and expertise, should attempt to achieve ‘‘collective comprehensiveness through overlapping patterns of unique narrowness.’’ (Campbell, 1969) cited in (Fischer, 2004). 2.1.3 Dynamic Group Processes (DGIn Model). The Dynamic Group Interaction Model (DGIn Model) provides a conceptual framework for analysis of groups and teams (Andriessen, 2002). The DGIn model identifies the most important group processes that must be supported in order to leverage group performance. Andriessen proposes that collaboration technologies support group interactions in a specific way. Introduction of new systems implies changes in how groups work, use tools, and interact. According to the contingency perspective, effective systems must match their environment. In the case of collaboration technology, this means that the effectiveness of a groupware application depends on its fit to aspects like the task, user groups, and the context in which these user groups operate. In the DGIn model (Figure 1), the contingency perspective proposes that the various input characteristics in the model, such as size, task, group composition, and group culture should be balanced. The better this balance is the higher is the chance that the groups will function effectively. Five group processes defined in the DGIn-model are cooperation, coordination, communication, social interaction, and learning. According to Andriessen, communication has a different nature than that of the other processes. It is basic to information sharing, coordination, cooperation, and social interaction. Andriessen defines cooperation, coordination and learning as task-oriented processes. Cooperation, i.e. working together, involves applying one’s knowledge, skills, and using appropriate performance strategies. Coordination involves adjusting the work of the group members to fit the goals of the group. Learning involves exchanging (sharing) and developing information, views, and knowledge. Social interaction is a group maintenance-oriented process. It involves team building that develops trust and cohesion, drive-oriented behaviour, and reflection of team activities and team development.

Coordinating the complexity of design using P2P groupware

Figure 1.

2.2

259

The Dynamic Group Interaction Model (DGIn) (Andriessen, 2002).

Communication and coordination in groups

Coordination science is a relatively new discipline developed to explain and manage complex collaborative situations that tend to overwhelm existing process management theory and technique. Whitfield, Coates, Duffy, and Hills (2000), Klein (Klein, 1998), and Malone and Crowston (Malone & Crowston, 1992) provide excellent overviews. Malone and Crowston provide a good, concise definition of coordination: ‘‘the act of working together harmoniously’’ (1992). Coordination of action is required, according to Klein (1998), when distributed activities, such as those found in collaborative design, are interdependent. Malone and Crowston also provide a list of technical definitions others have proposed for the term. Jennings provides a useful discussion (1996) regarding the three main reasons why the actions of multiple agents need to be coordinated. 1. Because there are dependencies between agents’ actions, 2. because there is a need to meet global constraints, and 3. because no one individual has sufficient competence, resources, or information to solve the entire problem. According to Klein (1998), the most fundamental aspect of support for coordination comes through communication. That is, it is inconceivable that in whatever design coordination regime, whether softwarebased or otherwise, that agents will be able to coordinate their work without actually communicating with one another. In hierarchical control situations, this communication may be indirect, through, for example, an agent’s manager or controller, while in distributed cases it can occur directly between agents. Communication is required for the construction of common ground between team members. In collaborative design a dominant party has neither the desire nor the ability to control a design process completely, and design team members must work together to come to some mutual understanding of what goals are appropriate in their perceived design context. This process of cooperation involves communication between actors. If successful, leads to a perception within the group of the growth of mutually held common understandings, or common ground. 2.2.1 Structuration theory. Structuration theory as defined by Giddens proposes that a recursive relationship exist between social structures, the hidden relations that

260

M. Cumming and E. Akar

structure society, with the actors who produce and reproduce these structures (Giddens, 1984). For a society to exhibit social norms—as all societies do—there must be independent, distributed parties who are able and willing to express these norms within their distributed behaviours. Therefore, societies and the social norms that create them are seen as an emergent outcome derived from the actions of many independent agents. As research in complex systems shows, emergence is often found when distributed, recurrent processes are iterated. Usually, it is not at all obvious what will emerge when processes are iterated, without building computer-based models and simulations (Holland, 1998) (Edmonds, Candy, Jones, & Soufi, 1994). Structuration theory focuses on the dynamic nature of social structures and on the human activities needed to reproduce these structures. Characteristics of institutions are either confirmed or changed by dynamic social interactions. According to structuration theory, the interaction between human action and institutional structures takes place in three domains: 1. Meaning constitution, 2. power relations, and 3. norms and legitimisation (Andriessen, 2002). Social structures also involve ‘group maintenance’. Group maintenance refers to processes that are not directly task-oriented but have an objective to foster the vitality, attractiveness, and continuity of the group, through strengthening of the cooperative climate (Andriessen 2003). Central issues in a team context are the development of trust, cohesion, and group identity. Andriessen states that group effectiveness crucially depends on such factors. Collaborative design teams are one form of social organisation. Managers of design teams hope that their members are creative, well informed, and work well together. It is possible that a design team’s organisational culture can be designed in a similar way to how designed artefacts are designed: as an intentional, interactive process informed by the contributions from many knowledgeable parties. Gidden’s theory may appear obvious (or not), but it has the potential to inform P2P software support for distributed processes in a fundamental way. It suggests that in order to create various types of organisational culture, one needs agents working at the bottom to reproduce social norms that encourage these cultures to emerge. Therefore, creation and maintenance of social organisations, which may appear to have globally defined attributes, necessarily involves bottom-up processes. 3. Collaboration technologies Orlikowski and Hofman, (1997) define groupware as ‘‘technologies that provide electronic networks that support communication, coordination and collaboration through facilities such as information exchange, shared repositories, discussion forums, and messaging’’ (Orlikowski and Hofman, 1997, in Andriessen 2002). Andriessen (2002) extends the definition for collaboration technology to ‘‘those ICT applications that support communication, coordination, cooperation, learning and/or social encounters through facilities such as information exchange, shared repositories, discussion forums, and messages.’’ Collaboration technologies refer to software intended to support groups of people who want to share information, or work together in some way. Collaboration technology, or groupware, is sometimes called ‘collaborative’ software. The first application that explored the collaboration technologies concept was the popular Lotus Notes application. This application is based on the client-server architecture and requires set-up of a centralised server. Notes has been generally used by larger organisations capable of managing its complex initial set-up and customisation (Orlikowski, 1992).

Coordinating the complexity of design using P2P groupware

3.1

261

P2P implementations of collaboration technology

A peer-to-peer (P2P) network is one that relies on the computing power and bandwidth of participants in the network rather than concentrating it, or centralising it in a relatively few servers (Wikipedia, 2005). One of the main attractions of the P2P approach is the fact that P2P systems can function without the necessity for centralised control and coordination. This is attractive in the domain of collaborative design, since centralised control and coordination of design processes tend to work against the inherently distributed nature of these types of interdisciplinary processes. Peers are the users of P2P-based applications. Peers can be both the consumers as well as producers of services and information found on P2P networks. This reflects the basic approach found in P2P computing, which tends to collapse multiple user categories into singular ones—that of the ‘peer’. This approach is a result of the basic technology of P2P computing, but also reflects non-technical concerns common in the P2P community, such as reduction of the social stratification of users, encouragement of open, social processes, and provision of resources that enable distributed phenomena to self-organise. One of the basic ideas of P2P is to reduce the barriers to communication by flattening communication hierarchies and making everyone a potential peer. In P2P systems, peers can self-organise into online social groups called peergroups. In P2P systems, peergroups act as virtual social spaces in which peers can interact and exchange information. It is up to co-operating peers to define groups, join groups, and leave groups (Oaks, Traversat, & Gong, 2002). The purpose of peergroups is to 1. Define a set of services and resources: peergroups can provide specialised services, such as access to secure information sources, or ways to interact with their fellow peers. 2. Provide a secure region: peers must be members of the same peergroup in order to share information.

Figure 2.

Client-server network with centralised data repository vs. a P2P network with connected peers and emergent peergroups.

3. Create a scoping environment: one of the primary purposes of peergroups is to partition the set of possible users into definable groups that provide a limiting scope for search and discovery of resources. Messages within a peergroup are propagated only to peers that are members of the peergroup (Oaks et al., 2002), Without the construct of a

262

M. Cumming and E. Akar

peergroup, sharing information within a distributed community becomes much less efficient, since then all information would have to be shared with all known peers, rather than a smaller subset of these peers. 3.1.1 P2P as a collaboration technology. P2P implementations of collaboration technologies are also becoming visible. Currently, the most prominent being Groove developed by the inventor of Lotus Notes, Ray Ozzie. Collaboration technologies tools have a range of capabilities that enable various interactive behaviours between users. They enable 1. Communication between users in a synchronous or asynchronous manner, 2. sharing of information that is contained in databases, 3. collaboration by enabling distributed authorship of shared documents or of group decision-making, 4. coordination by helping to synchronise processes between distributed agents, such as workload management systems that manage pre-defined sequences of routine tasks between agents, and finally, 5. support for social encounters and build-up of group awareness between people in distant locations (Andriessen, 2002). Clearly, the collaboration technologies domain involves a large number of research areas and could inspire a variety of software applications. However, these are still early days for the both collaboration technologies concept in general, and P2P implementations of collaboration technologies in particular. Neither appears yet to have caught the public imagination in a significant way. This, of course, could change quickly. Collaboration technologies address inherently social as well as technical issues in their design and implementation. Social-technical issues are important whenever computerbased processes are introduced into any organisation. This effect appears to be amplified in the case of collaboration technologies, which have as their foundation a social support function. One main research finding in the use of collaboration technologies in organisations is that people adapt collaboration technologies to suit their own purposes: they ‘appropriate’ them and make them their own. Collaboration technologies can structure interpersonal processes in an organisation such that the nature of the organisation changes somewhat. Therefore, collaboration technologies and the organisations they support mutually affect one another. This recursive effect is as predicted by structuration theory and is a major theme in the work of Wanda Orlikowski. As Orlikowski states: ‘‘we shape tools that then shape us, or at least shape us through our use of them in particular ways. It’s recursive. It’s not a one-way relationship.’’ (Scharmer, 2005). 3.1.2 Relevant P2P systems. Few formal studies exist of P2P collaboration systems applied to collaborative design domains. Clearly, P2P applications can support file and content sharing between designers. It is unclear whether they are the natural choice for higher-level functionality such as design coordination, and team ‘sense-making’ processes implied by the social-technical literature. One example of a P2P-based design support tool is the Design Process Modeller (DPM) designed to enable distributed teams to determine collaboratively the state of design entities, such as tasks and products (Cumming, 2005). The tool is role-based, and enables users to communicate simple looped state-transition models that they feel suitably describe the possible states and transitions that a design entity could experience. These state models can describe the degree of completion, degree of acceptance within a team, or progress with respect to a series of milestones. By attaching entities to simple state-transition loops, users make input based on simple questions about the state of individual entities, rather than complex ones arising from the interaction of entities.

Coordinating the complexity of design using P2P groupware

263

Complex branching process structures can be created by composing entities. The tool automatically handles state assessment of complex, linked compositions of entities, while users handle assessment of simple, non-linked entities. It provides users with information regarding design state and structure, and supports a form of bottom-up design coordination that requires no centralised policies or inputs, prior to deployment. DPM was tested in the context of an administrative process that manages a defined set of course prerequisites for technical course work for architectural students at TU Delft (Cumming, 2005). Therefore, this did not test designers working within complex interactive design processes found in industry, but rather design students working within technical support roles. Result of this testing demonstrated that the easy communication of design-related process information is possible using P2P systems (as expected), but that tuning the performance of the system depended on fixing memory leaks, and on creation of policies to ensure that resource-hungry threads are turned off at appropriate times. Indeed, testing of P2P systems can be quite dangerous due to their potential to consume excessive bandwidth and other resources. The performance of P2P systems tends to improve as users multiply, and when resources are redundantly copied between many peers. This allows systems to function if few peers are logged onto the P2P system at any one time. A P2P system with too few users online is similar to a client-server with a server that is down—important resources may then be unavailable to users. Another relevant research project is PeerSpaces, which includes a coordination model suited for P2P networks and, similar to the DPM above is based on the JXTA P2P framework (Busi et al., 2003). PeerSpaces is based on the coordination language Linda. PeerSpaces involves the development of a middleware platform for the management of dynamically configurable federations of devices where processes cooperate and compete for the use of shared resources. PeerSpaces support both context-aware and contexttransparent data production. Context-aware applications are those with access both the system configuration context and the data context explicitly, while context-transparent are developed without explicit knowledge of the current context. Another system designed using P2P/JXTA technology without any particular relevance to collaborative design practice, is Knowledge Nodes (Bonifacio et al., 2002). This research criticises traditional knowledge management systems in that they tend to embody a ‘‘centralised’’ approach to knowledge representation and management. This thought to fail because local perspectives are abstracted away and replaced by centrally designed semantic structures. According to these authors, a distributed approach to knowledge management should be based on: 1. The principle of autonomy in which organisational units are given a high degree of autonomy to their local knowledge, and 2. the principle of coordination: each unit must be able to exchange knowledge with other units not through the adoption of single interpretation schema, but through a mechanism of mapping other units’ contexts onto its own context from its own perspective. This is viewed as a semantic negotiation and coordination process, which many design researchers see as an important aspect of collaborative design. 3.1.3 Structures that can emerge from use of P2P systems. As design teams work together, if all goes well, team members acquire degrees of trust, social cohesion, and social identity. These social resources can enable as well as constrain social interaction within the team. In addition to informal social structures, technical ones also influence how technical design teams structure their activities. These include things such as technical norms, standards, and technologies used to solve specific design problems. If

264

M. Cumming and E. Akar

members find social structures helpful in their design practice, they are in the position to either reproduce them or change them in subsequent design processes. As structuration theory proposes, at each step in this reproductive process, a knowledge-led actor has the freedom and discretion either to reproduce the social structures that are presented to him or her, or to change or ignore these structures. This phenomenon lends unpredictability to collaborative design since social structure, though possibly very influential in its effect to frame design problems in particular ways, cannot wholly determine design processes, or their outcomes. 4. Conclusion Due to the complex nature of collaborative design process, design teams must have flexible means of addressing design problems using available social and technical resources. These resources derive from the experiences that design teams members acquire from previous design situations, or those they construct in response to their current situation. Collaborative design activities are also constrained by social and technical rules, which design teams either bring to a design process or learn to apply within it. For complex, knowledge-driven processes such as design, designers are in the position to apply learned and received social and technical norms from their previous design experiences. In P2P terms, they are the ‘peers’ that participate in the process. As structuration theory states, the social rules and resources that structure the design team’s current and future behaviours arise from the bottom-up interactions of these actors. The top-down features of design cultures that might arise from recurrent types of interactive processes must be produced and reproduced by local actors in order for these design cultures to have a lasting, rather than a transient effect. P2P groupware is in the position to capture actual interactions between designers in a non-prescriptive way. Therefore, P2P forms of collaboration technology are expected to be well positioned to capture emergent collaborative design cultures as they are produced and reproduced by the actors whose local actions are required to define these cultures. References 1. J. H. E. Andriessen, Working with Groupware: Understanding and Evaluating Collaboration Technology. Springer, London, 2002. 2. Y. Benkler, ‘‘Sharing Nicely: On Shareable Goods and the Emergence of Sharing as a Modality of Economic Production.’’ Yale Law Journal. 114. 273. 275 – 358, 2004. 3. M. Bonifacio, P. Bouquet, & R. Cuel, ‘‘Knowledge Nodes: the Building Blocks of a Distributed Approach to Knowledge Management.’’ Journal of Universal Computer Science. 8. 6. 652 – 661, 2002. 4. M. Bonifacio, & A. Molani, ‘‘The Richness of Diversity in Knowledge Creation: An Interdisciplinary Overview,’’ Technical Report DIT-03-030. Trento, Italy: Department of Information and Communication Technology, University of Trento, 2003. 5. N. Busi, C. Manfredini, A. Montresor, & G. Zavattaro, ‘‘PeerSpaces: Data-driven Coordination in Peer-toPeer Networks. Proceedings of ACM Symposium on Applied Computing. Melbourne, FL, USA. 380 – 386, 2003. 6. D. Campbell, ‘‘Ethnocentrism of Disciplines and the Fish-Scale Model of Omniscience.’’ In Interdisciplinary Relationships in the Social Sciences. M. Sherif & C. Sherif Eds. 328 – 348. Chicago: Aldine Publishing Company, 1969. 7. H. H. Clark, Using Language. Cambridge University Press, Cambridge, UK, 1996. 8. H. H. Clark and S. Brennan, ‘‘Grounding in Communication.’’ In Perspectives on Socially Shared Cognition. L. Resnick & J. Levine & S. Teasley Eds. 127 – 149. Washington, DC: American Psychological Association, 1991. 9. N. Cross and A. C. Cross, ‘‘Observations of Teamwork and Social Processes in Design,’’ in Analysing Design Activity, N. Cross, H. Christiaans, and K. Dorst, Eds. John Wiley & Sons, Chichester, UK, 1996.

Coordinating the complexity of design using P2P groupware

265

10. M. Cumming, M. ‘‘Sharing knowledge within organizational hierarchies using flexible peergroups.’’ Proceedings of 10th ISPE International Conference on Concurrent Engineering: Research and Applications. Madeira, Portugal. 26 – 30 July 2003. J. Cha & R. Jardim-Gonc¸alves & A. Steiger-Garc¸a˜o Eds. 591 – 598, 2003. 11. M. Cumming, Constructing Process Models from Distributed Design Activity. Ph.D. thesis. School of Architecture, Carnegie Mellon University, Pittsburgh, 2005. 12. Economist, ‘‘In Praise of P2P.’’ Economist Magazine. Available: http://www.economist.com/science/tq/ displayStory.cfm?story_id ¼ 3422905&tranMode ¼ none [2004, 14 December], 2004. 13. E. Edmonds, L. Candy, R. Jones, and B. Soufi, ‘‘Support for Collaborative Design: Agents and Emergence,’’ Communications of the ACM, Vol. 37, 1994. 14. G. Fischer, ‘‘Social creativity: turning barriers into opportunities for collaborative design.’’ Proceedings of Eighth Conference on Participatory Design: Artful Integration: Interweaving Media, Materials and Practices. Toronto, Ontario, Canada. 152 – 161, 2004. 15. A. Giddens, The Constitution of Society: Outline of the Theory of Structuration. Polity Press, Cambridge, UK, 1984. 16. E. von Hippel, Democratizing Innovation. Cambridge, MA: The MIT Press, 2005. 17. J. Holland, Emergence: From chaos to order. Perseus Books, Reading, MA, 1998. 18. N. R. Jennings, ‘‘Coordination techniques for distributed artificial intelligence,’’ In Foundations of Distributed Artificial Intelligence, G. O’Hare and N. R. Jennings, Eds. John Wiley & Sons, New York, NY, pp. 187 – 210, 1996. 19. M. Klein, ‘‘Coordination Science: Challenges and Directions,’’ in Coordination Technology for Collaborative Applications, W. Conen and G. Neumann, Eds. Springer Verlag, Berlin, pp. 161 – 176, 1998. 19. A. Larsson, ‘‘Making sense of collaboration: the challenge of thinking together in global design teams.’’ Proceedings of ACM SIGGROUP Conference on Supporting Group Work. Sanibel Island, Florida, USA. 153 – 160, 2003. 21. B. Lawson, How Designers Think, 3rd ed. Butterworth Architecture, Oxford, UK, 1990. 22. T. Malone and K. Crowston, ‘‘What is Coordination Theory and How Can It Help Design Cooperative Work Systems?’’ in Groupware: Software for Computer-Supported Cooperative Work, D. Marca and G. Bock, Eds. IEEE Computer Society Press, Los Alamitos, CA, 1992. 23. S. Oaks, B. Traversat, and L. Gong, JXTA in a Nutshell. O’Reilly, Sebastopol, CA, 2002. 24. W. Orlikowski, ‘‘Learning from Notes: Organizational Issues in Groupware Implementation,’’ Proceedings of Computer Supported Cooperative Work (CSCW), Toronto, Canada, pp. 362 – 369, 1992. 25. W. Orlikowski and J. D. Hofman, ‘‘An Improvisational Model for Change Management: The Case of Groupware Technologies,’’ Sloan Management Review, Winter 1997, pp. 11 – 21, 1997. 26. C. O. Scharmer, ‘‘Awareness is the First and Critical Thing: Conversation with Professor Wanda Orlikowski’’, MIT Sloan School of Management, [Interview]. Available: www.dialogonleadership.org [2005, January 10]. 2005. 27. J. Surowiecki, The Wisdom of Crowds: Why the Many are Smarter than the Few. London, UK: Little, Brown, 2004. 28. J. Watts, D. Woods, J. Corban, E. Patterson, R. Kerr, & L. Hicks, ‘‘Voice Loops as Cooperative Aids in Space Shuttle Mission Control.’’ Proceedings of CSCW ’96. Boston, MA. November 16 – 20. M. Ackerman Ed, 1996. 29. Websense. 2005. Those just aren’t files you’re swapping: the dangers of Peer-to-peer File Sharing. Websense, Inc. Available: http://www.websense.com/global/en/ResourceCenter/WhitePapers/p2p_security.php [2005, 11 November]. 30. R. I. Whitfield, G. Coates, A. Duffy, and B. Hills, ‘‘Coordination Approaches and Systems – Part I: A Strategic Perspective,’’ Research in Engineering Design, Vol. 12, pp. 48 – 60, 2000. 31. Wikipedia. 2005. Peer-to-peer. Available: http://en.wikipedia.org/wiki/Peer-to-peer [2005, 14 November].