Distributed Intelligence In Design

Introduction: Distributed intelligence in design

Tuba Kocatürk and Benachir Medjdoub

In the world of architecture, the emergent digital technologies have taken a significant role in how we create, collaborate, design and produce. This book attempts to address the current socio-technical transformation in the architectural industry, as a new paradigm. The increasing use of advanced 3D knowledge-rich parametric/generative tools, combined with information modelling systems and digital prototyping technologies, is already enabling radically new ways of designing and coordinating among the many actors in architectural design and production. Architectural and engineering design is becoming more and more a digitally networked practice. This has led to more distributed activities within and across disciplines and involves embedding intelligence in the formation and actualisation of spaces. Innovation in design is no longer recognised as the creation of a single product by a single designer, but as the outcome of an iterative and dynamic coordination of a cross-disciplinary intelligence that is distributed across various digital tools, people and organisations in a social context. The book tries to uncover the ways in which digitisation and digital tools have recently been adopted within the work practices of multidisciplinary firms and the evolving socio-technical networks and organisational infrastructures in architectural practice.

For quite some time now we have been debating the impact of new technologies on architectural practice and the emergent formal vocabularies. The generative, representational and collaborative potentials of various digital media and embedded computing are already well documented and discussed in various conferences, biennales and publications. Yet it would be fair to say that although the potential is huge and endless, the technological transformation the architectural profession is going through at present has not been as smooth as one would have hoped. The institutional and social structures of the building industry, as well as the high variation in its technical systems and practices (e.g. construction technologies, fabrication tools, computing software etc.), build up multiple barriers to utilizing the collaborative potential of new digital environments fully (Shelden 2006). Moreover, different digital media and collaboration styles offer radically new and, most often, varying methodologies to merge design with execution. Many practices struggle with the adoption of technologies into their work, as there is not yet any formulated method or theory of how to choose the best possible tools and organisational structures that will suit the designers’ preferred design approaches or preferred set of media. Moreover, there are more fundamental issues in the utilisation of these diverse sets of digital media. For example, although BIM (building information modelling) systems provide better data transfer and integration, they do not entirely support the creative processes occurring during the conceptual design stages. Similarly, there is a computational limitation in the design aspects that cannot be addressed parametrically with the current capabilities of various parametric and generative software packages.

How is the architectural industry responding to the possibilities offered by these technologies? How is the industry adopting and utilising these technologies and how is this adoption transforming the dynamics of practice? One obvious observation is that innovative practices are not necessarily merely adopting design technologies but are finding innovative mechanisms to structure and coordinate multidisciplinary design intelligence through various media, customised workflows, organisational structures and complementary activities. With this book, we are not aiming to start yet another anachronistic debate on ‘architectural design’ and technology, as the two are already inseparably linked. The book rather attempts to discover the controversial relationship between design innovation and technology. Technology is indeed a critical enabler of innovation, however new human networks and work practices, in their turn, facilitate the emergence of new methods to deal with the emerging knowledge and complexity affecting the ways in which the technology is adopted and used. This instrumentalisation entails the ways in which humans mediate between different media, facilitating new coordination mechanisms across various interdisciplinary actors and representations. Consequently, we can observe the spontaneous emergence of highly complex socio-technical systems where both the human/organisational structures, and the IT capabilities are distributed, diverse and heterogeneous. In these varying socio-technical formations, the interaction of the architect(s) with different project participants through different media at different stages of the design process and the extent to which this interaction contributes to product and process innovation both vary.

We introduce the concept of ‘distributed intelligence’ to further investigate the socio-technical and techno-organisational repercussions of digitally driven processes in building design and production at large. Here the use of the term ‘intelligence’ has been a very careful and conscious selection which has become the current ‘intellectual dominant of early twenty-first-century post-vanguards’, as famously put by Michael Speaks in his Intelligence after Theory article (Speaks 2007). In this text, Speaks mentions a new group of intelligence-based practices and their unique design intelligence that enables them to innovate by learning from and adapting to instability. This group is more concerned with ‘plausible truths’ generated through prototyping than with ‘received truths’ of theory and philosophy. Here, plausible truths refer to a quick way of testing ideas by doing, or making them (prototypes), and are thus the engines for innovation. In other words, prototypes create a ‘design intelligence’ by generating plausible solutions that become part of an office’s overall design intelligence. For example, a series of rapid prototyping models or generative design codes can enable the mass production of unique design solutions invented and deployed by an architectural design firm. In such a practice, design becomes more than a problem-solving exercise and creates new questions and solutions simultaneously, where the creative process is driven by an embedded intelligence.

We add a ‘distributed’ dimension to ‘design intelligence’ to end up with an even more complex entity with multiple interacting dimensions which need to be managed and coordinated accordingly. An important aspect of this complexity is the distribution of ‘design knowledge’ – the availability and orchestration of tools and ideas from different disciplines. Another aspect is the spatial distribution of ‘interacting agents’, which could further be distributed temporally when an artifact is being repeatedly modified by different user-creators over time. Finally, technological distribution involves understanding and distinguishing which medium, tool or technology is better suited for particular phases of a design. It is also important to note that architectural production is not just market, theory and/or technology driven, it also has a critical socio-cultural dimension which typically changes more slowly and incrementally than science and technology. The change is continuous, incremental and multifaceted. Therefore, in the context of this book, the uncovering of distributed intelligence refers to a multitude of interdisciplinary design knowledge constituted by different individuals with different backgrounds and experience, the media and technologies that support their individual thoughts and inter-individual communication and the social network that links them together.

The chapters in the book are compiled from the presentations and discussions of the Distributed Intelligence in Design Symposium which was organised in May 2009 by the Mediated Intelligence in Design (MInD) research group at Salford University. The symposium brought together some of the best practitioners, thinkers and educators from around the world to discuss and debate the emerging concept of distributed intelligence in design as an attempt to answer the following questions:

How have parametric and generative design tools moved the boundaries offered by conventional CAD tools and enhanced creative thinking?

How is cross-disciplinary intelligence distributed and dynamically coordinated across different design/modelling software packages, actors and organisations?

What are the characteristics of the evolving creative and collaborative practices (e.g. emerging skills, organisational and cognitive structures)?

How can architectural education adapt to this digitally networked practice and highly distributed intelligence in design?

The chapters are grouped under four main sections, each addressing a combination of methodologies and theoretical arguments, academic research work, innovative developments and state-of-the-art applications and industry experience.

From a future-oriented perspective, the book aims at presenting where we are and what can be expected in the next generation of architectural and engineering design as a collaborative practice.

References

Shelden, D. (2006). ‘Tectonics, economics and the reconfiguration of practice: The case for process change by digital means’. Architectural Design 76(4): 82–87.

Speaks, M. (2007). ‘Intelligence after theory’. In A. Burke and T. Tierney (eds), Network Practices: New Strategies in Architecture and Design. Princeton, NJ: Princeton Architectural Press, pp. 212–216.

Part 1

1 Of sails and sieves and sticky tape

Bryan Lawson

This chapter concentrates on creative conceptual design and will not deal with downstream issues of detailed technical development or the generation of production information. The title of the Distributed Intelligence in Design symposium used only the word ‘design’. It is not until we got into the description of the conference theme that the word ‘production’ appeared. From then on ‘design’ and ‘production’ were as inexorably linked like ‘love and marriage’, as the song would have it. I challenge that assumption, all the more dangerous because it is implicit rather than explicit. In particular, I am concerned about the dangers of developing knowledge structures and applications for the production stages of construction that then wash back into design.

In a paper very well known in the design research world, Nigel Cross asked us: ‘Why isn’t using a CAD system a more enjoyable, and perhaps, also more intellectually demanding experience than it has turned out to be?’ Nigel argued that CAD may in some cases be quicker, but it is more stressful and there is no evidence that the results are better (Cross 2001).

I have taught in schools of architecture that are privileged to have the most able students of their generation. Whether in Sheffield, in Singapore and China, in Holland and Norway, in Sydney or America, I find the same thing. Students no longer think computers are either difficult or extraordinary; they are just a fact of everyday life. Many architecture students find that computers are not a very appealing part of their design lives. My graduates regularly give voice to a tormenting dilemma. Listing their considerable CAD skills in their CVs often helps them to get a job. But they live in fear of their project leaders discovering this, especially during their years of practical training. They return telling tales of being sat for months in front of a computer exploited as ‘CAD monkeys’. They have a plethora of terms for the abuse of computers in design, from ‘Photoshop rash’ (the over-application of textures and photorealistic skies) through ‘Macfontopia’ (indiscriminate proliferation of fonts made so easy by the Mac) to ‘Modelshop bargains’ (an over-reliance on 3-D modelling forms). I have censored the names they have for principal partners who insist on all this nonsense to impress their clients but are unable to do it themselves.

Our students were further discouraged when one of their number won a major national award for his use of CAD and yet, with the same submission, failed his master’s degree.

My professional experience is hardly more encouraging. I am part of an international consortium that won the competition to masterplan about 100 hectares of central Dublin known as Grangegorman. The lead architects, Moore Ruble and Yudell, are in Santa Monica; the transportation planners, Arups, and conservation consultants, Shane McCaffrey, in Dublin; the landscape architect, Lutzow 7, in Berlin; the sustainability engineers, Battle McCarthy, in London; and I am in Sheffield. We met as a team roughly once every six weeks, but otherwise relied entirely on IT to communicate across continents and time zones.

What software did we use? Obviously we had an FTP server that held jpegs, Microsoft Office documents and pdfs. The size of such files was already a problem and exchanging CAD files or other active documents was impractical. We largely relied on Word and Acrobat Reader. We used some very basic 3-D modelling software but created inert pdf files for exchange. We often sketched over them by hand, digitised and returned similarly dead files. It worked OK, but relied heavily on the trust established in the face-to-face workshops where we sketched by hand and looked at physical models. How disappointing after all these years!

The vast majority of the software most architects use today is generic. We manipulate pixels and vectors and occasionally use crude solid modellers and generic word processors and spreadsheets. The few big CAD systems are not specifically architectural, although some have what you might call an architectural accent such as the Bentley suites. Even these are really AEC rather than architectural in their way of thinking and working. When we recently did research with architects in the UK using the Bentley suite, we struggled to find any operating the latest version or making sophisticated use of its supposed architectural features.

Design as a cognitive task

From a psychologist’s perspective, our view of the possible role of the computer has changed and I want to suggest it is now in need of another paradigm shift to take us forward. The first people in this field (Whitehead and Eldars 1964, Auger 1972) expected that long before now computers would be designing buildings.

More recently, I have worked with cognitive scientists who are in what we might call the ‘computation theory of mind’ camp. This artificial intelligence theory in essence claims that eventually we will make computers do what our brains can do; the only problem is we have not yet got big enough and powerful enough machines and sufficiently sophisticated software languages. Many of us have felt uncomfortable about this for a while, but each time we threw a new challenge down they would eventually rise to it. ‘OK,’ we said, ‘computers can play noughts and crosses, but they can’t play draughts.’ They did, so we challenged them to play chess. Of course they did that too. Then we cheated and demanded they beat the best human players. Guess what? They did, although no one seriously claims the software uses human-like cognitive processes.

At last cognitive scientists are seeing design as the challenge that collapses this house of cards. You could trace this argument through Jerry Fodor’s The Language of Thought (Fodor 1975) and then on to Dreyfus’ What Computers Still Can’t Do (Dreyfus 1992) and Vinod Goel’s Sketches of Thought (Goel 1995). AI claims that we can represent all useful knowledge through symbol systems and thought through the manipulation of those symbols. Our view now is that it does not seem possible to represent design knowledge and processes in this way. The leap from chess to design is not the same sort of thing as the step from draughts to chess. It is fundamentally different. This is beautifully illustrated through the famous paradox that Bar-Hillel advanced to show the unfeasibility of automatic language translation (Bar-Hillel 1964).

He asks if we could understand the sentence ‘The box was in the pen’. At first it might sound like a transposition error. But if it was in the context of a child looking for a toybox and possibly being in a playpen, then we can work it out. However, there simply is nothing in the symbol collections themselves that gives this away. We have to bring other knowledge into play and the symbols give no clues about that knowledge, what it might be or how it might work. We do not know how to make a computer that could work this out; and yet we find it easy. Designing is full of this sort of knowledge and this sort of thinking. In fact, they are at the very heart of creative designing.

At an RIBA CAAD symposium a software developer prefaced many remarks with the phrase ‘the trouble with architects is…’ I suggested that if the vast majority of architects behaved in the same way there were two possible explanations. The first was that all the most stupid people in the world had by chance chosen to become architects. The second was that perhaps they had adapted to their situation intelligently. So we had better darned well try to understand not just how architects think, but why. This idea offers a small creative leap that may help re-orientate us here. Once we start to think about the cognition of designing rather than of generating production information, we might not see the architect as part of the construction industry but rather as part of the design industry. This is quite a paradigm shift and I think a necessary one.

Lawson and Dorst lay out a description of what constitutes design expertise (Lawson and Dorst 2009). The model we develop shows a series of levels, rising from the novice through the advanced beginner and competent up to the expert and master and, finally, the visionary. One key finding is that designers operating at higher levels of expertise do not simply do the same things as lower-level experts. They are not quicker, better, more accurate or efficient. They actually do quite different things. In a curious way, they think less.

This model fits into a more generic set of ideas about cognitive expertise. De Groot showed that chess grand masters did very little analysis of board situations but rather recognised them (De Groot 1965). Advanced architects similarly recognise design situations. They can see parallels with other situations they know well. That knowledge about situations also incorporates ideas that in chess would be thought of as gambits, or bits of solutions that can be used, each having advantages and disadvantages. Complex situations may be made up of many of these. Architects talk of precedent, by which they mean the panoply of previous situations that can be brought to bear on the case in hand. Unlike lawyers who seek to show the accuracy of precedent, architects seek to interpret it more creatively and to draw it from apparently remote sources. This is a key feature of what we normally describe as creativity.

What this model also shows is that the cognitive support we might need as novices is quite different from that we might need when we are competent and certainly when we are masters or visionary designers. Since I seek excellence rather than the mundane, I am interested in how this affects education and the impact that such ideas might have on the higher levels of architectural design.

What is so different about design?

A key question you might ask here is: ‘What is it then that is so different or special about designing as a cognitive task that makes architects think in such peculiar and infuriating but ultimately fascinating ways?’ The answer to this question is long and complex, but some key points can be developed here with specific reference to how we might develop computer tools to aid distributed intelligence in design.

Design is not like chess. When I was recently designing a garden shelter, I had just spent time in Bali looking at their special way of designing traditional houses and temples. I had seen the Pondoks crafted by rice workers to allow them shelter from the intense midday sun in the open terraced fields dug out of the lower slopes of the sacred mountain. Knowing this, it should be clear that the design of my ‘pondok’ was heavily influenced by ideas from Bali, reinterpreted for our landscape and climate and my purpose. There is nothing clever or extraordinary about this; it is the way architects work. Had I been in Africa or South America rather than Asia, it is likely my pondok would have looked different. Design relies, then, on unbounded knowledge. No statement of the problem can symbolically encode information that gives reliable or comprehensive clues as to the kinds of knowledge that might usefully be employed in solving it.

For more problematic features of this world of design cognition, we turn further east to Sydney Opera House. This building is special because it has become so well loved, memorable and symbolic. It represents the unique place in which it belongs, Sydney Harbour, a new culturally progressive Australia, the time it was built and many other ideas. It is fascinating not just as a product but also as a process that has been well documented and teaches us many lessons about designing.

Central to the design are the great concrete sails that simultaneously perform many tasks for Utzon, the architect. They create a magnificent composition sitting perfectly on Bennelong Peninsula jutting out into the very heart of Sydney Harbour. They act as a perfect counterfoil to the famous bridge against which they are so often photographed for that reason. They subtly reflect the sails of the myriad small yachts that often surround the building. Of course, they also house the great spaces of the opera auditorium, the concert hall, the smaller restaurant and the public domain. They create opportunities for solving the tricky problems of threading services through such a complex and demanding set of volumes. They offer a structural system that is self-explanatory, efficient and beautiful when exposed. I could go on.

How can one mind arrive at a single device that simultaneously does so much on so many levels? In truth, the sails perform far better at some of their tasks than others. They leave spaces that have poor acoustics, though that is not really Utzon’s fault. They insult and discriminate against the disabled. They make life hell for stagehands; ridiculously, the public approach is from the stage end of the opera house. It is well known that Utzon designed the sails before he knew how to build or even draw them and this was one of the factors that would drive the initial contractor to financial ruin. Again, I could go on.

And yet we forgive the building all these inadequacies because it is so magnificent in so many other ways. To have become one of the best-known buildings in the world with all these faults shows just what a fantastic achievement it is. It narrates a very human story of genius that succeeded in the face of so many difficulties and yet also failed our unreasonable expectations of perfection.

So what do we learn here? Design depends on integrated responses to many disparate factors in one single device in ways that could not possibly be predicted from any symbolic representation of requirements. These factors cannot be measured against criteria with any common metric for success. Which of us can say how many more stairs we are prepared to walk up in order to get the memorable view that Utzon creates for the interval promenaders out in the middle of the harbour?

New ways of communicating with computers

Architects must be using extraordinary mental gymnastics when designing. This implies the existence of a multidimensional cognitive structure that enables multiple ideas to be considered and developed. So if computers are going to assist us in designing, surely weneed to converse with them in ways that are at least as sophisticated as we might use when working with other designers. Is this realistic?

Some 30 years ago, my research group developed a suite of CAD programs for designing architecture known as GABLE (Lawson and Roberts 1991). They were founded on the principles of intelligent building modelling and on some key ideas about the nature of architectural design processes. They allowed architects to describe buildings in a variety of cognitive modes observed to be in common usage (Lawson and Riley 1982). Thus one could draw elements such as walls, windows and doors and GABLE would infer a spatial model. Alternatively, one could move, combine or divide spaces and GABLE would update the elemental model.

Back in the 1980s this system was in international use in both practice and education. We learned a huge amount from its use, not so much about CAD but about designing itself and about the complexity of knowledge representation in design. Eventually GABLE failed for a number of reasons, but the main intellectual failure turned on some unwarranted assumptions that are still going unquestioned today.

We must decide the extent to which we expect such systems to be central or peripheral to the creative design process. John Lansdown asked this question decades ago, but few have explicitly attempted convincing answers (Lansdown 1969). He pointed out that there were two fundamentally different strategies we could employ, which he called ‘ad-hoc’ and ‘integrated’. He foresaw a wide range of applications, for example thermal evaluation, daylighting studies, visual form, costing, structure and so on. He realised that such applications need different though overlapping sets of data about features of the design.

Assuming that as designers we might like to be able to see how well our design is working on a number of criteria, how do we input the necessary information? In what Lansdown call the ‘ad-hoc’ strategy, we input the information needed as we use each individual application. So if we want to perform a simple steady-state thermal evaluation, we would need u-values and the areas of the external skin components. If we want a natural lighting study, then geometry, transmission, reflection data and orientations would be required and so on. This means a very halting process for the designer. Every time you want to examine the design along some dimension, you have to stop and input data.

An illustration of how impossible this would be can be seen from simply observing students. They are struggling to develop an integrated response, a task already almost too demanding for their early level of expertise. They need advice from a range of tutors, about architectural form, construction, structures, environmental control and sustainability. At Sheffield we now have this in-house, but previously structures was a service taught by our civil engineering department. To get advice on structures students had to phone up, make an appointment and then go to the other side of the campus. They did not do it, of course, and we saw many projects that were innovative climatologically but very few that were innovative and creative in structural terms. This ad-hoc idea simply does not work for designers. It would not work for the sails of Sydney Opera House. Utzon could never have used it.

So we turn to Lansdown’s ‘integrated’ strategy and link all the evaluation packages to a single database, now variously described as building information models or n-D models. Each evaluation then runs immediately.

Salford and Sheffield universities collaborated on a research project to create support systems to record and make explicit design rationale (Cerulli et al. 2001). There were several objectives. First, the need in a multiprofessional, and often not co-located, team to know who is making what decisions and why. This becomes especially important when things happen in parallel. The classic example is the scenario in which the architect issues a general arrangement floor plan and the M and E engineer starts to run services through routes that the structural engineer is busy blocking. The architect is often left trying to spot this and we all think that CAD clash checking would be the answer.

However, things often get even messier. Our drawings show the decisions but not the reasoning. Later on, someone who may not understand the reasons changes things without realising the damage they are inflicting on the design. Being able to see the thinking behind the design at every stage is far more important than just the clash checking. In the design of Sydney Opera House they built a huge perspex model so everyone could see how spaces were interconnected and related. Today we would think of doing this on a computer. Somehow the physical model still does the job better. Incidentally, this model is now seen as a security risk, since the knowledge it imparts could greatly facilitate terrorism.

The Sheffield–Salford project worked with the Bentley software and logged the complete state of the model, traced all additions and changes and recorded the rationale. Instinctively, we decided to plug our software into the CAD software. All very logical: as you called a routine to add, delete or edit a model element, you automatically accessed the rationale capture software. However, field trials revealed that this was hopeless. More often than not, key decisions were taken away from the computer model.

By way of illustration, you can see a most creative process at work in the Philadelphian offices of Bob Venturi when designing his famous extension to the National Gallery in Trafalgar Square (Lawson 1994). One of Venturi’s key forming concepts in this design is how the new architecture relates to the existing Wilkins’ building, so famously described by Prince Charles as ‘a much loved friend’; this, of course, when he so unfairly criticised the previous competition-winning design by ABK. Venturi had the original façade computer modelled, plotted out and cut up into pieces with scissors. These pieces were then stuck around his new physical models with sticky tape. How ironic to see a computer metaphor being used far more creatively in its physical reality.

The normal situation, then, is that key design decisions are often made over sketches or physical models, on telephone calls or at meetings, on