stressfree - building information model

Harvard Critical Digital Conference 2008 paper

David — Sun, 11 May 2008 10:08:06 +0000

In April I presented a paper at the GSD Critical Digital Conference at Harvard University. The paper was co-authored by my supervisor Mike Donn. The conference itself was pretty good considering it was the first time it had been run. You can find my paper along with all the others online at the Critical Digital website. However for posterity (and Google) I have included the text of my paper below.

Using Project Information Clouds to Preserve Design Stories within the Digital Architecture Workplace

Abstract

During the development of an architectural design a series of design stories form. These stories chronicle the collective decision making process of the diverse project team. Current digital design processes often fail to record these design stories because of the emphasis placed on the concise and accurate generation of the virtual model. This focus on an all-encompassing digital model is detrimental to design stories because it limits participation, consolidates information flow and risks editorialisation of design discussion. Project Information Clouds are proposed as a digital space for design team participants to link, categorise and repurpose existing digital information into comprehensible design stories in support of the digital building model. Instead of a discrete tool, the Project Information Cloud is a set of principles derived from a proven distributed information network, the World Wide Web. The seven guiding principles of the Project Information Cloud are simplicity, modular design, decentralisation, ubiquity, information awareness, evolutionary semantics and context sensitivity. These principles when applied to the development of existing and new digital design tools are intended to improve information exchange and participation within the distributed project team.

1. Preserving design stories within Project Information Clouds

Design stories form within architectural projects through the interweaving of design conversation, decisions and outcomes. These design stories are valuable in determining a project's current state and they increase the accessibility of information within the design team. Unfortunately, current digital architectural design tools emphasise production and communication of outcomes ahead of the preservation of conversations and decisions. To resolve this shortcoming the concept of Project Information Clouds is proposed as a means of digitally recording and maintaining these design stories. The Project Information Cloud is not a discrete entity but a set of principles. These principles when applied to the development of existing and new digital design tools are intended to improve information exchange and participation within the distributed project team. The principles that comprise the Project Information Cloud are derived from concepts similar to those that fostered the World Wide Web.

Although the architecture, engineering and construction (AEC) industry was slow to adopt digital design processes it is now undergoing rapid digital evolution. This digital migration was both a response to and an enabler of increased information processing demands. Hampering the recording of design stories during this evolution was the disconnect between the tools used to communicate and record design outcomes. Whilst digital communication through email and the Web have significantly improved the quantity of project communication¹, this data often fails to be directly or indirectly associated to the digital design outcome in any structured way. Likewise whilst digital tools used to model architecture can record design outcomes in exacting detail, they do so in a closed, virtual environment devoid of real context. Not only does this closed environment restrict participation, it also limits the ability of those interacting with the model to comprehend design decisions. Subsequently, whilst the AEC industry currently has powerful tools for communicating vast amounts of data and recording virtual outcomes in exacting detail, it lacks a digital vocabulary for weaving these two distinct information streams into coherent and maintainable design stories.

2. Deriving value from digital architecture's design stories

Architecture is as much about personalities and decisions as it is about the eventual built form². A project has multiple design story threads, each one is a subset of the personalities, decisions and outcomes contained in the overall design. The understanding of these design stories is instrumental in enabling a project team to collaborate effectively during the course of the design and construction process. Whilst of limited value at the moment of project conception, these stories appreciate over the building’s life-cycle to fulfill the role of decision making aids and historical learning resources. Traditionally design stories were established through direct participation and narrated to others should the need arise. Digital design is eroding these bonds through its ability to break down geographic constraints and consolidate project information around tightly controlled, data-rich models. This has led to more distributed and efficient design processes. However, it has reduced the ability for all design participants to comprehend and in some cases take part in ongoing design stories. Ironically in an effort to improve efficiency and distribution, digital design tools may in fact be degrading the underlying strength of the design process.

The project team must be able to digitally establish, reinforce and derive value from design stories. Therefore, they must be able to participate in the linking, categorisation and repurposing of all project information, whether it be complex virtual model, conventional plan or digital message. In order for this to take place there needs to be a shift in the way design participants treat their digital archives. Digital design artifacts cannot continue to be isolated and shielded from other project data. Instead these data points and their associated meta-data should be considered as part of a larger network, which when viewed as a whole forms a Project Information Cloud. There are two challenges to overcome if discrete project data is to be treated as part of this larger meta-network. The first is the organisational and legal constraints which accompany any professional exchange of data. Whilst a Project Information Cloud will need to respect the ownership and privacy requirements of existing data, the contributed meta-data used in the establishment of design stories should be considered property of the collective project team. Communal ownership is an essential element of this meta-layer because it will ensure all parties are free to copy, preserve and build upon existing digital stories in perpetuity. The second and perhaps more difficult challenge is to overcome the dominant trend within digital architecture to record all design outcomes within a single, complex and highly regulated digital building model.

3. Why digital building models compromise design stories

To efficiently manage the increased amounts of project information, the current trend in digital architecture is to build increasingly complex and information-dense virtual models. The premise of this trend is that the more comprehensively and accurately a virtual outcome can be modeled, the more efficiently the project team will be able to manage the information and processes associated with it. This objective has seen the traditional notion of Computer Aided Architectural Design (CAAD) evolve into the concept of the Building Information Model³ (BIM). Unlike CAAD, which at its core is a digital extension of the drafting table⁴, BIM accurately records the analytical and semantic characteristics of an architectural design within a highly structured, semi-intelligent digital model. BIM is not a fundamentally new idea and draws much of its technical inspiration from Product Model technologies proven within the aerospace, shipbuilding and manufacturing industries. This combination of CAAD and Product Model results in an architectural information modeling tool capable of utilising semantic data structures to create efficient and versatile working environments⁵. However to attain these benefits the design team must consolidate all significant architectural information around a single, highly structured BIM. Regrettably, by establishing this concise and complex point of truth, the ability of all participants to accurately record and comprehend design stories is diminished.

3.1 Complexity reduces participation

Participation is important to design stories because architecture is the physical representation of a collective decision making process⁶. BIM imposes process and knowledge barriers to participation due to its dependence on a single, complex data structure. In an effort to ensure the digital building model's integrity, the authority to manipulate the data is restricted. Even when permission is granted participants must understand and be capable of using the complicated software interfaces which govern the building model⁷. This participation bottleneck means the project team generally relies on selected participants to funnel relevant design data and decisions into the BIM. Owing to their status in the project team and close association with the digital building model, the role of digital shepherd generally falls to the architect. The architect undoubtedly is appreciative of this fact as it reinforces their place as the project's information and decision making hub. Unfortunately, those who take on this role can consciously or subconsciously filter out information vital in the recording and comprehension of design stories.

3.2 Rigid centralisation leads to editorialisation

Compounding BIM’s participation bottleneck is its rigid and often proprietary data structure. This limits the type and quantity of information capable of being stored within the digital building model. Whilst this enables consistency and efficiency it often requires third-party information to be editorialised and associated with a foreign semantic system before it can be included within the project BIM. This manipulation can potentially lead to degradation of the design stories through editorialisation and confusion. Vendors of BIM are aware of these data storage limitations and are continually extending the semantic structures within their products⁸. However this semantic extension occurs at the risk of increased complexity and also with the knowledge that no rigid structure can handle all potential data or semantic needs during the telling of design stories.

3.3 Virtual accuracy confuses practical reality

Accuracy within an architectural project is crucial but it is equally important to know where inaccuracies and tolerances lie. Architecture ultimately manifests itself in the physical environment and it is important for the project team to understand where, how and why the physical form deviates from its virtual blueprint. Traditional design representation depicted an abstract and partial description of the intended built form. In contrast BIM's capacity to depict a highly accurate, yet ultimately idealised, virtual truth risks impeding the ability of design participants to comprehend or accept the discrepancies between the virtual and physical realms. This is an issue that becomes pronounced as rapid design changes and construction inconsistencies are introduced into the process. If those administering the BIM cannot keep pace with these changes then information will be lost, incorrect decisions made and the design stories will suffer.

It is possible that eventually BIM implementations will evolve to account for the issues raised in this discussion. However, it is highly unlikely that within the foreseeable future a single digital building model will efficiently or accurately capture a project's design stories. Therefore, to ensure accurate recording of the design stories, the Project Information Cloud must exist as a distinct yet supporting element to BIM.

4. Learning from the Web to create the Project Information Cloud

Attempting to accurately record design stories using BIM highlights the inherent problem of using a centralised, highly structured data model to capture decentralised, unstructured decision making. A better means of capturing such data is to establish a distributed Project Information Cloud where all participants can contribute equally. Fortunately, many of the underlying principles and technologies necessary to create such a space exist already within the World Wide Web. The Web is the most successful distributed digital information network currently in existence. This success stems from its ability for anyone to create and link to other relatively unstructured data in meaningful ways.

The AEC industry has not ignored the Web but it is yet to embrace its full potential within the architectural design process. As with every industry, the availability of the Web and email has revolutionised the speed and distance across which project teams can communicate and exchange data. However, the actual processes of the industry itself have yet to be considerably influenced by the Web's principles or technologies. Project intranets have been adopted in a limited fashion within the AEC industry. However, these have primarily acted as digital extensions of traditional filing cabinets rather than as new methodology for collaborative design⁹. Whilst these tools can be valuable management and auditing aids, their centralised nature and the fact they are controlled by one group of design participants generally relegates their role to digital document manager for a specific project team or organisation. If implementations of the Project Information Cloud are to be based on similar technologies then they must overcome these shortcomings. This can be achieved by adhering to a common set of principles which emphasise decentralisation and ubiquitous data formats that all participants can utilise. Establishing a common set of principles will ensure that design stories can be created and openly syndicated amongst the distributed project team.

5. The principles of the Project Information Cloud

For the Project Information Cloud to be established seven guiding principles should inform the methodologies and technologies that constitute it: simplicity, modular design, decentralisation, ubiquity, information awareness, evolutionary semantics and context sensitivity. These principles are inspired by the concepts that have driven development of the World Wide Web¹⁰ yet reflect the objective of the Project Information Cloud to be a common, distributed environment for exchanging design meta-data and preserving cohesive design stories.

The principles of simplicity, modular design and decentralisation are intended to ensure implementations of the Project Information Cloud are capable of accommodating the largest and most fragmented project teams. The principle of simplicity aims to ensure that the underlying data formats and structures that form the Cloud's fabric are easy to understand and replicate. This principle will ensure a broad range of digital design tools can evolve to interact with this space and the design stories it contains¹¹. The principle of modular design aims to ensure that undue influence cannot be exerted by a single participant or software vendor. To achieve this, any component of the Project Information Cloud should be able to be replaced by a similar, independently developed component. The centralisation of digital information is a key inhibitor to storing design stories within the Building Information Model. To avoid this problem the principle of decentralisation declares that the Cloud cannot be formed around, or rely upon, a specific digital information source. Within this space all points of data are of equal significance to ensure scalability and equal participation by all project members.

The principles of ubiquity, information awareness, evolutionary semantics and context sensitively are intended to promote the intelligent distribution of design information throughout the project team. The principle of ubiquity should influence the nature of the digital information exchanged. Rather than stipulating data formats the emphasis of the Project Information Cloud should be on identifying the most common formats available within each project team. As this data is referenced in the Cloud, the principle of information awareness will then ensure that these changes are efficiently syndicated throughout the design team. The principle of evolutionary semantics states that the taxonomy of the Project Information Cloud must be capable of changing¹². This will assist in meeting the diverse and shifting classification requirements of the design stories. Finally, the principle of context sensitivity ensures that design team participants are only presented with information that is appropriate for their role or the project's current state. Through the embodiment of these seven principles implementations of the Project Information Cloud will be successful in digitally recording a project's design stories.

6. Conclusion

Design stories are a valuable outcome from the architectural process. Despite this, project teams lack the ability to easily weave digital information streams into cohesive design stories. The current trend towards centralised Building Information Models has further degraded design stories as these models impose barriers to participation and rigid semantic data structures. The concept of a Project Information Cloud is proposed as a means of allowing participants to record design stories within a meta-data layer that inherits properties of the World Wide Web. By learning from the underlying lessons of the Web the AEC industry can position itself to evolve its digital methodologies and tools. This will enable the formation of Project Information Clouds. Once in place these clouds should improve the project team's ability to digitally record design discussion and its relationship to the Building Information Model. It is envisaged that the Project Information Cloud will provide AEC professionals with a more capable means of utilising their design stories for problem solving and collaboration.

References

1 see Aragon, Patrick. 2006. Reinventing Collaboration Across Internal and External Project Teams. http://www.aecbytes.com/viewpoint/2006/issue_28.html (accessed 3 March, 2007).

2 see Kvan, Thomas. “Collaborative Design: What is it?” Automation in Construction 9, no. 4 (2000): 409-15.

3 see D’Agostino, Bruce, Marisé Mikulis, and Mark Bridgers. Eighth Annual Survey of Owners. FMI/CMAA, 2007.

4 see Willis, Daniel, and Woodward, Todd. “Diminishing Difficulty - Mass Customization and the Digital Production of Architecture.” Harvard Design Magazine 23 (2005): 71-83.

5 see Ibrahim, Mary. “To Bim Or Not to Bim, This is Not the Question.” Paper presented at the Communicating Space(s) 24th eCAADe Conference Proceedings, Volos, Greece, 2006.

6 see Cooper, Graham, Cerulli, Cristina, Peng, Chengzhi, and Rezgui, Yacine. “Tracking Decision-Making During Architectural Design.” ITcon (2005): 125-39.

7 see Kiviniemi, A, M Fischer, and V Bazjanac. “Multi-Model Environment: Links Between Objects in Different Building Models.” Paper presented at the CIB W78's 22nd International Conference on Information Technology in Construction, Dresden, Germany, 2005.

8 see Amor, Robert, Ying Jiang, and Xiaofan Chen. “Bim in 2007 – Are We There Yet?” Paper presented at the Bringing ITC knowledge to work, Maribor, Slovenia, 2007.

9 see Al-Reshaid, K, and N Kartam. “Improving Construction Communication: The Impact of Online Technology.” Paper presented at the CiB W78, Vancover, Canda, 1999.

10 see Berners-Lee, Tim. 1998. Principles of Design. http://www.w3.org/DesignIssues/ Principles.html (accessed August 10, 2007).

11 Berners-Lee, Tim, and Mendelsohn, Noah. 2001. The Rule of Least Power. http://www.w3.org/2001/tag/doc/leastPower.html (accessed March 20, 2008).

12 see Mathes, Adam. “Folksonomies - Cooperative Classification and Communication Through Shared Metadata.” Computer Mediated Communication - LIS590CMC (2004).

Identifying where BIM ends and the wilderness begins

David — Thu, 01 Feb 2007 10:43:28 +0000

The term Building Information Model (BIM) is used fairly loosely in the Architecture, Engineering and Construction (AEC) technology industry. Most of the software 'formerly known as CAD' is now referred to as a Building Information Modeller (i.e. Autodesk Revit), or at a minimum reference the term in their marketing blurb. In the field of AEC research many papers reference the Building Information Model as a hypothetical construct holding boundless quantities of data about a building. This approach avoids a commitment to a particular technology (which in research is not a bad thing) but it does mean the definition of what is and is not a BIM becomes even less clear. Perhaps the best general description of what a Building Information Model is without resorting to either “whatever program X supports” or “pretty much anything” is from Jerry Laiserin when he first proposed that the industry stop using a range of terms and focus on just one.

“Combined, "building information" implies, to my ear, a strong sense of what the design, construction and operation of buildings is about. It avoids techno-jargon, yet remains evocative of technical goings-on. "Modeling," although a near-jargon word, does connote the mathematical or digital description of objects or systems, we have econometric models and weather models as well as physical models of 3D objects. "Modeling" also implies a process of description or representation that provides the foundation for building performance simulation (essentially, modeling future behavior) and for the management of building information (information models serving as the frameworks in which information is managed).” - Jerry Laiserin

Why is identifying the boundaries of BIM important? Firstly it avoids confusion which when mixed with expensive technologies and vague marketing can be a dangerous combination. Those not versed in what BIM is can be easily confused between it and other technology concepts such as parametric modeling and interoperability efforts. This confusion often arises because the three technology concepts are often combined in varying portions within contemporary software tools. However the capability to differentiate between these technologies is important because each is setting out to solve a different problem, and it is only through acknowledging the unique characteristics of each problem can the applicability or later success of a proposed solution be gauged and understood.

With the concept of BIM delineated from the gaggle of contemporary AEC technology concepts we are better able to distinguish its boundaries and through doing so establish what it can or cannot do. Establishing such boundaries is important otherwise testing becomes a case of answering every question with a 'definitely maybe if BIM was extended to encompass factor X'. An example of the quandary posed by the lack of a clear definition arises when the following question is posed:

Is BIM limited to a single data source or can it encompass a broad range of data sources related to a project?

Note the use of the term data source and not file, a data source can be comprised of many files but it is always accessed through a single interface, for example a Building Information Modeler.

Taking the above question and applying Laiserin's description of what constitutes BIM it is difficult to disprove either state as both hold merit. But through undertaking a little thought experiment we should be able to prove for all intent and purposes whether it is practical to establish and maintain a multi-sourced Building Information Model.

The issues behind a multi-sourced BIM

A Building Information Model could be comprised of multiple data sources so long as the model was capable of accessing, interrogating and integrating data from all sources. Unfortunately using this logic the BIM would need the capability of integrating potentially conflicting sources of information that may not be originating in the same data format. This leads to a vastly more complicated BIM infrastructure than one that stipulates from the outset it can only operate with a single data source.

Continuing with this line of thought let us assume that it is possible to have a BIM which comprises of many different data sources, for example individual architectural and building simulation files. This BIM would need to understand the specific semantics and syntax behind both data sources and be able to read (and preferably write) to them in near real-time. This real-time provision is made because users of the BIM are only interested in current data, in fact in many cases obsolete data is often of less value (and more dangerous) than none at all. When taken into account these are difficult requirements to fulfill, especially when the problem of AEC data interoperability is not fully resolved even after over a decade of development.

Even if a BIM gained the capability to read (and hopefully write) at real-time to interoperable data sources the task of applying these functions at an abstracted BIM level is an order of magnitude more complicated. This complexity arises because there exists the less easily defined or understood question of what is it exactly the BIM needs to know and why? From a theoretical perspective it is easy to propose that all information from the data source be integrated into the BIM, but pragmatically this is hardly efficient and the resultant 'blob' of data would be of little use except for archiving purposes. For example take our architectural and building simulation files and imagine extracting information from those into a unified BIM. Both hold similar but different geometry and material data, but which (if any) should hold prevalence within the BIM? Whilst it could be argued that both should be considered equal the practical reality is that one representation must claim dominance. Added to this there is the challenging question of how to treat derived information such as building performance data. Information such as this is integral to one data source (e.g. the building simulation) but related to the architectural data source only by proxy of the BIM itself. Consequently there are now three elements at play when dealing with a BIM such as this: the two data sources and a third meta-element which maps relationships between these individual data sources.

The difficulty with this third element is that it is not just undertaking the simple task of plotting how one data source translates to another as is the case in texture mapping. Different AEC data sources of the same building apply different assumptions and working methods to achieve their desired outcome. Consequently from the perspective of the trained eye two data sources can be described as being representations of the same thing, but from the perspective of the BIM these relationships are not so obvious. Figure 1 below illustrates this problem using the architecture and building simulation data sources mentioned previously. In this example different assumptions have been made in both sources that results in two very different datasets existing within the same BIM. The obvious answer to this quandary would be to stipulate that the building simulation team use exactly the same model as the architecture group. This enforces data consistency but from a practical perspective this usually not possible due to interoperability, pragmatic and contractual constraints.

Figure 1: Integrating different data sources within a BIM must acknowledge each dataset's assumptions and working processes

Evident from the experiment above is that embodying information from just two data sources into a single BIM is a potentially complicated process. Not only does the BIM solution need to read and manage multiple data source types but is also must map relationships between this data in a meaningful way. With this in mind is it possible to reduce this complexity by referencing external data sources, for example a URL (http://example.com) or UNC path (\\server\share\file), and still consider them part of the Building Information Model?

Hyperlink enabling the Building Information Model

Whilst a practical option I do not believe data sources that are linked to but not fully integrated into the Building Information Model can still be considered an integral component. A 'model' exists as a series of tightly coupled elements arranged within a predefined framework. Elements that are not tightly coupled to other elements, or exist beyond the defined framework, have no influence on the performance of the model and consequently offer little value.

Take for example our Solar System, if we were to model this we would include elements such as the planets and the Sun and place them within a framework of gravitational physics. This would enable the performance of the model to be studied under different conditions, such as altering the size of the Sun or changing the force of gravity. For the model to be of value the significant elements must be present within the model and cannot be referenced by a simple place holder or ignored completely.

Determining what is important within a Building Information Model is a very challenging proposition considering the wide range of stakeholders taking part in the process. Consequently as there currently exists no BIM value system (i.e. what should or should not be part of the model), it must be concluded that what exists beyond its tightly coupled confines holds no value to the model itself.

Note that this does not imply that externally referenced data sources have no value to the project itself, it simply means that from the perspective of the BIM their value cannot be realised.

Then BIM is best from a single source?

There is no denying that in a hypothetical future the concept of BIM could grow to encompass multiple data sources as the previously discussed issues are resolved. Unfortunately the conclusion from the previous thought experiment is that for the foreseeable future a Building Information Model can only operate successfully when tied to a single data source.

Unsurprisingly this is the approach taken by contemporary BIM software. All external data is imported and maintained within the package's data file to ensure consistency and the correct relationships. This removes the need to resolve the complicated issues behind multiple data sources but as a consequence the process becomes less about integration and more about assimilation. This approach also complicates teamwork and for consistency requires the use of a single BIM platform throughout the development of the project. Unfortunately this also results in increased overhead for those tasked with maintaining the Building Model whilst they oversee the consolidation and distribution of data to and from the single Building Model.

The centralised nature of contemporary BIM limits its scalability as the working relationships are centralised around a single point. Consequently the onus is on the central BIM maintainer (often the architect) to meet the information input and output requirements of the remaining project members. If information demands cannot be meet then it is natural for participants to bypass the source of congestion and exclude data from the Building Model, thereby reducing BIM's value within the building design process (refer figure 2).

Figure 2: A diagram illustrating the proposed relationship between the value of a BIM and the number of information sources over the course of a project

One relatively obvious solution to the problem is to create an independent central BIM server that is interfaced by a potentially infinite number of clients. This is the approach successfully employed by database and identity management systems to great effect. If deployed correctly the client/server model offers significant benefits such as fine grained access controls, data consistency and a limited level of scalability and robustness. Unfortunately this is a “boil the ocean” approach as for most it would require a complete retooling of their existing software packages and a fundamental reorganisation of the way building professionals work with each other. Consequently whilst theoretically a worthwhile solution, and even applicable in a limited number of situations, it cannot be considered as a general solution to maintaining an accurate and active Building Information Model.

When asked by a reporter what to do about U-boat sinkings during World War I, Will Rogers is said to have responded: "Boil the ocean". "But how would you do that?" the reporter continued. Without a beat Rogers replied, "I'm just the idea man here. Get someone else to work out the details."

Knowing the way forward requires knowledge of where you are

So from this thought experiment what conclusions can be derived? Firstly for the foreseeable future a Building Information Model should be considered as a single data source which maintains a limited array of building specific data in a framework intended for intelligent investigation and interrogation. BIM is not a platform for any or all project related data because by design it creates an information bottleneck that without significant and sustained commitment will hamper collaboration and ultimately degrade the value of the Building Model itself.

Acknowledging the boundaries of BIM and its subsequent shortcomings enables a critical view of the long term information management shortcomings facing the AEC industry. In the coming years it is of no doubt the current BIM implementations will improve, taking on more responsibility and capability within the building design process. Unfortunately as this discussion has illustrated BIM cannot hope to cover a design team's complete information needs unless that team is willing to forgo flexibility and scale. However by keeping these identified process and information management shortcomings in mind it is possible to map out where AEC information technology and process needs to improve in order to assist in the accurate and timely recording of building design information.

Behind the Building Information Model Buzz

David — Thu, 25 Jan 2007 23:19:13 +0000

Last week I was invited to attend a meeting of a few local architects where they discussed the Building Information Model and its relationship to documentation. Before attending I prepared the following document which I distributed amoungst the attendents. In it I aimed to clarify what BIM is (or more importantly what is isn't) and give them an indication of the issues surrounding the concept of BIM from a macro-perspective. Most attendants were very familar with the power of BIM tools such as Autodesk Revit but in general there was a lot of confusion between BIM and parametric modeling. There were also mixed feelings on the capabilities of BIM as a collaboration platform. For the practices involved it had helped internal processes but it was acknowledged that getting disparate information from design team participants into a BIM was a challenging task. Interoperability between various BIM platforms was an issue but there was the greater factor that many people working within the industry still produce relatively 'dumb' (i.e. basic 2D/3D drawings) that need to be practically recreated in BIM if it is to be of use within the model.

What follows is a web version of the printed document I distributed for reference:

Behind the Building Information Model Buzz

The 'Building Information Model' (BIM) is a marketing buzzword that has been heavily promoted by many Architecture, Engineering and Construction (AEC) software vendors. But what exactly is it, how will it effect the way you work and will it solve all of your problems?

Hold on, what is a Building Information Model before I buy one?

The term Building Information Model originated at Autodesk and was unofficially adopted by the rest of the CAD industry after it was 'blessed' in a column entitled “Comparing Pommes and Naranjas” by influential AEC technologist Jerry Laiserin.

BIM as a black hole: A moment of potential
infinite information density within a project

Conceptually a black hole as a useful metaphor for envisaging a Building Information Model. It is a single point within an architectural project where data is (potentially) infinitely dense. The architect sits on the event horizon of this singularity and is able to take in everything at once, so long as what they maybe interested in has been consumed by the BIM. Take note though that the black hole metaphor is used as a metaphor for mass density and not in a foreboding, destructive sense. However parallels can be drawn to the inability of matter to escape a black hole and the similar difficulties faced when allowing different parties to simultaneously modify the same BIM.

The academic definition of what constitutes a Building Information Model however is not precisely defined. The general consensus is that BIM is a single digital database holding all relevant building information, i.e. 2D, 3D and nD (time) data. BIM should not be confused with parametric modelling which can be difficult as the two often coexist together within software products such as Revit. BIM is not necessarily a 3D model or a defined manner of working, at its heart it is a conceptual data structure with an indeterminate number of ways of interrogating and working with the data contained within.

Is this a crazy new idea or a variation on an old theme?

BIM draws its roots from the digital product model concepts within the aerospace, shipbuilding and mass production industries that evolved during the 1970's and 80's.

With the rise of the computer within architecture practice a central focus of AEC software vendors was on the digitisation of conventional methods rather than the creation of completely new ways of working. This ensured a smoother adoption curve but minimised the capability of software to take full advantage of the rich, 3-dimensional representations created by architects.

Product models are highly defined and have
their own visual language called STEP Express-G

AEC researchers identified technologies associated with productised industries (such as aircraft and ships) as being beneficial to the productivity of AEC practitioners. As these industries have relatively closed development cycles, (i.e. one or two large companies collaborating on a limited number of products) software vendors had been able to craft new tools which allowed designers to build inherently intelligent digital models.

As these 'smarter' models facilitated time and financial savings in the architectural process pioneering CAD vendors like Graphisoft (ArchiCAD) began to create the first intelligent building models. Unfortunately for software vendors moving the product model concept into architecture has not been simple because unlike aerospace industry each architectural design is for a specific environment and realised by a team of loosely joined professionals.

Where is BIM today?

Currently the complete vision of BIM is yet to be fully realised. The BIM ideal is that the digital model becomes the focus of all documentation for the life of the building. Presently BIM is only now making inroads into architectural design and documentation aspects of the process and has yet to evolve into a set of universal standards for interacting with architectural data. Given the massive investment in conventional CAD tools and entrenched working practices the move to a BIM manner of working has been very slow. However there are more factors at work in this slow adoption than the natural intertia of an industry way of new ways of working.

Barriers to this vision

Time is not the only limiting factor in the adoption of BIM throughout the AEC industry. Currently the industry fragmented by a host of vastly different professional interests (architects, engineers, contractors, quantity surveyors, etc.) and powerful commercial interests formed by the various technology vendors.

An overview of the IFC 2x2 data schema:
Whilst IFCs now cover many facets of the
AEC domain they do so at the expense of
software complexity (click to enlarge)

Accommodating the varied professional demands of the industry within a single digital representation is very demanding. In the early 1990's the International Alliance for Interoperability was established to develop a universal digital model for architectural projects. After fifteen years of continued development their Industry Foundation Classes (IFCs) are yet encompass the informational demands of the AEC domain. The cause of this delay is the human inability to universally agree on complex semantic terms. This is confounded by the fact many architectural terms inherently convey rich cultural histories through subtle physical and tactile differences.

Compounding this problem is the strong commercial divisions which are driven by financial and corporate motives. Large software vendors like Microsoft, Autodesk and Bentley profit most when they can create stacks of integrated products that hinder integration with third parties (data silos). The most recent example of a data silo is Autodesk's TrustedDWG standard introduced in AutoCAD 2007.

So where does the future lie for BIM?

Architectural design projects, like nebulas
come in all sizes and have many points of intensity

Given the fragmented nature of the architecture process, the degree of process change required for BIM introduction and the inconsistent level of technology uptake across the entire industry, it will be difficult for BIM to become the predominant form of architectural information storage as we move into the 21st Century. In fact it is highly likely that whilst BIM will continue to build on its role as a central information repository for the architect it will still play a supporting role alongside traditional documentation, numerous digital models (used for simulation, fabrication and presentation) and messaging services such as email, formal meetings and documentation. Consequently the information behind an architectural project may never take on the pure metaphor of a black hole but rather a nebula, open ended, decentralised and full of interesting things that detract from other interesting things, including the odd black hole.

If such a metaphor is more appropriate for the building design process then what is most significance is how design team members navigate the varying brief requirements, architectural intentions and pragmatic constraints to reach the decisions they made. The artefacts of these decision making processes are the digital models, drawings and documented exchanges generated during the course of a project. Consequently whilst BIM will continue to gain industry adoption it will never constitute the sole outcome of a design, or reach its full potential until it is understood within the greater expanse that is the digital design collaboration process.

Where my thesis begins

The architectural design problem that sets the undertone for the thesis is how to improve the ability for an architectural team members to maintain a digital record of their design processes and decisions in an increasingly distributed operating environment. My thesis begins with the observation that perhaps the concept of the Building Information Model is not the silver bullet to which many AEC professionals are pinning their hopes given it cannot realistically fulfil all the roles destined for it. The thesis then explores the principles of the Internet as a means of moving forward the process of architectural collaboration.

Reasonate: A prototype put together and tested
for my thesis that explored distributed ways
of design development and documentation

As the Building Information Model was based on pre-Internet, product model concepts it cannot flourish within an untrusted, dissimilar and distributed environment such as that present on the Internet. Through interrogating the methods and motives of the Internet my intention is to establish a new set of principles for the Project Information Cloud. The Project Information Cloud is a term of my own creation that describes a method of design collaboration that emphasises distributed working environments loosely coupled together via Internet technologies such as hyperlinks, syndication and evolving classification systems generated within the design team.

Reinventing Collaboration: An Adobe Perspective

David — Fri, 15 Sep 2006 03:23:48 +0000

The September 15th edition of the AECBytes email newsletter it featured a very good article from Patrick Aragon from Adobe. Entitled Reinventing Collaboration across Internal and External Project Teams, the article focused on findings from collaboration research conducted by Harris Interactive (on behalf of Adobe). The research concentrated on how Architecture, Engineering and Construction (AEC) professionals collaborate digitally. The research was undertaken using an online survey undertaken during April of 2006.

From the perspective of my own research the most significant finding from the article is that 72% of respondents collaborated outside their office location. This is a clear indication that the concept of a consolidated ‘office space’ where all design/construction activity takes place is eroding (or perhaps never existed). As a consequence the value of centralised, firewalled project databases or physical documentation repositories is brought into question because if project information cannot be accessed when and where it is needed what immediate value does it hold to the process? Of course these repositories are required for long-term reference and legal purposes but in the interests of moving a project forward it would appear participants are limited to the project knowledge they can personally recollect or store in a mobile device (be it laptop, phone or briefcase).

The other interesting finding was the collaboration file format breakdown as it illustrated the overwhelming majority of exchanged data is by and large straightforward text, numeric and image data stored in Word, Excel and jpeg formats respectively. The other very significant format used by participants is PDF which typically contains textual data but is capable of transferring any printable information (from pixel-based image to vector-based plan) making it difficult to classify. What all these formats have in common is that they are not semantically rich or typically considered part of a greater Building Information Model. In fact from the study it would appear that only approximately 21% of participants use some form of 3-dimensional computer model as a means of collaboration whilst 2-dimensional CAD representation is slightly higher at approximately 38%. These findings highlight the following issues of relevance to my thesis:

1. Given the emergence of Writable-Web tools like blogging, image sharing and the so-called Google Office (and equivalents) what is the future for the bulk of AEC collaboration?

2. Considering the majority of AEC collaboration takes place in formats not suited for integration with the Building Information Model does this validate the need for a looser, broader concept for dealing with design project information in an intelligent manner?

The future role of the Writeable-Web in AEC collaboration

The underlying motivation behind adoption of blogging and online photo-sharing is that these tools make very simple the publishing, consumption and feedback processes. Prior to these tools sharing information over the Internet took place primarily via email. Whilst email has the capability to ‘just work’ it is not as useful for sharing complex or time-sensitive data and requires recipients to be explicitly stated when the message is created. Consequently these issues add collaboration barriers and potentially limit the target audience.

Considering the bulk of AEC collaboration takes place in formats that are already compatible with these emerging Writable-Web services it is not unrealistic to suggest that the majority of AEC collaboration could one day take place within this arena and not be limited to isolated and proprietary files spread across participants’ various storage devices. This would dramatically change the collaboration landscape as the goal would cease to be getting discrete packets of data from A to B and instead focus on the means by which this fluid information could be efficiently directed, harnessed and monitored.

It is also important to note the increasing use of online blogging and photo-sharing tools, alongside the evolution of Web-based ‘Office’ applications and comparatively neutral formats like PDF have begun to loosen the tight grip a few software vendors have over the ownership and use of people’s data. The net effect of these Writable-Web tools is that they help in reducing the once difficult task of online collaboration, allowing participants to focus more time on the conveyed message or other pressing tasks. These open and ubiquitous data formats also ensure that in the long-term project data is not lost through software version incompatibilities or change in software vendor. This is a significant factor to consider when comparing a typical building life-cycle against the average lifespan of a software product and the more general rate of I.T. change within the AEC industry.

There are several issues to overcome before this idea can become reality. The most important is digitally representing the project team structure within this Writable-Web environment. Point to point transfer of data using tools like email manually ensures agreed upon management and communication structures are maintained. For reasons of confidentiality and consistency all project data cannot be made readable by all parties, that is just an invitation for confusion and disagreement. Likewise publishing content on the Web and locking access to a specific set of recipients significantly limits the potential usefulness of the information. What is required is an access system that balances these two requirements in a way that is both receptive to project requirements and conducive to strong collaboration.

The Building Information Model and AEC Collaboration

What is evident from the Harris Interactive/Adobe research is that basic 3-dimensional or complex Building Information Models are not widely used as a source of information within collaborative AEC environments. Arguably BIM is potentially the richest source of information within a project but that depends on its ability to consume these disparate sources of information.

Conclusive statements on the use of BIM in project collaboration cannot be drawn because it is difficult from the information presented to identify time-based usage trends. An interesting followup study to the one undertaken would be to look at the use of collaboration file formats over a period of time. What may become apparent from further study is a rapid decline in 2D CAD use or a rise in 3D model adoption which would indicate an increase in BIM adoption. This may indicate that BIM is gaining acceptance within the industry and in the long-term may satisfy more collaboration needs.

However based on the results presented it would appear that the role of Building Information Model as a collaborative tool is very limited no matter what the context. BIM as a concept is attempting to consolidate the various information streams into a concise, powerful and easily navigable model. In doing so BIM aims to increase project consistency and reduce the manual information monitoring and searching loads placed on current project participants. Unfortunately if BIM is failing to meet the collaboration needs of design participants, which from this study seems to indicate an emphasis on relatively basic information sources, then its value within the AEC design process is significantly limited. As Patrick Aragon states, “collaboration is intimately linked with communication--and to success” and if BIM cannot be a meaningful participant in this process then something is required to meet the very real information management challenges it was intended to address.

Two articles on Building Information Modelling

David — Mon, 26 Jun 2006 10:39:41 +0000

Recently two useful articles on BIM have been posted. The first from Cadalyst is a general overview of the BIM product space providing a brief overview of all the major vendors offerings (with links to more info). Light on content but still a useful point of reference none the less. The second is a more in-depth article that reviews the AIA Integrated Practice 2006 conference. The interesting idea put forward in this piece is that architects are not really using BIM tools to model the complete building model but rather are focusing on the drawing aspects of it (referred to as DIM - Drawing Information Model). Conversely it is proposed that the only people currently using BIM for its proper purpose are contractors who are less worried about documentation and more concerned about nuts and bolts (literally).

What this article highlights alongside the work going on at Bentley to do with generative objects is that there is a growing market for specialist information systems workers within the AEC space. These information systems specialists are needed to efficiently and economically achieve the objectives set out by the Building Information Modelling process in terms of model/data gathering and processing. Asking architects, engineers or project managers to undertake this highly important, difficult yet presently overlooked role is a factor leading to the failure of many attempts at achieving a true BIM methodology (rather than simply DIM). It seems only logical really considering the number of third-party contractors already employed in the process (engineers, building scientists, quanitity estimators, surveyors, etc.) that the all important task of efficiently juggling all this information should also be contracted out to a specialist third party. Just a thought...