Architecture as Metaphor

James O. Coplien

Bell Laboratories

cope@bell-labs.com

Martine Devos

EDS

martine.devos@eds.com

Most of the software development community uses a longstanding metaphor for a key technical project lead, the role responsible for the overall system structure and vision. Sometimes defined as the "keeper of the flame," the role of architect draws on parallels with the role of the same name in the building profession. The term had strong tones of metaphor from its earliest use. But the term is certainly in universal vogue across all kinds of software development cultures, where it usually evokes--at least in hopeful terms--the romantic image of the prestigious position of the classic architects in the days of Vitruvius or Alberti.

The "Architecture as Metaphor" workshop at  OT '99 was designed to investigate how the software community perceives the similarities and differences between software architects and building architects. The OT '99 call for participation says:

It is perhaps important to emphasize that the goal of the exercise was not to do a studious comparison of the two professions--though we of course would like to base the exercise on as well-founded impressions of the building profession as possible--but to investigate how software architects view themselves relative to their perceptions of the building profession.

Prior Art

Jerry Weinberg relates that he was teaching lessons from the history of architecture in his system development classes at the IBM Systems Research Institute in the early 1960s when Fred Brooks came to visit him to ask if the term "architect" was suitable for systems people. There was concern about whether the analogy was appropriate or not, but after some discussion to flesh out the analogy, the term came into wider use following Brooks' lead [Weinberg1999].

…software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as town and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem. As one single example of such a source of ideas I would like to mention: Christopher Alexander: Notes on the Synthesis of Form. [NATO1968]

Software design is a lot like building design. ("Architecture" is a term of art in programming.) [WSJ1999]

In other contemporary literature, Dahlbom [Dahlbom1992] argues that reality (including software construction) is a social artifact apart from any corporeal manifestation associated with materials or objective reality, but that we nonetheless interact with it using the same faculties as for material constructions. The architectural metaphor figures strongly in Dahlbom's arguments.

But there is an important "man bites dog" aspect to the relationship between the two disciplines as well. L. Bruce Archer writes:

The most fundamental challenge to conventional ideas on design, however, has been the growing advocacy of systematic methods of problem solving, borrowed from computer techniques and management theory, for the assessment of design problems and the development of design solutions. [Archer1965]

…The emphasis in making computer software, as with traditional craftwork, is upon the processes of using the product, its ease of operation, its suitability for the task and its adaptability to the user's specific requirements. With all computer software, the user's experience, rather than the physicality of the product, becomes the focus; the traditional concept is extended from physical objects to intangible processes.

The contrast between traditional product design and the new craft-derived approach of many software makers is analogous to the conflicting purposes of traditional and avant-garde modern art. Just as the transition from traditional art to modern art entailed not so much a change of style, but rather a complete change of attitude, approach and method, so the traditional product design approach and the emerging notion of designing as a process represent fundamentally different conceptions of design. The work of the artists of the avant garde provides a useful insight into how the transition from work with physical outcomes to purely conceptual work can be realized. [Mitchell1988]

The more I see of software designing the more I notice resemblance not to design in other fields but to craftsmanship. In each the designing, if such it can be called, is done by the maker, and there is much fitting, adjusting, adapting of existing designs, and much collaboration, with little chance of a bird's eye view, such as the drawing board affords, of how the whole thing is organized, though, in craft evolution, if not in software, the results have the appearance of natural organisms or of exceptionally well integrated designs. But there is an important difference: software is increasingly made by modifying the actual material of previous pieces of software, as a building may be altered for a new use, whereas a waggon-maker, for instance, modifies the form, but does not reuse the material, in making each small step in the gradual evolution of his product. As in natural evolution, each alteration is made without conscious intention, or plan, of what kind of artefact may later appear out of the seemingly blind process of making corrections, here and there, as and when lack of adaptation to the working conditions, or to the materials or the making process, becomes evident. But there is a tremendous respect for the form, as it has evolved so far, embodying, as it does, the otherwise unrecorded history of a thousand ways in which the artefact and its context can be attuned. [Jones1988]

The OT '99 conference has a reputation for pushing the envelope, and we used the informal and tolerant nature of the venue to our advantage. We used two techniques: group theatre, and a simplified version of grounded theory suitable for group interaction. The workshop comprised an eclectic audience (Attachment 1), a majority of whom claimed to be practising software architects.

Grounded theory (Attachment 2) is based on asking questions about the phenomenon in question. We primed the activity by posing the following questions in the call for participation:

1. What is the relationship of architects to cultural norms and fashion?
2. What is the relationship of architects to "true beauty" that transcends fashion?
3. What do architects produce? Do architects also implement? What is the role of as-builts?
4. How do architects deal with customization?
5. Where do architects work? On site? What does "on site" mean?
6. What is the esteem of architects in their respective professions for different cultures? What are the correlators for esteem or value for the role of architect?
7. When do architects start? When are they done?
8. Who do architects listen to? Who do they talk to? In the typical case? In the ideal case?

We started the session with an overview of the activities that would ensue. We described the workshop as an improvised play for two players, one a software architect, and the other a building architect. The setting was to be a public park bench that favored a chance meeting between the two architects. Several audience members felt they had especially good insights into the workings of the minds of building architects; some had worked with architects to design their own houses; some had best friends who were building architects; Russel Winder is the son of a building architect. I started in the role of software architect, and Tony Heap started in the role of building architect.

The audience was asked to observe the play attentively and to note salient concepts that arose in the dialogue. Each concept was captured on a card and thrown on the floor, in the area between the actors and the audience (most of whom were seated on the floor). In grounded theory, this is called open coding. (In describing the analysis techniques for the workshop, we largely avoided grounded theory lingo.) At the end of the play, we collected the cards and organized them into categories. The intent was to look for linkages between the categories (which is axial coding in grounded theory), to further flesh out each category, and to develop some rudiments of a theory of architecture from the exercise (which is done in a grounded theory exercise called selective coding). We didn't get that far, but we were able to converge seven preliminary categories.

During the play, any audience member who felt it absolutely necessary to contribute could either replace one of the actors, or could enter the play as an actor playing a role of their choice. We had cameo appearances by software developers, by bricklayers (including one "Extreme Builder" who extolled the woes of Brick Ownership), by people having houses built, by Christopher Alexander (someone who was familiar to the software architect, but a totally unknown personality to the building architect), by a dog who was curious about the building architect and who did a nasty deed to the software architect (a dog curiously reminiscent of last year's OT chair), and a few others. The actors for the architecture roles changed out a lot--the building architect more so than the software architect, surprisingly enough. Perhaps no one wanted to be on the hot seat.

The crowd had rather a self-deprecating tone to it, as though the architects had come to do penance or to take part in a pilgrimage of sorts that would enlighten the way to improvement. Part of this might be wrapped up in British culture (self-deprecating humour is a characteristic element of British advertising and cultural criticism) and part of it might owe to the frustration in the profession.

The crowd seems did seem to take strong ownership for the metaphor, which combined with the slightly self-deprecating tone, made for an open setting where few inhibitions took root. There was open but thoughtful communication both in the role-play and in the ensuing analysis exercise.

1. Change: How do architects deal with change? This was actually one of the last categories proposed, but it turned out to be one of the most insightful.
2. Role Interaction: Who do architects interact with? This was the first category that came out of the axial coding exercise.
3. Structure: What is the role of the architect in shaping structure? This subsumes the originally proposed category "Materials".
4. Economics: What economic processes does the architect participate in? This was originally proposed as "Funding" and then broadened.
5. Constraints: What are the fundamental constraints that limit the architect in each profession?
6. Process: This subsumed the proposed categories Planning, Division of Labor, and Work Practice.
7. Professionalism: This subsumed the proposed categories Responsibility and Liability.

Role Interaction: With whom do architects interact?

The Role Interaction group bifurcated the world into a client community and project worker community:

The role interaction group produced the above diagram depicting architect communication in a project. They viewed the architect as often being the single point of contact to the client and as the interpreters of both the contract and architectural vision to the workers. They negotiate with the client and "reflect", perhaps artistically, on the client needs. The interaction at this level is much the same for the software and building architect--an observation that would be borne out in the process category.

A main finding of another workshop I attended (Andy Moorley's "Architects are from Mars, Developers are from Venus") is that architects spend a lot of time carrying information from person to person -- being information brokers. This facet of the architectural role is corroborated in at least one other study [Grinter1999] . Cher Devey notes that architects may play both of the potentially conflicting roles of information brokers and negotiators.

Structure: What is the role of the architect in shaping structure?

Perhaps the most noteworthy thing about this chart (Table 2) is that building architects are credited with influence over all aspects of structure, whereas software architects are accorded no influence (Ø), questionable influence (?), or an even stronger version of Ø (X). The place of aesthetics and fashion are questioned for software, but software architects are given some credit for dealing with architectural style.

Axial analysis -- so-called because it takes place along the axis of the categories -- is the due consideration of relationships between the categories. We try to link categories together at the level of their properties and dimensions. Here, we visit each category in turn and examine linkages to other categories.

Change

The Change category highlights the central concerns of change management that fall into the architect's domain. We also see change considerations in the Economics category, particularly with respect to large lump development. This is a central concern in the architecture work of Christopher Alexander, whose influence on software may be as profound as his influence on architecture of the built world. Funding is a crucial consideration in system evolution. Most contemporary personal homes have front-loaded funding. The occupant's payout for this expenditure is protracted over a 20- or 30-year mortgage. While mortgages make it possible for people to afford homes beyond the means of their monthly income, they also lead to interest expenses that dwarf the actual cost of the house. That interest money is money that could be used to improve the houses instead of feeding bank investments. To solve this problem, Alexander proposes building houses piecemeal. Piecemeal growth attacks additional problems: one never fully understands requirements up-front, anyhow, and houses should grow to accommodate increasing understanding in needs. And a builder cannot achieve a true sense of accommodation and comfort in an edifice that's master planned: only in one whose growth is tailored to the needs of the edifice over time.

The Change team mentioned the issue of iteration as well, noting iteration is a staple of software but that little happens in construction.

The Economics team found that both software and builders deal with maintenance and whole life cost. However, software models tend to be back-loaded: Boehm's oft-quoted figure notes that 80% of software expense goes into maintenance. Houses are more front-loaded -- another change concept that surfaces in the Economics category. Brand (How Buildings Learn [Brand1994]) notes that the greatest buildings are so adaptable, at a deep level, that they can serve many purposes over a long lifetime. They may change not only function, but form as well, over that lifetime: the original form does not reflect all the functions the building can support.

Role interaction

There is a strange dichotomy between the present architecture and planning professions. On the one hand, the architects are in the habit of creating completely mad idealistic utopias. These utopias often have little meaning, they are unlikely to be implemented; often no one in his right mind would want to implement them. They are personal dreams, not anchored in reality. Archigram’'s city on legs is an extreme example. [Alexander1969]

The three basic elements of grounded theory are concepts, categories and propositions. Concepts are the basic units of analysis since it is from conceptualisation of data, not the actual data per se, that theory is developed. Corbin and Strauss (1990, p. 7) state:

The second element of grounded theory, categories, are defined by Corbin and Strauss (1990, p. 7) thus:

The third element of grounded theory are propositions which indicate generalised relationships between a category and its concepts and between discrete categories. This third element was originally termed 'hypotheses' by Glaser and Strauss (1967). It is felt that the term 'propositions' is more appropriate since, as Whetten (1989, p. 492) correctly points out, propositions involve conceptual relationships whereas hypotheses require measured relationships. Since the grounded approach produces conceptual and not measured relationships, the former term is preferred.

The generation and development of concepts, categories and propositions is an iterative process. Grounded theory is not generated a priori and then subsequently tested. Rather, it is,

... inductively derived from the study of the phenomenon it represents. That is, discovered, developed, and provisionally verified through systematic data collection and analysis of data pertaining to that phenomenon. Therefore, data collection, analysis, and theory should stand in reciprocal relationship with each other. One does not begin with a theory, then prove it. Rather, one begins with an area of study and what is relevant to that area is allowed to emerge. Strauss and Corbin, 1990, p. 23. Emphasis added.)

[Alexander1969] Alexander, Christopher. Major changes in environmental form required by social and psychological demands. Ekistics, volume 48, 1969, pp. 78-85.

[Alexander1977] Alexander, C. A., et al. A Pattern Language. New York: Oxford University Press, 1977.

[Archer1965] Archer, L. Bruce. Systematic Method for Designers. In Nigel Cross, ed., Developments in Design Methodology. Chichester: Wiley, 1984, reprinted from a work published by The Design Council, London, in 1965.

[Brand1994] Brand, Stewart. How Buildings Learn: What happens after they're built. New York: Viking (Penguin Group), ©1994.

[Dahlbom1992] Dahlbom, Bo. The Idea that Reality is Socially Constructed. In Floyd et al., eds., Software Development and Reality Construction. Berlin: Springer-Verlag, 1992, pp. 100-126.

[Darke1979] Darke, Jane. The primary generator and the design process. In Nigel Cross, ed., Developments in Design Methodology, p. 177. Chichester: Wiley, 1984, reprinted from an article in Design Series 1(1), 1979, 36-44.

[Grinter1999] Grinter, R. E. (1999) "Systems Architecture: Product Designing and Social Engineering." ACM Conference on Work Activities Coordination and Collaboration (WACC '99) San Francisco, California: February 20-22, 1999. 11-18.

[Jones1988] Jones, John Chris. Softecnica. In John Thackara, ed., Design after Modernism. P. 219.

[Mitchell1988] Mitchell, John. The product as illusion. In John Thackara, ed., Design after Modernism. P. 211.

[NATO1968] Naur, P. and B. Randell, eds. Proceedings of NATO Software Engineering Conference, Garmisch, Germany.

[Strauss+1998] Strauss, Anselm, and Juliet Corbin. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. London: SAGE Publications, ©1998.

[Weinberg1999] Personal interview with Jerry Weinberg, 31 May, 1999..

[WSJ1999] Petzinger, Thomas, Jr. The Frontlines: To get machines to talk to each other, two men write human language. Wall Street Journal, 14 May 1999, page B1.