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.
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).
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.