concept

A while back (like two months ago) Mike and I were discussing what the project was about. Initially I talked about a 'time capsule for project thinking' but then it moved on to 'stream of conscious' and from there to the metaphor of a river and navigating against the current (sometimes without a paddle). This metaphor crystalised into a fairly tidy little diagram that describes a number of the ideas at play.

Essentially the diagram maps the quantity of decisions against time. The majority of design and development decisions occur in the first half of a project. Once construction begins onsite  decisions must be made but for the most part the impact of these are not as significant as what has gone before. The diagram takes a simplistic view of the design/construction process, breaking it into four stages for clarity. In actual fact its very rare to find such distinctions along a timeline but for clarity's sake it has been shown this way to illustrate the different transition periods. As the project shifts between phases a 'firewall' is erected that typically filters the quantity of information passed through to the next phase. This filter manifests itself as a project milestone that is typically clearly defined and used as a yardstick for assessing payment, progress and success. For example, the briefing phase generates a concise brief, from conceptual design comes a proposal and the outcome of design development is construction documentation and formal consents. Most (if not all) of the background work related to these final documents are archived, lost or deleted. Also as a project shifts phases the participants and 'key figures' change (even internally within an architecture practice), resulting in further knowledge leakage. The emphasis of this research is to provide a digital means of moving back through project time, peering through the internal firewalls to examine past decisions and conversations in order to better understand the project's evolution and resolve its present issues.

Recently Mike and I met with a couple of representatives from Bentley. It was interesting to talk to them, basically it boils down that Bentley has taken a hands off approach in the New Zealand market and now they have realised that does not really work, especially when they are up against very vocal ArchiCAD and Vectorworks salesmen and an industry entrenched in AutoCAD. The first reaction when I described my research was 'ProjectWise does this already'. This is in part true of any Internet-enabled, project documentation management tool such as the aforementioned Bentley ProjectWise, AutoDesk Buzzsaw, Constructw@re or Prolog (a glitzy Flash demo for is available here). However there are some significant differences between the approaches that I should go into.

Recently I submitted an abstract for the CAADRIA 2006 'Rhythm and Harmony in the Bit-Sphere' conference in Kumamoto, Japan. I am pleased to say the abstract was accepted so now I have the arduous task of completing a paper for submission January 21st 2006. The comments that came back were very good (compared to others I have received) and these are included below the abstract.

USING WEB 2.0 TECHNOLOGIES TO PRESERVE DESIGN HISTORY AND IMPROVE COLLABORATION

Abstract. This paper describes ongoing research into how emerging Internet concepts used in conjunction with existing Information Technologies (IT) can improve inter-project communication and understanding. The emphasis of the research is to use technology as an enabler to share personal thoughts and enhance the conversation that takes place within a development team. It stems from the observation that the emphasis of many new Architecture, Engineering and Construction (AEC) technologies is to minimise and diffuse project conversation with highly complex, machine interpretable building information models.

Ignoring front-end clients which could come in a multitude of formats (from web browser to CAD plugin) the backend application would be divided into three major backend pieces.  These pieces of functionality are divided in order to maximize deployment flexibility in a multitude of environments. The system uses two accepted methods of data transfer on the Internet: email and file transfer via a server (FTP/HTTP). By using a standard, non-proprietary means of data submission a multitude of clients can be supported or built using existing technologies. The three back-end components to the application are:

In previous meetings Mike and I have discussed how the system would operate (along with a lengthy discussion about Google Maps/Earth). One import issue Mike brought up was the role of versioning and how that would play out in the system. I think at this point there is a distinction to draw between the IT/programming concept of 'versioning' and one an architect may hold. In programming versioning is the process of tracking changes from a given point in time based on a set of very clearly defined parameters.

I often wonder what the Google founders were researching at University and if it had anything at all to do with Google or Internet search. Assuming they did and they decided to tackle the problem of 'relevant search' I am then left wondering how do you academically describe 'relevant' in a way that is testable.

My direction has been set primarily by a bunch of observations gathered from a number of other issues in the modern AEC environment. There are some clearly identified issues with the rigidness of the briefing process that are an ongoing concern within the industry. An issue I have been grappling with is how brief requirements and conceptual issues can be maintained and reevaluated throughout the design and construction process. Following a traditional process a briefing document is prepared and the architect responds to this with a set of working drawings. Other participants (contractors, engineers and consultants) typically only interact with these formal working drawings or the completed work. As a consequence of this reinterpretation the consumers (client/occupants) find it difficult to change their requirements whilst the producers are left with a partial understanding of the overall intentions and evolution of the project.

Solving this problem is reliant on clear and consistent communication. A major issue in communicating architectural ideas is the language in which this conversation takes place. An obvious focus for this debate is the richly detailed computer models that constitute a large portion of contemporary project documentation.  Building Information Model (BIM) theory is attempting to establish a unified 'model' in which the life-cycle of of building can be tracked and monitored. Unfortunately the structured nature of this model makes capturing and relating informal conversation about a project very difficult and time consuming as fitting these snippets of information into a highly structured model is very difficult (and adapting existing models to suit informal structures impossible).

Compounding the BIM advocates is the limited degree of Information Technology uptake throughout the AEC industry. Whilst proposing the use of highly technical BIM's may suit the management tier of a project (architects, engineers and consultants) it does not 'downsize' well into the production arena where technology skills and resources are low or enable those unaccustomed to the concept (clients and occupants) to participate at an even level. What is required is a lowest common denominator means of transferring and storing this informal conversation in a manner that facilitates later reuse in the design process or within a much higher level Building Information Model.

These issues all fall under the general umbrella of 'knowledge management' which is a formal term for 'stuff we should really note down and hopefully don't forget'. Whilst at the Manchester conference last year I sat through many (rather dull) presentations about the subject and how it fitted into the AEC industry. Given the level of interest at academic and even professional levels there is obviously some demand for knowledge management but I think it should be known more appropriately as information reuse. Knowledge is something that you have learnt over time through the process of doing and parsing different information sources.  

Before moving on I must say the last couple of weeks have been much better than previous ones. The once problematic client server is now behaving itself beautifully and I have even had a chance to document it all so I (or anyone else) can do the same thing all over again. Now back to more interesting things (if you do not consider SAMBA networking and Logical Volume Management boring)....

To recap this thesis aims to deal with the informal knowledge that slips between the cracks as an architectural project evolves. The process of architecture is very good at documenting the formal, whether is be in the form of a comprehensive brief or a set of working drawings. What I believe has been lost is the informal glue that holds all of these formal pieces together. Whether or not this informal glue ever existed is a matter for contention. The 1998 report by the UK Construction Task Force titled 'Rethinking Construction' sited major issues with the briefing process and the manner in which information from different strands of development failed to be applied in the final construction. The big issue here is that you have a lot of people doing many different things at the same time and most of it somehow impacts on the way others will be working or set-out to solve problems. When design or construction documentation is exchanged it forms the basis for a whole series of informal and formal discussions that in most cases remained contained within a particular group of people. At the moment, apart from sitting in on every meeting and listening to every conversation, there is no easy way of determining how the project is proceeding and what changes are taking place that my effect a particular aspect of the project.

A considerable amount of knowledge is also lost during transition phases like moving from design to construction or at the point of hand-over. At these times often documentation is paired down and tidied up to meet formal requirements (such as building handbooks). When applying a Building Life-cycle approach to this information it is only logical to consider how the informal discussions and decisions fit within this information puzzle.

In the late 1990's project intranets where targetted as a useful way of storing project pertanent information (Zarli, Richaud, Buckley. Requirements and Trends in Advanced Technologies for the Large Scale Engineering Uptake, 1998). Products like AutoDesk's Buzzsaw and CollaborIT. Given the amount of 'buzz' at the time very few projects adopted a project intranet style of approach. A primary reason for this limited uptake I believe is the potential productivity gains of using a centralised system are outweighed by the time and resources needed to setup the process. Tools like email can be easily applied within project groups as it is ubiquitous whilst more powerful groupware tools like Microsoft Exchange or Novell Groupwise could not.

A couple of weeks ago I talked with my supervisor Mike Donn about these things. In our discussions we talked about testing a pilot system out with students. The idea would be that a class would use an online information gathering system and then at the end of the process evaluate how their thoughts as recorded in the system influenced the outcome of a design produced by a second or even third person.

Mike also wondered what role the project schedule played in the system. This was an interesting angle that I had not considered. On thinking about it including the project schedule (both proposed and actual) made a lot of sense as much of the information gathered was time sensitive and related to the task at hand. The project schedule could also play a very useful role in passive data gathering. If a user's diary recorded they were working on a particular part of the building then any observations made by them at the time would more than likely be related to some aspect of that work.
He raised a number of issues related to my line of study and the potential outcomes of the research:
1. What are you trying to prove or demonstrate?
2. How will this change processes?
3. Where does Industry Foundation Classes and the Building Information Model concept sit in this picture?
4. How will this be tested and what will be tested? Obtrusiveness? Quantity of information? Quality of information?
5. What sort of numbers will you need to gauge a good response?
6. How will the relevance of any tests be proved in the real world?
7. What are people like Bentley and AutoDesk doing in this field?

I was not sure how to respond to many of those questions though I am pretty certain about a few.
I do not see Industry Foundation Classes or the Building Information Model playing much of a role in any of this higher level communication. For the most part I want to explore how RSS and the notion of intelligent blogging (blogging with a lot of passive meta-data attached) can effect the design and development process. In discussion between architects, builders and clients the applicability of complex, low-level data standards is almost zero. At this high-level text and basic images are about the lowest common denominator between the groups. When communicating this information I believe an abstracted IFC model just adds complications to what should be a simple process. Adam Bosworth (who works for Google) thinks the same way.

"As I said earlier, I remember listening many years ago to someone saying contemptuously that HTML would never succeed because it was so primitive. It succeeded, of course, precisely because it was so primitive. Today, I listen to the same people at the same companies say that XML over HTTP can never succeed because it is so primitive. Only with SOAP and SCHEMA and so on can it succeed. But the real magic in XML is that it is self-describing. The RDF guys never got this because they were looking for something that has never been delivered, namely universal truth." Adam Bosworth, ISCOC04

It has been a while since much movement has occurred with this PhD. Ironically during this time I have been doing a lot of movement physically. This is not to say I have not been doing a lot of reading and listening, but as far as moving the ball forward the opposition has been entrenched firmly in my 22 so to speak. So lets recap where I was, where I am and more importantly, where exactly am I going?

What is wrong with this picture?

Firstly lets touch on the style of this writing. Part of my hesitation (some may say procrastination) has been tied up in the thought of formalising things into an academic paper or something of equal banality. As the subject matter of the study deals closely with the deficit of recorded informal communication within the process of architecture, it just seemed a little weird to start off by formalising the concept in a rigid paper. That is not say there is not a place for formal coalition of these musings into a concise body of work, it is just that I feel this process needs to happen once the concepts are out there and the concrete has begun to harden.

Achieving meaningful digital communication in today's AEC environment

Introduction

The technology of the Internet has not impacted the tools and processes of the Architecture, Construction and Engineering (AEC) Industry as much as other industries or modern culture in general. In some respects this observation is unusual considering the architecture process is one of the complex communication. From a neural standpoint it would have been logical to assume Internet technologies would have been quickly adopted given their theoretical ability to enhance communication. However from a professional viewpoint inside the Industry it is not surprising AEC digital processes are still very isolated.