Systems Architecture: Product Designing and Engineering Social

Systems Architecture: Product Designing and Social Engineering

Rebecca E. Grinter Bell Labs, Lucent Technologies 263 Shuman Blvd Naperville, IL 60566 USA

[email protected] http://www.bell-labs.com/-beki

ABSTRACT structure - of what was being designed. The role of The production of large and complex systems usually architect evolved to fill that gap. requires the coordination and collaboration of many At the same time as the role of architect was being individuals spread among numerous divisions of a established within some corporations, software architecture corporation. However, much research examining emergedas a researcharea. Software architecture researchers coordination has focused on the subtleties of interactions have focusedon a number of topics including architectural between individuals who may work together in the same description languagesfor expressing the design, codifying department. In this paper, I present a study of systems architectural experienceinto principles, and domain-specific architects and the work that they do to coordinate design frameworks with formal methods for reasoning about acrossorganizational and institutional boundaries. I also architectures[ 13,251. describethe processesand tools that the architects use to support their work. The implications of the social While much of the research in software architecture has processesinvolved in coordinating the design of large focusedon the outcome of the process - the architecture complex systemson the product and those involved in its itself - there is an increasing concern being shown for production are discussed. understandinghow architecturework happensin practice [ 1, 131. One reason why there has been a turn to Keywords understanding practice is it is often the relationship between Systems architecture, empirical studies of design and the design and the organization that presents challenges. development, grounded theory, coordination and As one architect in a computer company explained: collaboration.. The job (of architect} isn’t so much thinking up 1 INTRODUCTION new architecturesbut getting them accomplished. The production of large and complex systems usually That’s the larger part of the effort. Lots of people requires the coordination and collaboration of many have intellectual architectures and not too many individuals including developers, marketing staff, standards people can translate those info actions and experts, and customer representatives. Often, these agreement and creation, that’s really where the individuals are often spreadamong numerous divisions of a rubber meetsthe road. corporation. This paper focuses on one aspect of that production: the early stages of design known as Bass, Clements and Kazman [l] highlight the relationship architecture. Specifically, I examine the how architects between architectureand the organization that produces it in coordinate the design of systems across organizational something they call the architecturebusiness cycle. They boundaries. identify a number of influences on the process including the development organization, the customer organization, any The role of architect is relatively new especially when it maintenanceorganizations, the technical experience of the comesto softwaredesign. However, the idea of an architect architects, and the technical environment itself. has evolved from an older profession: systems engineering. In the late 1980s it was perceived that something was The processof building architecture also reveals these kinds missing from systems engineering, an attention on the up of influences on design (for example [3, I 11). For example, front part of the process[22]. Specifically, it was perceived there are clients who drive the design process through their that the source of failure in many systems was that no one fmancial support, governmental organizations that regulate was explicitly focusing on the overall architecture - the shape, height, and placing of buildings through laws, permits, zones, and so forth, and the architecture profession PermisSiOn to make digital or hard copies of all or part of this work for itself that sets standards for design, and encourages Personal or classroom use is granted without fee provided that copies ere not made or distributed for profit or commercial advan. innovations. This design context spans organizations and tage and that copies bear this notice and the full citation on the first page. even countries through the context of financial, legal, and TO copy otherwise, to republish. to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. professionalattachment. WACC ‘99 2/99 San Francisco, CA, USA 0 1999 ACM 1.58113-070.8/99/0002...$5.00 Systems architects face similar challenges, but little is known about how they manage them, and how they

11 produce technically working and organizationally workable going over an hour. Each interview was subsequently designs. Empirical studies of engineering design work transcribed. I used grounded theory - a method for have often taken a different focus looking what happens developing theories from qualitative data - to analyze the during meetings [7, 17, 201 and individuals’ design work data [ 141. The grounded theory approach uses cycles of [24]. Other studies have highlighted the challenges of the data gathering and analysis to develop an understanding of overall development process of which design forms one what is taking place and why. These cycles involve component [2, 9, 121, and how tools support their work collecting data, breaking it down into conceptual units, [15]. More recently, studies of design have begun to reassembling the parts into a substantive explanation of explore the challenges in coordinating work across why events occur, and then using the current understanding organizational and geographical boundaries [ 10, 193. to drive the next phasesof data gathering [27]. This paper builds on these studies by drawing on their The secondphase of the study consisted of following three insights about how design happens. However, it also architectureprojects. The projects selected were designed follows the example set by studies of building architectsto to be a cross-section of the work going on, but were all expand the analysis away from the design work done by a small projects so that it would be possible to observe a team of individuals sharing common goals, to examine the substantial amount of the process unfolding. After heterogeneousnetwork of actors who shape the design of following each of the projects to conclusion, I wrote up a the architectures. In the next section, I introduce the report describing architecture work and sent it to subset of methods used to collect and analyze the data and site of the architects I interviewed for their comments and feedback study. The following sections discuss how and why the as a way of verifying whether I captured their work architects studied bring a wide variety of participants into practices. the design processand describe the technologies they use to 2.2 Site support their work. I conclude by arguing that these The data in this study are drawn from two departments of architects coordinate the work of multiple groups and that architects that work for a telecommunications equipment they do this by negotiating in an ever-changing vendor. The telecommunications domain has some environment. unusual characteristics that influence the character of the 2 THE STUDY products designed. First, reliability is critical in voice 2.1 Methods networks, and so designs have to provide fail-safe The focus of this study was understanding how one procedures, minimize downtime, and so forth. Second, corporation’s architects go about their design work, which most telecommunications systems have real-time led to a choice of qualitative researchmethods [IS]. The performancerequirements. Both reliability and real-time study itself consisted of two data gathering phases. The requirements can often stand in conflict with other first phase involved interviewing the architects. Initially I principles of good design, and part of architecture work conducted a group interview with three of the architects. involves resolving those issuesas favorably as possible. The purpose of the interview was to elicit information Other characteristicsof the telecommunications domain that about the range of their activities, the people that they architects work with come from customers and regulators. interacted with, the history of their department, their place First, many of the products are configurations of smaller in the bigger organization, and other information of interest. hardware and software components that customers can The information gathered from the group-interview was purchase collectively or selectively. Further, customers used to devise a guide for the semi-structured interviews. expect to be able add more pieces to their .products over The guide developed focused on three important time. Second, telecommunications products also need to componentsof their work: be designed to work with the phone systems of many countries that have different standards. Third, the l questions about what architecture is; telecommunications market has been changing rapidly with l descriptions of the work that the architect does in the the growth of the Internet, deregulation of monopoly departmentincluding a typical project life cycle; and markets, and growth of wireless technologies. Not only is l details about the resources (materials, people, there increaseddemand for products generally, but features technologies) that the architects use in their work. that used to be conceptually different are becoming increasingly blurred as definitions of data, voice, networks, The questions were designed to encouragethe participants broadcast,and routing change. Finally, both governmental to talk at some length about their own work, what they and international standards organizations regulate parts of produced, and the resourcesthey used. Enough time was the telephony domain. Furthermore, the standards change allowed for the interview to follow specific lines of over time, forcing changes to be made to the products questioning pertinent to an individual architect’s work. affectedto accommodatethe revisions. For example, one architect interviewed reviewed proposals for a standardsagency. This was a component of the job These characteristics of the telephony domain along with that some other architects interviewed did not have. By the size of the development efforts - often taking hundreds asking the architect a number of specific questions about of people to build - are the reasons why the company this aspectof the work, I was able to learn about it. employs architects: to maintain and extend the high-level design of the product. Specifically, their architects design I interviewed seventeenarchitects in the two departments. new featuresand enhancetheir existing range of products as Typical interviews lasted around 45 minutes with several well as design new ones for emerging markets. Some of

12 the architects work on very high-level designs of networks interviewed had worked in developmentbefore joining their of products, while others specialize in designing departments. Several of them were well known throughout componentsand additions to existing product lines. Some the corporation for having designed certain features of architects work on ideas that may be realized within the products. During their time with the company the next decade,while others focus on products that need to be architects had met many people, kept in contact with them, built and released as soon as possible. The common and now as architectswere turning to them for advice. ground these architects’ share is that they all work on Architects try to bring experts into the design process for providing technological solutions to the problems that they more than just their technical knowledge. Architects have are presentedwith. responsibility for the design of the solutions that they In addition to providing architectural solutions to problems produce, but they do not build their designs. The the architects studied also shared some other unique implementation of the designs is given to development corporatedemographics. All of them have worked in the organizations, usually those that are working on similar company for a long time, with most of them serving ten products or have had responsibility for the product line to years or more. They are expected to work on problems date. without close supervision and they are trusted to produce Critically, these development organizations have some appropriate solutions that development groups can autonomy in deciding whether to implement the solution. implement. In this sense they operate much like This puts the architects in the position of needing to researchers:fleshingout the details and complexities of a convince developers that these solutions are worth problem, gathering data and resourcesto inform the choice building. This process begins in the team formation stage of solution, weighing alternatives, and then writing up when architects try to ensure that they have developers on solutions. the team in some capacity who will recommend the 3 DESIGN NEGOTIATION: ALLIANCE AND solution to their respective groups. Furthermore, the INFORMATION GATHERING people that they bring into the architectureprocess will get The design processbegins with an architect being assigned to know the architects. This means that during a problem to work on. “Problems” - features or development if problems arise with the architecture the enhancementsto the existing product lines, or entirely new developersare more likely to approach the architects and products - are generated by the architects, their ask for help. This is important becauseit lets the architects management,people in the development organizations, and know how their designs are working out in development, field representatives on behalf of their clients. These and makes sure that their next design tits the current problems eventually arrive to the architect who has the product reality. most expertise in the area. Architects also work with the development organization to Assuming that the problem gains support in the form of get support and start the processof aligning the design to resourcesand staffing - which does not always happen - the implementation schedule. Development groups have the lead architect assemblesa team of colleagues to work on their own schedulesfor building products. Architects need the problem. Although individuals are assigned problems, to find opportunities in those schedules where the the architects almost always work in groups. The developerscan start working on their products, something architects distinguish between two kinds of team that has to be planned months and even years in advanceof participants: core membersand consultants. the time when development starts. So, in addition to The core team members form the heart of the group. Core bringing developers into the team, the architects give group membersare expectedto attend all the team meetings presentationsto development divisions as a mechanism for and contribute to the design of the solution for either as socializing the design and gathering information about long as the project lasts or until they leave their current whether and when the organization could build the design. job. The lead architect aims to have all key aspectsof the The development organizations are only one group among problem covered by members of the core group. The several that the architects need to socialize their solutions architects explained to me that they try to draw as many with. Much of this group socialization of architectures is people as they can from their departmentbecause it is easier conductedthrough presentationsof the design. I found that to negotiate for core members’ time from people in their by attending presentations given by architects I met the management chain. The lead architect turns to their groups that need to “buy-in” to the fmal design. architecture division and then the rest of the corporation - Most projects have problem owners - people who in that order - if there are areasof expertise missing from generatedand provided resourcesfor the design work - the department. and the architectspresent their solutions to those owners. Consultants contribute to the project by attending specific Some architects like to have routine presentations meetings and providing feedbackto the team about the scheduledin the early stages of the project. Others wait current design. The architects draw the consultants from until they have reacheda point where they believe that they anywhere in the corporation. Finding and requesting time should present their current working solution to the from consultantsrequires the architects to maintain and use problem owners. The architects use these presentations to extensive social networks that span the entire corporation. get feedback and support for further work. These These networks have to be especially large to find presentations to problem owners serve as an consultants who may be geographically and functionally acknowledgment of continued commitment to the removed from the architects. All the architects I architecture work by the problem owners.

13 Architects also give presentations to sales teams and The World-Wide Web (WWW) is clearly a source for customers. The purpose of presenting to the salesteam is gathering information. All the architects use the WWW, to get support to sell the products that result from their and many of them use it to gather information about architectures. Architects are often bought in to present products that might be elements their design must products to customers as the technical expert. The accommodate. However, for one of the two departmentsthe presentations,question and answer sessions, and time with web is much more than a resourceas it is also used as a the customers exposes the architects to the clients’ tool for sharing resourcesand an organizational memory. concerns. The adoption of the WWW was not planned. Instead, the Customersare only one external source of information that architects discovered the WWW as part of their role to architects need exposure too in order to build successful investigate and experiment with new solutions, and bring products. Governmental and international agenciesdirectly the results of that into their work. Initially the WWW influence the equipment vendors by generating standardsfor server was on one of the architects’ machines. While he communications, and the media that handle that traffic. maintained the server, another architect taught herself cgi Someof the architects work with the government agencies, scripting. Slowly these bottom-up efforts spreadout until a reviewing their standards and following their latest number of other architects were using the technology. This discussions about standardsand regulations. This provides was made possible by an early commitment horn the head the architects with current information that they then use in of the departmentto have a common hardwareand software their architectures to ensure that when the standard or platform in use throughout the department. Eventually, regulation is implemented their design will be compliant. enough people found the WWW useful that the department In some cases, it also provides the architects with an invested in another machine to house the server. This was opportunity to influence the direction of future standardsin mainly- becausethe architect whose machine had held the ways that support their design work. server was experimenting with other new softwarepackages As well as conforming to standards, and offering features and in the process kept crashing his machine and that their customers want, the architects must’ also follow consequently taking down the server. The shift to a stand- what other telecommunications equipment vendors are alone and stable server marked the beginning of the use of developing. The architects I interviewed all subscribedto the WWW as a departmental tool. trade journals such as Computer Telephony. They kept The architects use the WWW to share project materials journals, magazines, and books around their offices. It is with others. A number of architects pointed out the hard to describe the volume of these subscriptions that advantagesof using the WWW instead of other traditional most architects seemedto have. One architect referredto mediums. Sometimes they have meetings with team his extensive collection as a fire hazard. memberswho are located in another state or even in another This continual attention to broader market trends permeates country. In the absenceof the WWW, the team members the entire architecture organization. The architects’bosses, would have to fax the slides or notes to the remote team also meet routinely and share information about work going members. Sometimes the faxes did not arrive, or were on inside the company, and innovations in the marketplace. simply not arriving fast enough. The architects now put Sharing news about where the telecommunications business their slides onto their server and the remote members can is headed is a topic of conversation for everyone in the easily get them. They also put meeting notes and other architecture organization whether it’s over lunch, in a summary materials on to the WWW rather than meeting, or at a conferenceor trade show. photocopying and mailing them out to people. Now, each project has a small space on the server where materials The architects work in ways that allow them to accomplish relating to the on-going design can be found. These their dual mission of designing technically possible and practiceshave beenfurther reinforced through the emergence organizationally feasible products. They bring people from of a new departmentalstandard for documenting architecture all over the corporation in to consult on their technical work on the WWW. knowledge, and at the same time learn about other groups’ priorities and schedules. The architects present their work The WWW may be a new technology, but the practices to different groups to ensurethat the solutions are attractive that it is supporting inside the architecture department to build, buy, and sell. Finally, they continually look representa common pattern of adoption. In the beginning, outside the company to align their work with standards the technology is adopted to support existing processes, agenciesand competitors. All of this is necessarydesign and it succeeds when it supports these practices well work, without it, solutions might work, but could not be enough that people continue to use it. However, the built or sold. technology also provides new possibilities and slowly people develop new practices, and thus the technology 4 DESIGN SUPPORT: TOOLS AND PROCESSES FOR begins to influence the characterof the processesthat it ARCHITECTURE supports. The architects use a variety of technologies in their work. Clearly, the telephone and electronic mail are vital for One of these new practices is something the architects refer maintaining their networks of contacts. In this section, I to as borrowing. If an architect knows that the architecture will describe how two other technologies support their she’sworking on is similar to someoneeIse’s then she may work: the world-wide web (WWW) and a viewgraph use the WWW server to copy the relevant materials. package. Rather than redoing an architecture by hand, the WWW provides a way for architects to cut-and-pastefrom others’

14 work into their own and then make modifications as work with other sections of the organization. This work necessary. They have also found it useful for bringing new involves crossing organizational boundaries, both inside people up-to-speedwith the current state of design. Rather and outside the company. A considerable amount of their than spending time in meetings explaining the current work involves garnering support and commitment from design, the architects send people to the project web site. distant departments,maintaining current information about In that sense,the WWW becomes a repository of design development schedules, and staying current with new rationale for facilitating new design work and bringing standards,technologies and legislation. others up to date. The challenge of coordinating heterogeneousgroups has While most of the architects in this department are eager recently becomea focus for research[6J Two mechanisms and regular WWW users,they have taken on an additional for coordinating this kind of work have been previously source of negotiation. The architects now have to persuade described: boundary spannersand boundary objects. In a the people outside the department to adopt their WWW study of software development projects, Curtis, Krasner, practices. Otherwise, the architects have to send out and Iscoe [12] identify boundary spanners as people who photocopies of meeting notes, viewgraphs, and moved among different groups transferring information documentation. However, over time as a department they about the state of the project. These boundary spannersare have managed to persuade other architects - including characterizedas informal roles, adopted by individuals with those I interviewed in the other department- and others to good speaking and listening skills who have contacts that adopt the WWW. span multiple groups. Another tool that the architects use a lot is a viewgraph Clearly, part of the work of these architects involves having package. The need for a viewgraph package reflects their good networks of contacts acrossthe corporation. Unlike need to have a medium for developing architecturesthat fits boundary spanners,the architects are expectedto use these their working style, a style that involves talking with informal networks. It may not be a written requirement of numerous groups about their designs. These viewgraphs their job, but everyone knows that knowing people is an were usually produced using a tool like Microsoft essential part of being a competent architect in the PowerPointTM. company. In this sense,the corporation expects architects Although a viewgraph tool does not carry the prestige of a to work acrossorganizational boundaries. In other words, CAD tool for producing architecture documentation, it they are sanctioned by the corporation to facilitate offers the architectsat least four advantages. First, it is easy coordination across heterogeneous groups with different to draw with the tool. Compare the simple drawing priorities and agendas. This makes them differentfrom the functions in the viewgraph package with other systems: a boundary spanners described by Curtis who used their complex CAD package or text processing software. networks without any expectations on the part of the Second, the viewgraph package allows the architects to corporationsthey worked for. draw their own architectures. Another alternative would be Boundary objects are another approachto facilitating cross- to hand draw the architecture and give it to the art group and inter-organizational coordination [26]. Boundary department to draw up professionally. Not only would objectsare: they require considerable planning, but also if anything neededto be changed afterwardsthe architects would not objects that are both plastic enough to adapt to the have the ability to changethe drawing. Third, as everyone local needs and constraints of the several parties in the department uses a standard viewgraph package the employing them, yet robust enough to maintain a architects can share and borrow others’ architectures and common identity acrosssites. ([26] p 103.) customize them for their purposes. Finally, slides are One example of a boundary object is a library index, which highly portable within the corporation. Other individuals allows multiple groups - different groups of researchers work with the packagetoo. The architects can send their with differentobjectives - to use the same materials, by viewgraphs to anyone who needs to see them, and know presenting them in a standardway. A design processthat that they’ll be able to read them. Given the diverse range of involves multiple groups also generatesboundary objects groups the architectswork with this portability is critical. PI* 5 DISCUSSION These architects certainly produce boundary objects. The The last two sections described the work that these viewgraphs and web-based documentation describing the architects do to design enhancementsor new features and designs act as guides for development, let managers see examined the role that technologies play in supporting what featuresare being adding to products, help ftmders to them. This section discusses the role that the architects decide whether to support the project among other uses. play in coordinating work from two perspectives. First, I Here the portability across platforms and usability of the describehow these architects go about coordinating design technology is critical in supporting those boundary objects, acrossorganizational boundaries. Second, I discuss how becauseit lets those multiple groups accessthe design in the architectsnegotiate in a context that changes and where ways that are resonant with their own environments and their ideasare subjectto resistance. skills in using these technologies. 5.1 Facilitating Design Across Boundaries However, I would also argue that these architects are a The architectswork with people from their own department boundary object themselves through which other groups like other designers. However, these architects must also can coordinate enough to accomplish design work. Problem owners, funding groups, and developers coordinate

15 their needsthrough the architects. The architect becomesa The development context createsa number of challenges centrally located resource available to these groups. In the Bowers and Pycock [5] have describedhow the existence of corporation these architect are boundary objects known by a prototype created a gradient of resistance, which made their title and organized around their expertise with changes in line with the prototype easier to negotiate for identifiable pieces of products or skills with standards and than radical alternations. These architects work with that other technologies. Conversations and meetings serve as gradient of resistance. Much of their work consists of boundary “occasions” when the architects work to establish adding new pieces to existing product lines or changing the shared understanding of the design. The architects current technologies. These kinds of projects begin with an sharethese understandings among all the groups involved, existing base of software and hardware. The architects through their presentations. could champion a solution that involves designing from It is the institutionalization of the use of networks of scratch, but it takes more energy to convince the contacts, the title of architect, and the organizational development organizations. scheme by which others locate appropriate architects that However, this is not just a gradient of technological allow heterogeneousgroups to design products. All the resistance. The development organizations are structured technologies that architects use in their work support this and scheduled to build certain products. Over time they need to span multiple groups as seamlesslyas the architects have built up expertise in the products that the build, and themselves do. Architects are a kind of organizational defined their relationships with other groups. If the diplomat, helping the many groups it takes to build a architects suggestthat the development groups build things technically working and organizational workable product that demand changes in resources, expertise, scheduling, come together to agree on a design. and bring them into contact with other groups in new ways In this corporation, architects are one group of individuals they often find that the gradient of organizational resistance who support intra and inter-organizational coordination. grows. They do this by having work that takes them acrosslarge In turn, the architects use their own gradient of influence sections of the company. While architecturemay not play given to them by their organizational position. Simply put this role in other corporations where the architects may not designs that require organizational change requires more work in these ways, studies of other corporations suggest effort. Architects must negotiate every aspect of their that where there are organizational divisions one design with every group involved. This negotiation lies mechanism of managing the coordination required is somewherebetween the two extremesof inter-organizational through the institutionalization of a work role like the one coordination. The print shop workers in Bowers, Button thesearchitects have. and Sharrock’s [4] study had little choice in using a new For example, people responsible for release management system in their work, because it was part of their also work with many sections of the organization to find contractual obligation. In other words, the print shop the right pieces and assemble them into the final product workers were powerless to change their circumstances. [ 161. Away from the softwaredevelopment world, F’ycock While these architects are not powerless, they can not and Bower’s study of fashion design [21] also highlighted enforcetheir solutions using managerial authority, because the interorganizational nature of that work and how groups they do not manage the implementation. Instead, these of individuals have the role and authority to facilitate that architects must to convince others on the strengths of their coordination. merits that designs are worthy of implementation. Studies of these kinds of individuals hold much promise for A further complexity in managing these dual contexts is researchersinterested in the challenges of intra and inter- that they change each other over time. Changes occur in organizational coordination. These individuals can be the market or standardsthat affect the corporation’s direction interviewed and observed using field research techniques. and their customers’ priorities. Changes inside the These kinds of people offer those interested in building corporation also influence the products that architects systems to support coordination that spans divisions of a design, and so change the nature of what can be sold to corporation insight into the kinds of technologies that can customers. Architects - especially those who work on work. projects that unfold over years - find themselves making changesto their technical solutions to accommodatethese 5.2 Gradients and Contexts in Design Work updates, and renegotiating agreementsand support from In recent years a number of studies have illustrated how the other groups. One critical variable in this is the degreeto context in which work takes place influences and shapesthe which the technology in question is in a state of flux. kinds of technologies that can be adopted and used. The More mature products tend to be stable in the sense that design work here presents a particularly interesting case, new changesare often alterations to what exists. However, becausethese architects find themselves working with two other products may be much more susceptible to radical contexts, that of the customers and the development changesin areas where standards are evolving rapidly, or organization. They work to include the context of their the underlying technologies are changing dramatically. A customers - their users - while designing within the final source of change is the corporation itself, and when development context that surrounds them. Each context that happens then even the most stable of project can need createschallenges that are worked out through the design modification to accommodatethe reorganization. itself. Managing change and negotiation are core elements of the architects’ work in this corporation. Their practices of

16 involving people in the design process, giving REFERENCES presentationsand soliciting feedback,that managesto lower 1. Bass, L., P. Clements, and R. Kazman, Sofhyare the gradient of resistance,while simultaneously increasing Architecture in Practice Addison Wesley Longman, the gradient of influence. All of this continues throughout Inc., Reading, MA, 1998. the project because at any time changes from inside or 2. Bellotti, V. and S. Bly. Walking Away from the outside the corporation can have a major effect on the Desktop Computer: Distributed Collaboration and design. Mobility in a Product Design Team. In Proceedings of 6 CONCLUSION ACM Conferenceon Computer Supported Cooperative The design and developmentof large and complex products Work CSCW ‘96 (Cambridge, MA, November 16-20, is a coordination intensive activity requiring hundreds if 1996), New York, N.Y.: ACM Press,209-218. not thousands of individuals to synchronize their efforts. 3. Blau, J. R., Architects and Firms: A. Sociological While some of this work takes place among groups with a Perspective on Architectural Practices MIT Press, common goal, a considerable amount of coordination is Cambridge, MA, 1987. required that spans multiple groups of an organization that have their own particular concerns. In this corporation 4. Bowers, J., G. Button, and W. Sharrock. Workflow architectsown part of the responsibility of intra- and inter- from Within and Without: Technology and organizational design. Thus, they representan opportunity Cooperative Work on the Print Industry Shopfloor. In to study the challenges of coordinating design work across Proceedings of European Conference on Computer- boundaries. Supported Cooperative Work (Stockholm, Sweden, lo- 14 September, 1995), Dordrecht, Netherlands: In this study, I have shown that these architects work in a Kluwer Academic Publishers, 5 l-66. web of social forces like their building architecture counterparts. These forces do not create additional work 5. Bowers, J. and J. Pycock. Talking Through Design: that needs to be taken care of in order to produce the Requirements and Resistance in Cooperative technical design, they are what product architecture is Prototyping. In Proceedings of ACM Conference on about. It is the articulation work necessaryto bring about Human Factors in Computing Systems CHI’94 the opportunity to design technically a new product or (Boston, MA., April 24-28, 1994), 299-305. j featureenhancement[23]. 6. Bowker, G. C., et al., Social Science, Technical Their architecture work involves reconciling these social Systems, and Cooperative Work: Beyond the Great forces in ways that produce products that are both Divide Lawrence Erlbaum Associates, Publishers, technically possible and organizationally feasible. This Mahwah, New Jersey, 1997. meansthat these architects are not only technical experts. 7. Bucciarelli, L. L. An Ethnographic Perspective on Their practices suggest that they are also good Engineering Design. Design Studies. 9, 3 (1988), 159- communicatorsand listeners able to move among multiple 168. groups, extract their concerns, and present a solution that 8. Bucciarelli, L. L., Designing Engineers MIT Press, reachesa compromiseamong the participants. Cambridge, MA, 1994. These skills and needs are reflected in the processesand 9. Button, G. and W. Sharrock. Project Work: The technologies that the architects studied use in their design Organisation of Collaborative Design and Development work. Specifically, these architects have evolved and in Software Engineering. Computer Supported standardizeda set of practices that ensure that they get Cooperative Work: The Journal of Collaborative information and feedbackessential for the design process. Computing 5, 4 (1996), 369-386. They have adoptedtechnologies that allow them to share their work with all the interested parties readily. In 10. Carstensen,P. H. and C. Sorensen.From the Social to addition to this, the organization has supported their the Systematic: Mechanisms Supporting Coordinating collaborative activities by institutionalizing the role of in Design. Computer Supported Cooperative Work: architect. In conclusion, this study contributes to our The Journal of Collaborative Computing. 5, 4 (1996), understandingof what the challengesof coordinating design 387-413. work in a large development corporation, and the kinds of 11. Cuff, D., Architecture: The Story of Practice MIT processesand technologies that make this possible. Press,Cambridge, MA, 1991. ACKNOWLEDGMENTS 12. Curtis, B., H. Krasner, and N. Iscoe. A Field Study of I would like to thank all the architects who gave willingly the Software Design Process for Large Systems. explained their work to me and made sure that I was “in the Communications of the ACM 31, 11 (1988), 1268- loop” during projects as well as those who made the study 1287. possible. I would like to thank Paul Clement% Jim 13. Garlan, D. and D. E. Perry. Introduction to the Special Herbsleb, Sanjoy Mazumdar, David Weiss, and the Issue on SoftwareArchitecture. IEEE Transactions on reviewers for their comments and suggestions on previous Sofmare Engineering. 21,4 (1995), 269-274. drafts. 14. Glaser, B. G. and A. L. Strauss, The Discovery of Grounded Theory: Strategiesfor Qualitative Research Aldine de Gruyter, Hawthorne, N. Y., 1967.

17 15. Grinter, R. E. Doing Software Development: 21. Pycock, J. and J. Bowers. Getting others to Get it Occasions for Automation and Formalisation. In Right: An Ethnography of Design Work in the Proceedings of Ftfth European Conference on Fashion Industry. In Proceedings of ACM Conference Computer-Supported Cooperative Work ECSCW ‘97 on Computer Supported Cooperative Work CSCW ‘96 (Lancaster, UK, September 9-12, 1997), Dordrecht, (Cambridge, MA, November 16-20, 1996), New York, Netherlands: Kluwer Academic Publishers, 173-188. N.Y.: ACM Press,219-228. 16. Grinter, R. E. Recomposition: Putting It All Back 22. Rechtin, E. and M. W. Maier, The Art of Systems Together Again. In Proceedings of ACM Conference Engineering CRC Press,Inc., Boca Raton, FL, 1997. on Computer Supported Cooperative Work (CSCW 23. Schmidt, K. and L. Bannon. Taking CSCW ‘98) (Seattle, Washington, November 14-18), ACM Seriously: Supporting Articulation Work. Computer Press, Supported Cooperative Work (CSCW): An 17. Herbsleb, J. D., et al. Object-Oriented Analysis and International Journal. 1, 1-2 (1992), 7-40. Design in So&are Project Teams. Human-Computer 24. Schon, D. A., The Reflective Practitioner: How Interaction. IO, 2-3 (1995), 249-292. Professionals Think in Action Basic Books Inc., New 18. Lofland, J. and L. H. Lofland, Anat’yzing Social York, NY, 1983. Settings: A Guide to Qualitative Observation and 25. Shaw, M. and D. Garlan, Software Architectures: Analysis. 3rd Ed Wadsworth, Belmont, CA, 1995. Perspectiveson an Emerging Discipline Prentice Hall, 19. Olson, J. S. and S. Teasley. Groupware in the Wild: Inc., Upper Saddle River, N.J., 1996. LessonsLearned from a Year of Virtual Collocation. In 26. Star, S. L., Cooperation Without Consensus in Proceedings of ACM Conference on Computer Scientific Problem Solving: Dynamics of Closure in Supported Cooperative Work CSCW ‘96 (Cambridge, Open Systems,in CSCW: Cooperation or Conflict?, MA, November 16-20, 1996), New York, N.Y.: S. Easterbrook, Editor. 1993, Springer-Verlag: ACM Press,419-427. Heidelberg, Germany. 93-106. 20. Potts, C. and L. Catledge. Collaborative Conceptual 27. Strauss, A., Qualitative Analysis for Social Scientists Design: A Large Software Project Case Study. Cambridge University Press,New York: N.Y., 1987. Computer Supported Cooperative Work: The Journal of Collaborative Computing 5,4 (1996), 415-445.