stressfree - concept

Old diagram recorded for posterity

David — Mon, 19 Dec 2005 10:43:51 +0000

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.

What makes this different to big-iron project management?

David — Mon, 12 Dec 2005 09:42:14 +0000

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.

Firstly all the products just mentioned require a significant degree of buy-in both in terms of financial outlay and training. All of the products are vast in their functionality and are primarily targeted at management of large, long-term construction projects where all participants (architects, contractors and engineers) have extensive and long-term relationships. These long-term relationships provide justification for the considerable learning curve involved in implementing the products. A few years ago I saw I demo of a piece of New Zealand developed design/construction management software for a large spec-housing company that satisfied the same economy of scale argument as these management tools. However there is a large untapped market of very short-term, small scale architectural projects that could benefit from online collaboration but cannot justify the costs of implementing a large management system. This is the target market for my research and ultimately this is the ideal Internet experience, allowing participants to converse directly with one and other unrestrained by the forces of centralised management. The Cluetrain Manifesto touches on this concept from an advertising and marketing perspective but it has also been termed 'talking to an audience of one'.

All the of the products use a centralised management approach requiring a dedicated server or hosted service which in turn have their own ongoing maintenance and support costs. The emphasis of my research is identifying a means of achieving distributed project knowledge sharing to remove the presence of a centralised server and re-utilise existing office resources such as their email and web-hosting services. Most if not all offices now have access to an email service and probably a web-host as well. Coupled with this is the wide variety of online mail services offered with huge storage capacities and very little cost (GMail, Runbox, Yahoo for example). Yet these centralized tools do not take advantage of these services, in fact most of these programs began development in the late 90's well before these services even existed. Buying into online collaboration should not involve buying into an expensive server or service, the most expensive purchase should be the bandwidth and even over time the price of this is going down (though there are some concerns related to how the Net will evolve in the future).

These document management products also emphasize the word management. To a certain extent all these products are aimed at top-tier managers with the end-users (builders, CAD monkeys and client) coming in a very distant second place. Even the reasons promoted for implementing these systems revolve around how useful these tools are for management to keep their employees up to date and keep a watch on how their projects are progressing. I personally think I am aiming for the 'Google Architect' of AEC document management arena; who's emphasis is on ease of use and flexibility for the end-user to both interact with and understand how their work fits in to the big picture.

Just like Google there should be zero buy-in and buy-out in the system for users. Google does not make end-users pay money to search or limit the search scope based on economic needs (though sometimes political demands have forced some changes). However most of the AEC project management products emphasize the creation of a brand silo that tightly integrates with and rewards the use of company supported products. Consequently migration between product silos is made very difficult as the document management meta-data is proprietary and stored within databases housed on the server or on the hosting provider. My work is looking to find a way of adding value to existing data (through the creation of meta-data enriched RSS feeds) whilst preserving the independence of the underlying information from a corporate silo. Through sticking to industry standard email (SMTP,POP3), web (HTML) and RSS technologies the mechanisms put in place would in no way lock users into to any particular brand.

Rather than championing the use of a central server my work is trying to distribute tasks and re-utilise the existing email and web hosting services already present within the infrastructure of an architecture practice. Through reusing these resources and the spare CPU cycles of increasingly powerful desktops the requirement for a dedicated and costly server should no longer be required unless in situations where it economically makes sense. This will significantly reduce buy-in and heighten adoption vertically throughout the industry from small two person practices right through to large organisations as decisions can be made without significant outlay of time or money. Plus following this strategy the emphasis would be on a bottom-up adoption model rather than a top-down strategy for implementation.

Most importantly the emphasis of this research is on creation of an AEC decision & conversation management tool, not simply a document management framework. Obviously CAD and image files play a crucial role in this conversation but email, schedules and eventually blogging are just as important. This is especially true as time passes and the personal relationships and decisions that helped form the design are forgotten or the people that were associated with development transfer project documentation off to others. Exactly how this conversation is (or isn't important) to the evalutation of the project is important and most probably the crux of my thesis. Determining whether or not the preservation or re-evaluation of project conversation can play a beneficial role is the end-game conclusion for the work. My hypothesis is that the advent of such a tool would greatly improve not only collaboration and understanding but also the long-term success of a project. Proving this hypothesis is what the testing phase is all about.

An old but still very interesting Cadalyst article I read recently touched on the importance of conversation and collaboration in the evolution of the Building Information Model. The article even suggested that the success of Industry Foundation Classes may hinge on the failure of proprietary silos and collaboration tools (what need is an open model if most of the value comes from a proprietary means of collaboration?). This is an interesting point of view and quite logical when the true value of collaboration and conversation is factored into the life-cycle costs of a project.

CAADRIA 2006 Abstract Accepted

David — Mon, 12 Dec 2005 08:27:57 +0000

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.

Conversation and collaboration play a crucial role within the Architecture, Engineering and Construction (AEC) industry. No matter the technology employed, without effective communication or understanding of design issues as conveyed by the client the chances of successfully meeting project objectives are severely handicapped (Barrett, Hudson and Stanley, 1996). Currently there is no simple, transparent way of documenting, reviewing and searching this conversation throughout the lifecycle of a project. Consequently information about design decisions and issues are lost as development responsibilities shift between groups who maintain different objectives within a project.

Although the AEC industry has proven slow to adopt new process enhancing technologies it has been very swift in accepting email as a means of communication (Swee-Lean and Nga Na, 2004). More complex collaboration technologies ranging from the Building Information Model to project Intranets have struggled to gain the same level of acceptance even though research by Arayici and Aouad (2004) and Al-Reshaid (1999) has shown many benefits in their respective adoption. A factor identified by Anumba (1998) for this slow adoption is the limited time and financial resources available within AEC organizations to retrain staff and change internal and external collaboration processes.

Project teams are usually brought together for a relatively short but intense period of time. Following project completion these unique teams are dissolved just as quickly and often are never formed again. As a consequence it is difficult to justify the investment in time and resources required to implement complex IT-based collaboration solutions. A further barrier to adoption is the differential application of IT skills across the AEC industry. Therefore in order for a new technology to gain broad acceptance and be most beneficial it must be applicable to the broadest audience with the minimum investment required from all parties.

Web 2.0 is the name given to a series of new technology concepts that are profoundly affecting the way users are experiencing the Internet (Hammersley, 2005). Web 2.0 technologies like Really Simple Syndication (RSS), ‘blogging’ and ‘tagging’ focus on the creation of social networks and place an emphasis on actively sharing data. A key reason these technologies are being adopted very quickly is because just like email they are simple to understand and implement (Bosworth, 2004). This paper proposes a distributed Web 2.0 technology framework that works with the email and Internet tools already available to store, track and search for design decisions and communication. Through the reutilization of existing tools a user familiarity is maintained and the cost of entry for participants in this conversation is significantly reduced.

The primary objective of this research is to preserve the rich design history of a project from conception to completion. Submitted information can be intelligently searched using the meta-data sourced from syndicated data feeds about team members, project timelines, work diaries and email communication. Once indexed users can tag documents and messages in order to provide a further, far richer layer of meta-data to assist in searching, identification of issues and semantic identification. This strategy of defining AEC semantics through social interaction differs greatly from that of more complex, computer interpretable solutions such as Industry Foundation Classes (Wix and Liebich, 2001). Rather than abstracting information to suit a generic yet highly intelligent building model, the emphasis is on preserving the participant’s own thoughts and conversation about decisions and issues in order to create a forum for intelligent conversation as the design evolves.

References

Al-Reshaid K., Kartam, N.: 1999, Improving Construction Communication: The Impact of the On-Line Technology, W78: Information Technology in Construction, Vancouver, Canada.
Anumba, C.J.: 1998, Industry Uptake of Construction Innovations – Key Elements of a Proactive Strategy, W78: The Life-Cycle of Construction IT Innovations, Stockholm, Sweden.
Arayici Y., Aouad G.: 2004, Requirements Engineering Process in the CIC Development: The Divercity Project Case Study, proceedings from the 1st International SCRI Symposium, Salford, United Kingdom. Pp 169-181.
Barrett, P.S., Hudson, J., Stanley, C.: Is Briefing Innovation? Proceedings of CIB W65 Symposium. Glasgow, United Kingdom.
Bosworth, A.: 2004, transcript of presentation, International Conference on Service Oriented Computing, New York, USA. http://www.adambosworth.net/archives/000031.html
Hammersley, B.: 2005, Developing Feeds with RSS and Atom, O’Reilly Media, California, USA. Pp 5.
Swee-Lean, C., Nga-Na, L.: 2004, State-of-the-Art Internet Technology in Singapore’s Construction Industry: The Impact of the On-Line Technology, CIB: Construction IT Bridging the Distance, Auckland, New Zealand. Pp 378-386.
Wix J. & Liebich T.: 2001. Industry Foundation Classes Ifc 2x,
http://www.iai-international.org/Model/documentation/IFC_2x_Technical_Guide.pdf

Reviewer Comments

Good idea seemingly well thought out. Broadly applicable. What it needs, however, is an example or case study - not as the end or goal of the paper - but as an illustration of the efficacy of the process(es) described.

This is well presented perspective about limitations on the technology for collaborative work. It justifies the authors' efforts, although the abstract isn't entirely clear about the essential advantages of the authors approach nor does it provide any metrics to evaluate their findings. Will they really overcome the inherent in-practice limitations to such collaborative systems reducing time and cost and providing greater ease for handling the complex management of information? Have past models failed to grasp the nature of the communications needed? Can some abstract meta-data model capture this effectively? Hasn't this been the objective of such efforts to date? Perhaps these are issues to be more fully addressed in a final revision of the paper, the premise of which looks quite reasonable.

The research correctly identifies limited time and financial resources in hampering the acquistion of process enhancing technologies. It makes sense to use Web 2 technologies in this context, however, many of the examples cited in paragraph four of the abstract are quite generic. It will help if this presentation is illustrated with a technology demonstrator or nomenclatures showing the specific ways in which Web 2 technologies can be used by AEC industry.

Application Diagrams

David — Sun, 13 Nov 2005 22:26:02 +0000

Click to enlarge

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:

Getter Application

The Getter retrieves messages from a number of identified email accounts, web services and file servers and consolidates the information to at a single location with separate RSS feeds for the various information sources. The Getter could be acting for a single project or setup to serve a practice with numerous projects 'on the go' at one time. The principle behind the Getter is that storage and bandwidth are relatively cheap compared to the time required to dynamically harvest resources from around the web. Deployment wise the Getter could be setup to operate on each PC (in order to create local versions of the data-store) or centrally at a single location in order to create a single location where all project data is stored.

Receiver/Indexer Application

The Receiver monitors the file repositories created by the various Getters for each organisation (or person/group within). The Receiver reads the RSS feeds generated by the Getter and on submission of new information the Receiver pulls down the corresponding files and meta data for parsing and submission into the search index by the Index. The creation of the concise search index is required in order to quickly perform rich, sophisticated searches of the project data. The Indexer would create its index using the meta data supplied by the RSS feeds coupled with a full-text index of the submitted file attachments, work-logs and emails.

RSS Search Engine

The RSS enabled Search Engine would interface the search index created by the Receiver/Indexer and provide RSS feeds to any search queries submitted. The use of RSS style search feeds would enable the creation of sophisticated, time sensitive searches by a multitude of clients (from web-based tools to plugins and desktop helper applications). The search results would provide hyperlinks to the information stored in the central repository created by the Getter application. In this sense the original content can be transient but still be referenced over long periods of time. In most deployment situations the three applications would be deployed on a single office server but they could also be deployed on a laptop or spread across three hosted servers located anywhere on the Internet.

Advanced search (Click to enlarge)	Search results (Click to enlarge)
Conversational view (Click to enlarge)	Expanding view (Click to enlarge)
Schedule view (Click to enlarge)	View of related resources (Click to enlarge)

Example User Interface

The focus of this example user interface is to retain a lot of the familiarity of contemporary search engines whilst emphasizing the chronological and conversational nature of architectural design evolution. In the given example as the designer submits daily work-log entries (along with file attachments of their working drawings) and discusses design changes via email a time sensitive model is created that allows the user to browse through the evolution of the project. The user is free to expand out different conversational threads or switch the search view into a gantt chart style view where email and work-logs are tracked against project schedules. As working files are submitted to the system as work-logs are created the user can browse and download a versioned history of files in order to examine the state of design during a particular phase of the project.

Versioning and practice-use requirements

David — Thu, 10 Nov 2005 23:18:37 +0000

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.

Two common programming versioning systems are CVS and Subversion. I use Subversion on a daily basis with Eclipse (my Java IDE). The process of using a versioning system involves 'committing' code changes to the repository and at defined times (like a software release) creating 'braches' from the main development 'tree'. The versioning system does not keep multiple copies of files it simply tracks the changes to each file and dynamically builds files by adding together all the code changes. Such a system extremely useful, especially when working in groups as different pieces can be worked on simultaneously and then combined. Probably the most important aspect of the entire process is the unobtrusive nature of the versioning process from a developer's perspective. Committing a change is as simple as a right mouse button click yet the consequences are sophisticated and extremely useful.

(Click to enlarge)
Committing a change to Subversion using Eclipse. It is as easy as right click -> Team -> Commit

(Click to enlarge)
Then enter a brief description of what has changed. Browsing to subversion.stress-free.co.nz provides everyone with a look at what has changed.

From an architect's perspective versioning is a little different as the idea is more conceptual in practice and hardly ever grounds itself in a concise piece of 'code' (a single drawing/sketch). Some CAD packages do versioning based on parametric conditions or the notion of time, but as far as versioning across an entire project, manual methods are still the main form of versioning. Online project Intranets are trying to address this issue but because of the buy-in and major working changes required to use a project intranet these services have not gained major acceptance.

For the most part the practical realities of creating a true 'versioned' design model are beyond the reach of all but a few of the most anally retentive architects. In most offices I have been associated with digital versioning typically consists of creating a new file when a major change is about to take place or going back to a backup if a change occurs that cannot be easily 'undone' using the software.

So in my proposed system one of the designers asks the question, 'when was the door moved from A to B and why?' how will this search, and the information related to it, be displayed?
This question is essential to answer but difficult to solve and poses a conceptual versioning dilemma. In in the context of a design project a whole series of design moves could be made in a single 'version' of the design. Two CAD models produced at different times may provide evidence of the elemental shift but it probably would not narrow down the date of when this change occurred or more importantly why. To identify the when and why you would first need to know who made the decision to move the door, what discussions led to this decision and when in the design development stage was this decision implemented and whether subsequent design moves influenced this shift.
When searching for these answers you would probably be asking the following questions and receiving these hypothetical responses:

1. What is the design history of this door?

Whilst not specific you generally begin a broad search and then narrow it down from there. More often than not when using any search engine (be it Google or your local file search tool) your initial search attempt is a test of the water rather than a precisely focused search statement. In the case of the door it is problematic to search within CAD models themselves as doors are typically only represented by a series of lines. In a Building Information Model it could be possible to search within the document to find a specific door instance but achieving this in todays mixed AutoCAD/Revit/ArchiCAD/Microstation environment would be problematic and probably lead to inconsistent results.
So as far as searching for the door's history we would be limited to meta-data tags and written documentation (in the form of notes, briefing documents, etc).

Another avenue for locating information could follow the use of project plans and work diaries. Given enough chronological information about the project as far as when things were done by whom it could be possible to extend the usefulness of any search by identifying useful pieces of information. This brings to question exactly how often data should be entered into the system. Just like in computer software versioning the system is only as good as the data it receives. If you fail to frequently commit your changes to the versioning system your chronological view of the model will be very weak. Hence the versioning process in this system would need to take place as frequently as possible (whenever information is exchanged, important decisions are met or at the close of the business day).

2. When did the move from A to B take place?

If the general search for the history of the door door in question returns a large number of results (from material options to recorded notes on design options sent to the client by the architect) the next phase in the search would be the isolation of when the actual move took place. The most efficient manner to do this would be a narrowing of the search based on the tag 'design decision' (or equivalent as setup within the project). This tag would be applied to any correspondence or work logs submitted that related to instances where specific design decisions were made. The highlighted results viewed against a project timeline would highlight when design decisions related to doors occurred. It would be at this point when the user would use their own intuition based on their personal insights and knowledge of the project to zoom in on a specific time zone within the project where it was thought the door was probably moved (based on the displayed information).
This move is very similar to how we interact with current search engines of all kinds. The greatest difference is that we view and evaluate these results against the chronological project canvas.

3. Who moved the door?

Now that we have narrowed down the time frame as to when the door was moved it is important to understand who were the parties involved in the decision making process. Was this an action performed individually for no reason or did it occur against the backdrop of a number of different but inter-related issues that are important to keep in mind?

4. Why was the door moved?

Understanding this question will require extracting a subset of the conversations and logs placed by the person responsible for moving the door. By examining their activity before and after the activity we would soon identify whether this was a requested planned action, a spur of the moment decision or an action brought on by a chain of events unassociated to the door itself. Situations like this often occur when a design change results in the repositioning of a spacial element which in turn forces the door move (through no fault of its own).

5. Subsequent to this discussion, what other (if any) influences effected the placement of the door?

This investigation of the moving of the door may reveal discussion threads indirectly associated with the door's repositioning. In order to identify this a broad cross section of the conversation would need to be extracted and browsed based on the time frame, participants and project tags associated to the repositioning of the door element.

What would make users buy into this increased data entry requirement?

I believe architects would be willing to invest their time in such an endevour if it was proven that it satisfied a number of their ongoing concerns about working digitally. By itself the system would be useful but the added burden would stunt, if not destroy any chance of widespread adoption. There are a number of small areas where architecture practitioners must pay particular attention to that large software vendors do not properly address. From my experience acting as a consultant in this environment these 'gaps' can be broken into four different groups:
a.) Taking care of the data backup process
b.) Time tracking based on task/project particulars for a specific person
c.) Finding things they or others have worked on in the past
d.) Enable simple sharing between people in their team and other parties

These issues are presently tackled in a number of ways and usually involve customised manual processes that have evolved within each particular office. For example:

a.) Taking care of the data backup process

All companies are deeply concerned about loosing their data. There is the time cost involved in loosing past work but also the prestige and moral hit that takes place when hours of blood sweat and tears suddenly disappear. This is especially important when other parties depend on the data you are providing to undertake work. Just recently I had an experience where an architecture practice lost a few files and they could not be recovered. The flow on effects for this loss where huge. A team of builders could not work, other projects were delayed and office moral took a dive as hundreds of hours of work had to be redone under stressful circumstances.

Probably the most surprising thing however is that architects still do not value their data enough (until it is lost). For many the idea of creating frequent, multiple offsite backups of their work is just too much effort when a single, weekly backup protects them on a week by week basis. If a system like the one proposed were to exist then backups of critical data would occur automatically as changes were logged or information exchanged between groups. Not only this but as more parties joined the project the backup integrity would increase as multiple copies of the same file propagated itself through the network.

b.) Time tracking based on task/project particulars for a specific person

Tracking what time was spent on which tasks by who is crucial for architecture practices. Not only is it required for paying employees but also tracking chargeable hours and assisting in the quoting of new jobs. There are numerous applications available for time tracking, especially for the legal arena but none have been universally adopted by architects (in fact in this field a simple Excel spreadsheet is a popular option). If the system logged time spent on projects as users committed work to the project this information would be silently recorded by the system for later analysis. Not only would it provide immediate benefits in staff and charge out tracking but over the long-term it would provide a resource for comparing past projects to future estimates.

c.) Finding things others have worked on in the past

Information reuse within any office is typically very low. Due to the sheer quantity of information present within a single project it is often easier to reinvent a solution rather than track down past work on a crowded disk archive. As more materials and accepted solutions libraries are put in digital format the architects physical reference library is shrinking yet their capacity to easily find digital information available to them still depends almost entirely on an up to date and comprehensible digital filing system. Desktop search tools like Spotlight and Beagle acknowledge this problem and are attempting to provide general search functionality to desktops around the world. Unfortunately the functionality provided by any of these general search engines fall well below that required in an architecture specific context as no matter how evolved these tools become they will never understand AEC semantics.

If the tool provided this ability to easily search a project or projects information base for a set of constraints old solutions could potentially be rediscovered and utilized on current problems.

d.) Enable simple sharing between people in their team and other parties

Although file sharing has been around since the beginning of computers it is still difficult. Presently project files are exchanged either physically (on CD/USB) or using the Internet (via email). Within an office often the option exists to share files live via the local network but this is problematic in small offices due to the lack of IT knowledge available and various intricacies that still exist in the process itself.

Exchanging files using email or physical means results in a 'frozen' version of the file that does not keep pace with changes made by either party. In this scenario we do not want others to have direct ability to change our files (or even see our in-process version). What we do need to be able easily do is easily notify users of a particular file that it is now considered out of date and for what reasons.

Consider the following example, I email a development drawing to a quantity surveyor and building services engineer for estimation and simulation. The quantity surveyor's feedback results in the design undergoing a series of changes. Once these design changes are finalized a simple mechanism is required to notify the quantity surveyor, building scientist and any other related parties of the design change otherwise there is the potential (as so often happens) that third party work will be completed using outdated data. In computer programming such a concept is known as a 'thread-safe architecture'. Basically it boils down to establishing a common communication layer between all actions so that everyone is always on the same page.

Part of the file sharing process also requires a communication of assumptions, standards and conventions associated with a file. When emailing data, especially to people outside your work group these factors play a crucial role in not only determining what the data is but also play a role in the eventual outputs from this third party. In a conventional AutoCAD file the semantics behind CAD layers and XREF management are vital to understand but more importantly in an estimation or simulation context other users must be aware of assumptions, shortcuts and operating logic associated to the working data. In these scenarios the raw data (an Excel sheet, 3D walkthrough or still image) is only the first clue to the puzzle, understanding the logic behind this data and how it fits into the bigger picture is very (if not more) important.

So what need is this research fulfilling?

David — Tue, 25 Oct 2005 02:51:10 +0000

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.

Thinking things through

David — Tue, 13 Sep 2005 04:05:46 +0000

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

With this research I want to investigate how a distributed data approach (via RSS) can be applied in the area of design/development. From my perspective if I can get a system that pulls project data from a number of different sources I will be very happy. This would be a significantly different approach to traditional client/server solutions that would allow easy 'buy in' and 'opt out' for project participants. If the concept is to succeed building practitioners must be able to use the system within their existing infrastructure else it will fall prey to the same handicaps faced by project intranets. With this in mind the technologies applied must be simple, uniform and potentially applied within a number of different applications (not just tied to a web browser client).

Getting back on the Bike

David — Sun, 28 Aug 2005 11:24:18 +0000

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.

Secondly I would like to see how this works online with comments rather than working on paper and pen. I am still going to print these things out and pin them up where you see them but this should be seen more as a post-it reminder than the 'informal' submission. The reasons for this goes back to the concept as it seems rather two-faced to propose informal digital collaboration and then flesh it out using printed documents and discussions held behind closed doors. I should also make things easier for me to do numerous blocks of discussion rather than commit (and potentially loose) too much time to a single endeavor.

On the subject informal conversation to give a background of what I keep track of here's a link to my current RSS subscriptions in OPML format. Most RSS aggregators import OPML, on Windows I would recommend RSSReader (http://www.rssreader.com/) whilst on OSX there's my favourite NetnewsWire (http://ranchero.com/netnewswire/). At the very least you should probably checkout Doc Searls' site (http://doc.weblogs.com/) and the Technorati blog search engine (http://www.technorati.com/). The mechanics behind Technorati are pretty amazing when you consider how up to date the content is and how active many of the conversations are.

Why am I here?

This is a pretty important question and one for a while I did not know how to answer. It was a bit like waking up one morning on a cruise ship with an all you can eat buffet and a destination many years away. Whilst limited by the constraints of the ship I have had the opportunity to take some risks and do some pretty cool things. Not many people have the financial freedom to dip their feet in the water of running their own business knowing that if things turn bad they can always retreat back to their PhD. Over the last two years since I learnt I had the scholarship I have been contracted by a number of different organisations both within and outside the confines of the architecture community. These mixed experiences have helped to clarify a number of issues related to the why dilemma.

Firstly I like the challenges of digital communication forcing people to work closer together. Before the Internet there was a lot of barriers (both physical and otherwise) between people that we as a culture had built up to protect and serve us. Media was controlled by a select few, the list of people you could talk to was limited by your phonebook and to solve a problem the first place you'd go would be the bookshelf. In this new arena I enjoy hearing what Doc Searls has to say. He and his compatriots put forward a lot of ideas about contemporary Internet business in the Cluetrain Manifesto that I agree with. There is still the question of how these concepts sit in the AEC arena, sure email has replaced the letter and to a limited extent the fax, but is there a discernible change in the way the process of architecture is conducted in the digital realm?

The Internet is the new frontier and this gets me excited. It seems like every month there is a new craze or 'next big thing', Google's stock price keeps going up and my RSS aggregator (an application genre that did not exist a few years ago) gets filled with new articles in just a matter of hours. The fact that most of these crazes flop, Google's business plan is shaky and the majority of news articles are chaff does not bother me in the slightest; I am attracted to the energy that emanates from this industry in a manner that hasn't occurred in the AEC sector since Le Corbusier thought white walls and reinforced concrete might make it big with the rich folk.

It is great when simple, loosely joined things work together to solve complex problems. Too often in any endeavor, but especially in the IT arena, complex solutions are offered to solve difficult problems. Most of these solutions work out okay but the truly great solutions are the ones that are so simple (almost) anyone can understand. The Web is the perfect example of this, but I think Tim Berners-Lee hit on it through luck rather than astute reasoning (more on that later).

In the real world I had an example occur to me this week. A year ago I helped put a Netware server in for a local architecture practice. The decision was based on the fact the administrator of the server was proficient in Netware and it is a robust system used in really large organisations. Providing a system that met the requirements of the practice turned out to be very difficult. Netware is a very complex system with a lot of moving parts on the server and client. It means in large scale situations administrators have a lot of control, and control in a large organisation is a very important thing. In this situation lots of moving parts meant lots of problems and eventually on Wednesday the whole system crashed. Fortunately like a volcano getting ready to erupt it had sent enough danger signs out the previous week that the data was backed up and the users were prepared for the worst. Unfortunately it meant I lost a good many days picking up the pieces.

Someone once said the sign of a stupid person is someone who repeats their past mistakes. I did not want to fall for this trap as the smell of a lawsuit is not particularly nice. Netware was out and along with it all its complexities. What is now in place is so simple its almost beautiful and everything is modular so that one failure cannot bring down the entire network. Even better the simple solution is understood by the users which even at this early stage has helped instill a lot more faith than the past system ever had.

What is the moral of this story? Small, low-resource architecture practices throw up just as many problems as large organisations (they just look different and you have less time to solve them). Consequently if you are going to propose something for this environment it has to be simple, it has to work right off the bat and users need to understand the processes behind it so that they can trust what is going on.

Right then, so what's your problem?

I am disgruntled and yet at the same time drawn in by the disjointed nature of the architecture process. I find it fascinating how so many people from different backgrounds can pull themselves together to work on a project and then within an instant disband and go and form other project groups elsewhere (or at the same time). You would think the communications channels for this would be extremely complex and technologically sophisticated but in most cases they are not. What does annoy me is the thought of all the knowledge that evaporates during this project as requirements are communicated, concepts proposed, decisions documented, the structure built and finally inhabited by users completely foreign to the whole process. But in saying this it is not just a case of subscribing to the notion that if every single piece of information was recorded throughout the building life-cycle then everyone would be better off. I think that was a nice concept in during the 1990's when the Internet was just coming to the fore and the idea that any piece of data could be 'managed' was all the rage (Refer: 'The Nonsense of Knowledge Management'). In the real world we were soon overcome by too much data and not enough usable knowledge as Google demonstrates to us daily (a search for 'New Zealand timber frame wall' tonight produced 112,000 results).

It was in this environment that Tim Berners-Lee published his second concept of the Semantic Web (http://www.xml.com/pub/a/2000/12/xml2000/timbl.html). This is where I think he demonstrated his 'fathering' of the contemporary Web was more by accident than purpose. The Semantic Web demonstrates none of the underlying simplicity of the current Web; it is reliant on complex protocols, super intelligent 'bots' and a world where everyone is in agreement and trusts each other. In this environment HTML evolved into XML and was to form the common glue that would bind the new Web. XML in many respects is a step backwards from HTML, and whilst grammar is formalised the document itself contains less semantics than its predecessor.

I have to go to bed now, I have been working on things since 5:00am and its now 11:30pm. There is a few things I need to see to in the morning but by lunch I should be back writing. Rather than adding onto this posting I will start a new entry going further into what I would like to produce (a.k.a 'my cool thing').

Hyperlinked Practice

David — Sun, 06 Feb 2005 04:05:43 +0000

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.

Construction is a very demanding process that relies heavily on strong leadership and communication within a project team to achieve the desired result. Consequently from the beginning of human history complex organisational structures have been employed to formalise and manage these processes to attain a successful result. At the opposite end of human development the Internet is effecting profound change on many aspects of modern life through its decentralising ability to supplant formal, top-down media with personal, hyperlinked conversation. Business processes are being changed as management comes to the realisation that their workers actually understand what they are doing and need to be listened to. "While managers had gotten really good at bossing people around, they didn't know much about how things actually got made. This naturally resulted in many high-level executive-type conferences about 'The Knowledge Deficit'." (p162, The Cluetrain Manifesto) Almost overnight the field of 'knowledge management' was created for the new breed of intelligent 'knowledge worker'.

However whilst other industries have begun to embrace this distributed environment it is with some irony that the emphasis of current AEC technology lies in consolidation around a single Building Information Model (BIM). There are some very strong reasons for using a centralised model that revolve around control and change management. However BIM works against the hyperlinked principles of the Internet, stifling informal communication and fire-walling direct communication between workers. In order to benefit from the Internet an interface is required to BIM to enable Web-based navigation and hyperlinking of the model and its meta-data to other sources. Unlike the broad semantic models of BIM the hyperlinked practice would promote participant conversation through different personal and formal sources. Rather than interjecting completely new technology the success of the hyperlinked practice would hinge on the reutilisation of existing, proven Web and AEC methodology. Consequently richer project information repositories would be enabled as search tools could be applied within project teams as easily as they are deployed on the Web. The hyperlinked practice would acknowledge the complexities of the unified information model and instead focus on maintaining a common point of reference between different data sources. Instead of seeking unification through elimination the hyperlinked practice assumes data will be always be distributed across a number of formats and will work to promote understanding through open conversation.

A Future Scenario

Exactly how the hyperlinked practice would effect the industry is uncertain. It is envisioned through the following fictional story that the tightly controlled, adversarial nature exhibited by present day Industry professionals could be positively influenced by better comprehension of wider project issues and less formal communication channels.

Kelly stared at her list of tasks for the day and did not like what she saw. The architectural graduate was working under John, one of the Practice's directors on a large office development. The project was running behind schedule mainly because halfway through construction the Client had changed the brief requirements for the top floor when they realised the other floors would more than satisfy their initial needs.

For a week Kelly and John had been making design alterations. Before and after an element was modified in the Building Information Model the computer would bring up a list of important considerations drawn together from the workblogs and supporting documents of the project team. Kelly did not understand exactly how it worked she knew that by selecting a part of the model a search tool would go out and find relevant issues based on hyperlinks to and from that part of the building in CAD files and documents. Just like Google the more times something was linked to the more important it probably was. Kelly was surprised that the modification of a single wall could draw such sharp criticism from the contractor or invalidate so many design requirements identified in a concept design process she was never a part of. She wondered why the Client wanted to go to such trouble but John reassured her that nothing was ever easy in construction, but at least now the hyperlinked conversation helped identify issues quickly rather than waiting weeks for project meetings or a little longer for law suits.

Late in the afternoon just as the design modifications were nearing completion Frank the building scientist commented on his workblog that the functional change would break a key Government energy guideline. Frank previously had not been involved in discussions as his analysis work had been completed before construction began. Fortunately for the project team Frank kept his feed reader monitoring project developments for instances just like this one. In his post Frank hinted at how this guideline could be met but concluded by saying some further simulation would be required. John wryly smiled at Frank's post, the young scientist had a knack for picking up extra work by keeping an eye on project developments. He posted a reply to Frank's workblog that requested further simulation of the area be completed as soon as possible.

The next morning John and Kelly arrived at the office to find a summary of Frank's findings marked important in their news readers. The north windows were too large given the size of the HVAC system and the cooling load of the new functional requirements. John checked the construction news feed. The steel structure had been put in place a week ago without issue but fortunately the glazing had been delayed due to scheduling difficulties. He was about to ring the site when a follow up comment from the Foreman to Frank's post informed everyone that the construction team had been moved to the east facade until this issue had been discussed with the Architect. John quickly replied that he agreed with the Foreman's decision and he would be in contact as soon as possible with a revision.

While John was at a meeting with the other directors, Kelly opened her Building Model to checkout the problem area for herself. Some podcasts recording early client discussions about the northern facade had been hyperlinked to the model. In the recordings the client made some very clear aesthetic demands that contradicted the requirements set by the Building Scientist. Kelly made an entry in her workblog noting the contradiction between the briefing requirement for large north windows and Frank's report giving reasons for smaller windows. She rang the Client to inform them of the problem and arrange a meeting time for John later in the day. She recommended the client checkout the discussion between the various team members so that when John met with them later in the day they had a clear understanding of the issues.

In the afternoon John travelled to the Client's office to discuss alternatives. In the time between the problem being brought to their attention and the meeting with the Architect the Client had browsed the discussion thread and had thought through some acceptable compromises to bring to the meeting with the Architect. During the meeting the John made some quick notes and sketches on his tablet computer of the agreed upon design solution. In the taxi on the way to another meeting he uploaded the document to his workblog, referencing it to Kelly's previous workblog entry and the CAD file that would need modifying. He sent a text message to Kelly to inform her of what he had done and to move forward with documentation of the proposed solution.

Kelly modified the CAD file as the Director had requested and published the changes to the project registry. She then published her modifications and emailed the building scientist, notifying him of the change with reference to John's notes and sketches. The Building Scientist searched the project registry for the modified windows in Kelly's CAD file based on the hyperlink she gave him. A quick look at the layer's properties which the windows were now a lot smaller and slightly higher. He modified the simulation file and reran the simulation. Initially the simulation did not meet code but Frank found a slight increase in wall insulation levels would just allow the building to pass. Late in the afternoon Frank posted the successful simulation results along with his suggested increase in wall insulation to his workblog. In the blog he placed a hyperlink to the to Kelly's CAD file modifications and linked to the wall area that needed extra insulation. Just to ensure everyone understood the problem he placed a final link to his initial post pinpointing the code issue.

The Director returned to the office and checked Kelly's documentation against the building scientist's simulation findings. By this time the contractor had seen the unofficial design modifications on his news reader and had posted his unofficial approval of the proposal. Safe in the knowledge that the Contractor and Building Scientist were in agreement the Architect emailed the Client to get their approval for the change request before going home for the evening.