Introduction

For over a decade now, BIM (Building Information Modelling) has been a key part of the mainstream in AECO (architecture, engineering, construction and operation) computerization. Every week new scientific publications appear on the subject, while BIM software is constantly updated and augmented. The number of BIM users keeps on increasing and various public and private bodies issue recommendations, requirements, policies and standards for BIM. The success of this wide and heavily promoted technology can only be described as varied, but this does not seem to affect the optimism surrounding the technology. The promise of BIM remains significant but so do the obstacles. What can help to unlock this potential?

The situation invites a thorough investigation of BIM and its various contexts, especially because so far critical perspectives have been sparse and incidental. As with many tendencies in digitization, it is often easy to be annoyed by the superficiality BIM is sometimes treated with, even in scientific publications. It is therefore tempting to get didactic and admonish inconsistent users to study the methodology of BIM or uninformed developers to search for precedents in the rich history of computerization. Hopefully, the following text does not succumb to this temptation too often because it is motivated more by a quest for deeper issues that underlie BIM, and probably go beyond BIM in doing so.

Our primary aim is to pose meaningful questions against an informative background that helps comprehension and possibly also points out directions where answers may be found. This specificity is significant because one can discuss BIM at multiple levels: at the level of how the tools and the underlying technology are applied in practice; at the level of the technology developed according to some theory; at the level of the theory itself. Our questions concern all levels and the connections between them, towards an analysis of the whole phenomenon. Each question is intended as a starting or key point in unravelling the complex situation around BIM.

In addition to the above levels, one should also consider the approach to the design, construction and management of buildings. In keeping with BIM theory, we depart from an engineering approach, usually involving methodical and incremental development by several actors towards a full specification of a product and process. This does not preclude other approaches, in particular algorithmic ones, as parameterization in BIM demonstrates. It merely constrains the scope of these approaches to the way BIM organizes processes around a shared building model. Understanding BIM from socio-technical or even socio-material perspective might illuminate, for example, how it recasts or even reconstitutes the relationships between actors, designs, representations and built assets themselves.

Similarly, we use the term AECO computerization to describe computer technologies for the production and use of buildings, instead of alternatives like computer-aided architectural design, design computing, digital design, architectural computerization, computational design etc. This serves to stress that the technologies are intended for the professionals involved in the practical, day-to-day design, construction, management and operation of buildings.

Transitions

The advent of BIM marked a significant transition in AECO computerization but not necessarily for the reasons mostly quoted in BIM lore. Two real reasons that deserve attention are the promotion of explicit symbolic representations and the wide support for BIM.

Transition to explicit symbolic representations

Before BIM, the representations used in mainstream AECO were chiefly graphic supplemented by text, as in specifications. They described buildings at the level of implementation mechanisms used in analogue representations, such as two- and three-dimensional shapes. And as in analogue representations, like drawings on paper, the symbols were implicit in combinations of these graphic primitives (implementation mechanisms) and dependent on the readers’ ability to recognize them. In BIM, by contrast, the symbols are explicit – and commonly but arguably misleadingly called “objects” (more on this later).

An example that explains the relation between symbols and implementation mechanisms in analogue and digital representations is handwritten versus computer-processed text in Latin characters: in handwriting, one puts explicit strokes on paper or other medium, e.g. a doughnut and a short vertical stick to form a lowercase ‘a’. The strokes are the implementation mechanisms and in handwriting they are explicit. The letters are the symbols and in handwriting they are implicit. In computer-processed texts, one does not enter strokes but symbols, using keyboards and similar interfaces. The letters are explicit in the computer memory as Unicode symbols. The bits and bytes used to physically store the Unicode symbols are the implementation mechanisms. The strokes comprising a letter are visible on the screen but they are just a view of the symbols. To avoid confusion, in this text we reserve the term ‘symbol’ for what denotes the real thing or concept, e.g., the grapheme ‘a’ or the symbol of a door. The strokes and lines used in these symbols are called 'graphic elements'.

It should be stressed that the dominance of graphic representations in practice does not imply that research had not explored symbolic approaches. In fact, one can say that BIM precedes CAD, through design systems from the 1960 through to the 1980s like OXSYS, then BDS [8] and its 2D sequel GDS by Applied Research of Cambridge. Interestingly, GDS was purchased by McDonnell Douglas who then produced Revit using the BDS/GDS code, effectively making Revit the grandchild of BDS and great-grandchild of OXYSYS. Regrettably, such systems failed to reach the wide audience attained by CAD and its facsimile of analogue, paper-drawing representations. See also [3] for another proposal for an early system also called BDS.

The use of explicit symbols brings AECO in line with wider developments in computerization and representation in general but is not without difficulties. Quite often, the correspondence between the real-world, intellectual concepts and their symbols is vague, as one can see in relation between the Latin alphabet (one of the exemplary successes of symbolic representation) and the languages that employ it. In English, for example, the grapheme ‘a’ corresponds to five different phonemes (as in the words ‘car’, ‘cat’, ‘call’, ‘alive’ and ‘talk’). In building representations such vagueness is evident in symbols for building elements like walls, which can have complex shapes and variable composition. When representing walls with lines, individual line segments do not suggest the wall has parts, just as letters of which a word is composed do not suggest the concept the word represents has parts. On the other hand, when using BIM symbols for walls, we cut them up in wall segments more based on the geometry of their axes (which relates to how these are drawn) than on any construction logic. This suggests that the symbolic representations used in AECO and BIM require further attention. Furthermore, the implicit BIM ontology is based on the rather naive assumption that the correct way to break down a building into objects can be determined by observing real world buildings.

Popular acceptance and support

Earlier computing technologies in AECO were sometimes met with enthusiasm that led to disappointment but more frequently with scepticism, reluctance, rejection or hostility. They were seen as costly and alienating, as limiting creativity and imposing unnecessary constraints on existing practices. For a long time, office automation was more prominent in AECO offices than domain-specific computerization. Adoption of 2D and 3D drawing systems took a long time, accelerating only after desktop systems became feasible.

It was therefore surprising that BIM received such rapid adoption, especially since by the time of its appearance CAD was firmly established in AECO. Even people with a rather sketchy understanding of computerization were actively promoting BIM. Moreover, they frequently pushed BIM as a panacea to the management of information with flagrant disregard for the unintended consequences of using digital practices to drive change. Mandating BIM for public or major projects is quite different to attempts at innovation in building construction through digital transformation [4].

The early popularity of BIM can be explained in various ways: by the extensive promise of the technology, especially for overall AECO performance; by the presence of a domain theory behind the technology (while with CAD, many academics stressed the difference between ‘intelligent design’ and ‘stupid drawing’); by the naïve belief that BIM model was more “real” than CAD drawing; by the strong cohering narratives that cemented belief in BIM in an industry so reliant on analogue practices; by the apparent simplicity of BIM, which arguably made it appealing to non-experts; by the realization that AECO was lagging behind other disciplines in both computerization and performance. Regardless of explanation, it is significant that BIM entered AECO with a wide support base, characterized by a staunch, often unquestioning, belief in its promise. The academic environment was characterised by groupthink in which scepticism was undesired.

Promise and performance

With hyperbole characteristic of technology marketing, BIM rhetoric presented the technology and its underlying approach as a panacea for all AECO ills. Soon enough, however, users started voicing complaints about hardware and training costs, cumbersome or underperforming software, and other practical matters that are often dismissed as teething problems or mere malingering. What has been objectively measured were the increased costs of producing the design documentation while the industry has not seen any drop in prices of the finished product for the client. The entire BIM community has been focused on increasing the quality and detailing of digital models under the assumption that more information must be beneficial down the value chain. This is contrary to the initial understanding of the STEP standards, that this is all about the exchange of information and about providing sufficient information downstream the process. At the same time, the promotion of BIM went on and client bodies started to demand it, often without properly understanding the purpose or burdens, having been sold the hypothetical benefits.

Dismissing such problems is not without foundation: the same users who complain about BIM costs and complexity may spend considerable sums to possess the latest smartphone and become expert users of social media for their private activities without any formal training. On the other hand, however, any practical complaint deserves at least some attention, as it can signify room for improvement in areas of direct or high impact, such as ease of use: it is not difficult to see that smartphone apps are significantly easier, far more intuitive and more closely attuned to user actions than the archaically expansive interfaces of BIM or CAD software. Interface design is not cosmetic: it follows an underlying approach to information processing and interaction or a philosophy about the role of computers and their users. Could it be that BIM is based on outdated ideas on the subject within the model-view-controller paradigm? Could it be that it does not reflect the custom and practice that defines professional interactions across the interfaces within the AECO domain? Or could it be that it follows too closely a sterile engineering approach at the cost of the ambiguity and abstraction designers prefer? A symbol with behaviours may be more explicit than a designer wants, which may limit BIM to a cosmetic appearance in late design.

What has seldom been questioned was BIM performance: few have doubted the promised improvement and its validity, even though the espoused heights of Level 3 were seldom if ever met. What used to be documented in a multitude of drawings is lately documented in a multitude of federated or linked or in some other way connected BIM models. And whatever does not fit into those models is stored in something called “Common Data Environment” which is little more than a glorified Dropbox. It was widely assumed that full and correct application of BIM (itself a rarity) would deliver its promise. The fault therefore lay with the clients pushing its adoption, the naive users and their joint half-hearted use of BIM. Still, as any serious and committed user of BIM can attest, there are many problems with both the software and the approach, including considerable room for error, despite the prescriptiveness of BIM.

Misconceptions and misunderstandings

At the heart of it all, there are several fundamental misconceptions and misunderstandings, in particular by developers and users, deriving jointly from a disconnection with the history of AECO computerization and the superficial, elliptical or downright wrong way BIM is presented. The following are some of the most critical ones.

Integration—but how?

It is often stressed that BIM achieves integration of building information and so facilitates integration of information, communication and decision processes. What is not always explained in how integration is achieved. Many think of integration merely in terms of having all drawings and other documents –floor plans, sections, elevation, details, perspectives, specifications, quantities, etc.– in the same model. Others come closer to the truth by explaining that all documents are views of the same model, which accommodates all building information. However, this does not explain how the model integrates information.

Once integration is explained as a natural consequence of the symbolic structure of the model, i.e. that all information is in the properties and relations of the same symbols (rather than spread over a number of different drawings), integration in BIM is no longer magic, a wondrous black box, but transparent and rather unspectacular. At the same time, it is highly operational and therefore valuable: it establishes a simple basis for authorship and custodianship and directs discussion and development to the real issues of symbols and the things or concepts they represent—as opposed to relative trivialities such as the production of various projections from the same model. These issues generally transcend the technical and affect the social, e.g., processes of decision making, learning and sense making [14]. It has been argued, though, that even integration of this kind is not achievable. The industry is not interested in integration per se, but in specialization, division of labour and higher productivity. For this reason, all information may never be present in a unified symbolic structure of a model [13] which may not even be tragic as the function expected from AECO computerisation is informing and not representing.

Objects and symbols

BIM is presented as “object-based” or “object-oriented”, by which it is meant that rather than drawing the graphic elements that comprise the appearance of a symbol of a construction thing, one works directly with the symbol of the thing, which is usually selected from a library of predefined construction symbols. There are two main problems with this: firstly, object-based and object-oriented have a rather specific and quite different meaning in computer science. This goes beyond confusion; it creates the suspicion of seeking legitimacy for BIM and symbol libraries in established but unrelated terms. Ironically, one could argue that in many respects BIM is object-oriented (although this may not apply to its current implementations) but not for calling building elements ‘objects’.

Secondly, the objects in BIM do not always do justice to the elegance and power of symbolic representation, while suffering from many of its problems. Equating the symbol with the thing it symbolizes is a common issue in any area but in the case of BIM it obscures fundamental inconsistencies in the ways symbols are defined. In a BIM library, one encounters fully standardized building components, like steel profiles; ad hoc assemblies with a largely fixed structure and form, like doors of a specific type; quite flexible assemblies, such as wall types, in which one can change various properties of different layers without crossing over to a different type. All these usually come in completely standardized versions that do not necessarily agree with the ways the symbolized things are produced or the ways buildings are designed.

What they do agree with is legacy conventions that derive from the limitations of analogue representations, such as the SfB classification. These were reasonable common arrangements for the pre-computer use of catalogues of standard details and components. They are, however, unsuitable as a departure for computerization because they reduce the domain of discourse that BIM is called to model to an earlier understanding of the domain. BIM symbols, including standards like IFC, need rethinking with respect to the real purposes of our representations, which should not be confused with means like the production of conventional documents. One must scratch below the surface of convention to uncover the path dependencies that shape current practices.

Appropriation of computing

Many of the advertised advantages of BIM are not specific to the particular technology but generic to computerization. Probably the most striking example is the early use of 3D modelling as a unique selling point for BIM, something patently false because 3D had been available in CAD from the very beginning—not to mention in the precursors to BIM like BDS. It may be customary to present new products through favourable comparisons to precedent ones but the comparison to CAD would have been more meaningful without such falsehoods. Instead, it indicates that both proponents of BIM and users of CAD knew little about the potential of the latter. Should we expect that users of BIM are more knowledgeable of the new technology and aware of its potential?

Polarization

Another aspect of the same polemic push for BIM is the juxtaposition to ‘traditional’, underperforming practices and approaches. This may be typical of innovative and disruptive rhetoric but, once again, it also suggests appropriation of various innovative approaches that precede BIM and are compatible with it. Interestingly, these approaches could equally well be considered part of ‘tradition’ and so be summarily and unjustly dismissed by BIM propaganda.

Equally interesting is that here ‘tradition’ is used negatively, as a synonym of stagnation and backwardness, in contrast to other contexts: ‘traditional food’ is wholesome and tasty [11], while popular events are supported by invented yet cherished traditions [5]. By contrast, ‘traditional’ design and construction are presented as having little to offer. One could argue that, while in a technological context advancement entails rejection of tradition, in a social context traditional means are proven and positive—to be challenged, for sure, but not to be dismissed without care. In a sociotechnical context, tradition could also be positive as an expression of perhaps not fully understood benefits of the existing situation.

‘Tradition’ is moreover arguably the wrong term in this context. What impedes progress and hampers performance is convention: the practices that formalize (including by law) social customs, so that they can be imparted to new practitioners, together with the received wisdom of their domain. An inherent weakness of convention is that, to safeguard satisfaction, it promotes invariant performance at an accessible level. Imposing fixed, formalized practices may guarantee adherence to social continuity and balance but also reduces the potential for change and innovation. Conventions in AECO, too, are designed to ensure inclusiveness: they establish relatively low thresholds that allow various kinds of professionals to work together in the production and operation of buildings.

BIM aspires to inclusiveness but also to improve performance and innovate. On the one hand, it changes the way building information is organized and processed but at the same time it sticks to conventional documents as output and, arguably more destructively, as interfaces that distort users’ perspectives of building information, including of BIM itself. As if it were not enough that the production processes of the built environment remain unchanged, design and communication also appear (superficially, at least) to be the same. The only difference is that BIM, as a magic black box in the background, makes everything better if not easier. Does this happen automatically when we start using BIM? Or is BIM willingly entrenched in the conventions it purports to reject or replace? Its attachment to the ‘objects’ and drawings of analogue, paper-based practices suggests little fundamental change. What is more, BIM has a normative character that adds to the prescriptiveness of AECO procedures [7], creating neo-traditions and requiring conformity in order to deliver. It is symptomatic how changes in the ways buildings are represented lead to an inflation of the documents needed to organize and manage the process of producing building models. In the grand scheme of things of ISO 19650, the BIM Execution Plan, something that was not needed in the world of drawings, is a tiny piece in a deluge of standards, agreements, contracts and plans.

An additional challenge is that customs vary across cultures, so the professional customs in AECO in the US are not the same as those in Japan or France. Development teams tend to encode their own cultural customs and, as a result of that, systems intended for a global market allow for little if any local variance.

Finally, one could suggest that the prescriptive character of BIM de-skills and hence adversely disrupts the elements of craft (in the sense used by Richard Sennett), which shape excellent design and production practices. It is arguable that, by its attachment to AECO convention and its lack of attention to underlying conditions, BIM takes the industry backwards in many respects, creating processes that are black-boxed and design elements that are standardized. The question therefore is: which existing AECO practices should be supported rather than suppressed by BIM?

Information exchange

One of the most exciting parts of the BIM promise was the coming together of all actor and stakeholder actions and data in a central, shared model that practically guaranteed completeness, coherence and consistency, and facilitated project management. Very soon, however, for practical reasons that had to do with BIM software, servers and networks, as well as due to ingrained AECO practices against synchronous, open collaboration, everyone was working on their own part or aspect of the model, synchronizing with the others every day or even week, very much as before BIM. The consequence was an anachronistic and costly emphasis on information exchange or, more precisely, file exchange (remarkably sanctioned by the definition of Levels 1 and 2). Asynchronous workflows dominated, even though they ran contrary to the principles of BIM and replicated the ‘traditional’ models of collaboration that BIM purports to replace.

This illustrates the abject failure of technocratic solutions to address social issues, despite the potential of their technologies, and marks an important shift of emphasis from interoperability and integration to representation. BIM originally departed from the representation as an externalization of decisions but even more as a context for communication. By removing the latter function and reducing communication to prescriptive workflows around the representation, BIM fails to fulfil its potential and leaves social aspects of communication underexplored. Such issues are not unique to BIM. Similar pressures have been exerted on all other new tools, even CAD. The potentials of these tools are perverted and diluted until they do not upset the established professional power structures and subservience – hence in the UK CAD started strong when the BRE was operating and in the US the legal strictures in construction slowed acceptance down so architects did not want to create a descriptive model because liability flowed back to the author. Many of the implementation problems appear to derive from these national professional needs to contain responsibilities.

One can view the resulting situation pragmatically, as a valid hybrid practice [2], but it is doubtful that hybridization truly works in this case. BIM does not merely demand a central position in information and decision processes, it is also holistic in that it expects everything to start from and preferably also remain in BIM. This obviously begs the question whether BIM can handle everything, as its most staunch advocates claim, but also invites a closer look at hybridization practices, such as information exchange around BIM. A cursory glance at current recommendations on the subject (https://www.bimloket.nl/p/294/BIM-basis-ILS) returns reasonable yet basic stuff, e.g. on the standardization of file and layer names, but also multiple standards, e.g. IFC and NL-Sfb, which may differ in their definitions of ‘objects’. This adherence to multiple conventions, both new and old, means any incompatibilities between them are left to the pragmatic improvisations of users. Should they prioritize IFC in order to stay closer to the principles of BIM or NL-Sfb so as to produce conventional documents more easily? Hybridization may both confuse and come at a high operational cost.

As for information exchange itself, it is striking that IFC, a lexicographic data standard, is abused as a pretended exchange scheme, with most people focusing on its apparent top-level simplicity and ignoring what lies underneath, notably elements borrowed from STEP (ISO 10,303): a rather old standard with known difficulties in geometric conversions, which would have been largely irrelevant in a shared model. That the goal of information is informing others and not creating a digital replica, has been forgotten by many in the process including the policymakers that would mandate the use of BIM, not a certain quality of information.

Client demands

Quite often the use and costs of BIM are referred to the client: the client should be wishing BIM for the design, construction and possibly operation of their building, so they should cover the costs of the additional resources required for BIM. This is a strange, hardly professional, attitude. A direct question is why the client should require BIM. The probable answer is that they are advised to do so not for efficiencies in the design and construction phase but for lower risk in that phase and subsequent efficiencies in operation. If these goals coincide with the interests of the AECO professionals, it is up to the professionals to adopt it and profit from the higher efficiency, reliability or other performance it supports. Any additional costs, especially in overhead (including training), should be compensated by that and probably even more by additional services AECO can offer thanks to BIM. Seeing BIM as an overlay on existing practices and tasks does little to deepen and widen adoption or sustained utilization of the technology. It also undermines its capacity to collect and integrate: even though BIM software includes means for reporting and communicating issues with respect to a model, a 2015 survey suggests that most communication about a model took place through emails, which often included views of the model as illustrations (https://www.architectsdatafile.co.uk/news/70-of-aec-firms-say-the-information-explosion-has-impacted-collaboration/). With the further proliferation of smartphones and the growing popularity of communication through messaging apps, it is unlikely that this has been reversed in favour of communication within BIM in the meantime.

Opinions and facts

One of the strikingly worrying features of both scientific and popular reports on BIM is that value, success, performance etc. of BIM in projects and enterprises are measured by the opinions of users, expert or not, as stated in interviews and questionnaires (e.g. https://architecturequote.com/architecture-statistics/). However useful for understanding e.g. expectations and experiences, these opinions should not be taken at face value; yet, most performance improvements and benefits quoted in literature are subjective estimates. Time-use studies have demonstrated that such estimates may differ even from diaries kept by the same persons [9]: the more stressed people are, the more pessimistic their estimates of how they spend their days, even adding up to more than twenty-four hours per day. In our case, even basic information, such as how long it takes to complete a specific task with or without BIM, is lacking precision, reliability and corroboration from other sources. It is quite surprising that, in the age of big data, little is done to extract objective information from the software and hardware used in BIM.

The future of BIM

Even without stressing the limitations of BIM, it makes sense to consider the future of AECO computerization beyond this specific technology. As the rapid changes in digital successes and popular habits illustrate, no specific technology is guaranteed to remain dominant for long. Antecedent technologies pop up continuously and challenge the established ones, which frequently adapt in unexpected ways to survive. What we take for granted on our smartphones today may be obsolete next year. In AECO, development is not as fast for a variety of reasons, from the size of the overall market to the tendency to stick to existing conventions and the fragmented practices in different markets. It follows that any consideration of the future of AECO computerization must start from BIM but not be defined by it: in the short term to guide meaningful further development of BIM; in the long term to understand better what should come after BIM; and in the mid-term to invest wisely in the transition. Is BIM, for example, a sound basis for digital twins or the golden thread, as many assume? Moreover, from what we learn from BIM, are digital twins and the golden thread the future for AECO?

One of the first things to be considered is that commercial implementations of BIM, despite claims to disrupt, show a strong adherence to conventional and conceptual frameworks of both analogue AECO practices, including graphic representations like CAD. The way we use BIM is analogous to insisting that smartphones retain the form and interfaces of telephones of the 1970s, even though the technology and our use of smartphones are completely different. Should such questionable conformism be leading the future of AECO computerization? Or should computerization be a leading factor in attempts to improve AECO?

The adherence to convention is not without consequences with respect to performance: BIM becomes a means for mere incremental improvements, with a limited effect or appeal. It is undeniable, for example, that BIM produces improved material take-offs for cost estimation, but costs are then still estimated in the same old, inadequate ways, instead of utilizing the ability of BIM to represent explicitly the means and processes of production (e.g. having scaffolds and cranes as independent symbols rather than as mere coefficients of building elements that require them). Through such explicit representation one can produce more accurate, reliable and analytical projections that moreover bring together design, time planning and cost estimation.

Other consequences are lack of understanding of how BIM actually works, what it can do and what it still lacks, even though it may be of paramount importance, for example adequate DBMS facilities for the large quantities of information in a model [12]. Since its forceful entry in AECO computerization over a decade ago, BIM software has changed little, although the same period has seen substantial changes in the ways we process and interact with information. The user complaints about the lengthy and costly training required for BIM are not unrelated to that. Moreover, in contrast to the democratizing effect of other digital technologies, which bring new possibilities to previously disenfranchised sections of various societies, BIM clearly favours bigger organizations with resources they can be wasted in current BIM practices [1] – a far cry from the inclusive, collaborative world envisaged in BIM theory. Evidently, BIM is a huge investment in terms of ideology, knowledge, software and organization. Perhaps we need stronger theoretical evidence that it is practically possible.

BIM theory

One could question whether BIM theory is fully developed and sufficient for guiding software development and application. So far we have been discussing BIM primarily with respect to implementation, deployment and application: what the technology currently entails and how it is used. This, however, is only part of the story. One of the selling points the BIM community takes particular pride in is that this technology has a twin in a BIM theory that guides and explains what BIM is and how it works. This naturally poses the following question: what constitutes the corpus of BIM theory? Which texts and other information sources should one study to understand and learn BIM?

One publication that should obviously be included in this corpus is the influential and informative BIM Handbook [10]. The BIM Handbook describes BIM (modelling and workflows) rather practically, often in opposition or relation to other approaches or technologies (from 'traditional' approaches and CAD to IPD and lean construction). More chapters are more on what one should do with BIM software rather than what this software should do. This pragmatic view helps people deploy BIM but at the same time bounds BIM to what current implementations afford, as well as to its outputs in the framework of conventional tasks.

Another influential source is buildingSMART, "the neutral, international forum for initiating, developing, creating and adoption of open digital standards for BIM processes", including IFC, the main standard used for describing built assets; bsDD (formerly IFD), a standard for interpreting these descriptions; IDM, a standard for sharing information; and BCF, a standard for communication though annotation. As mentioned before, these standards remain attached to earlier interpretations of the domain of discourse, with classifications and definitions drawing largely from previous, pre-computer conventions. The underlying ontologies do not have a sound theoretical basis but seem to be a result of rather simplistic “system” analysis.

Despite the presence of competitors, these standards remain the foundation used by most developers, who increasingly call for their modernization, as testified by many discussions in buildingSMART's own forums. Interestingly, modernization requests are not limited to technical issues, such as automating the validation of IFC structures, use of more modern data schemata or abandoning the idea that data are organized in discrete files in favour of web-based workflows. They also extend to strategic suggestions like the decoupling of semantics from geometry, which arguably strikes at the very foundation of integration but nevertheless give a clear indication of the troubles caused by the incorporation of legacy elements in the structure of BIM.

The above suggests that BIM theory may be in transition, trying to be both a theory that enables the development of applications and a theory that explains preceding actions and their results. That action precedes theory is not uncommon. Roman engineering and Renaissance violin construction lacked appropriate and sufficient theories in physics but nevertheless achieved admirable feats. For physics these achievements became problems to be explained, not applications. In a similar vein, one could argue that the theory of BIM and AECO computerization in general can be stimulated not only by the failures but also by the feats of AECO, in terms of both products (remarkable buildings and other structures) and practices (the ability to deliver despite fragmentation, poor communication, inadequate specification etc.). Acknowledging BIM as a transitional technology can help the development of this theory but gives no solace to current users of the technology, especially when it is imposed on them by legislation.

It is also important to acknowledge that domain knowledge may not suffice as a source for this theory. Extensive contributions from computer and data science seem to be needed, so as to finally bring AECO computerization up to speed with wider current developments from which it can profit. This involves addressing issues such as IP and data protection in a fresh and unencumbered way. Such issues may be quite complex but falling back to pragmatic positions and maintaining what is customary or what users believe to be their rights does little to help AECO performance, let alone modernization. The resulting reciprocity of domain and computational aspects in the theory of AECO computerization could establish a wider domain basis on which digitization can be deployed more organically than with BIM. This theory should moreover take more pride in the history of AECO computerization, bypassing the polarization with CAD and making users and developers aware of the precedents on which BIM is founded.

Historical awareness can have a deep impact on the symbolic representations championed by BIM. Such representations describe the world in terms of things and their pairwise relations, which explains the enduring popularity of graphs in computer science. However, searching for the graph of symbols in a model makes apparent that BIM software not only has to become more consistent in the definition of its symbols but has yet to incorporate all relations (even though IFC provides for them). Some relations are cleverly implemented as behaviours, such as the hosting of openings in walls. Others are present but hidden from plain view, for example a door knows which two rooms it connects. Yet others are fuzzy and not always effective or reliable, such as the (co)termination of wall segments in neat corners and junctions, which is restricted by the persistence of the old, graphical ways in which the models are created and processed. BIM theory has yet to produce explicit means for describing its fundamental symbolic representation in a more formal manner that ensures coherence and consistency, e.g. as the dual graph of building elements and spaces that has been studied in AECO computerization since the late 1960s [6]. Parameterization is often presented as a way of adding relations between symbols but, although user-defined parameters are a powerful way of controlling a representation, they are no substitute for relations that should already be present and accessible to users, allowing them to understand a visualize e.g. a pedestrian route in a building as a subgraph of the spatial representation.

Finally, a sobering thought is that AECO as an industry is less driven by a technology and its theory and more by responses to the market, including software developers and resellers. Several characteristics of the state of the art in BIM are explainable primarily through market desires: they developed so that the tools will sell. BIM theory, as outlined in e.g. the BIM Handbook, stresses some drivers for the adoption of BIM, such as the cost of failures and the promise for higher efficiency. Should theory expand to include all key AECO activities in a way that fully reflects domain discussions, e.g. what facilities management actually does and the direction it is moving to? This would replicate theoretical work on various subjects but would also help reach out to practice and its daily realities, providing a fuller picture of both drivers and inhibitors for the adoption of new technologies.

One cannot escape the suspicion that in fact there is no real BIM theory beyond the simplistic idea that having more information has to be better and people communicating via a centralized exchange has to be better than a cacophony of peer-peer exchanges. What would be candidates for BIM theory —work done by various researchers into design digitization— is hardly translated into the schematics behind IFC if at all.

Discussion

The levels on which BIM can be discussed are connected to each other but not always in a straightforward top-down hierarchy: BIM theory prescribes how the tools should be used but is also bounded by them, as well as entrenched in legacy practices in application. Similarly, the new tools (software, procedures, conventions etc.) are dictated by both the theory and these legacy practices. This reciprocity may be useful for BIM deployment but at the same time remains a source of unnecessary limitations. As suggested above, there is room for improvement at each level, if not for rejecting some of the tenets of BIM. The same holds for the connections between levels, which require more attention to become truly transparent.

BIM points the way to the future of AECO computerization, but BIM should not be considered the goal. We should learn from BIM and move on in theoretically as well as practically more innovative ways. Assuming that what we do today with BIM suffices as a foundation for e.g. digital twins and connections with the IoT may be misguided. Similarly, imposing current BIM tools and approaches on practice is not the priority. On the contrary, we should learn from clashes and obstacles in BIM deployment and application to understand better where practice should improve and direct research and development effort in means that directly address these improvement areas.

Back to our question at the start, how do we unlock the potential of BIM? We suggest that questions raised above and questions elicited by them can be organized in four themes (Table 1):

  • 1. BIM theory: is there such a thing? Does it have any weaknesses or unrealised opportunities? Does tracing its historical background back to the 1960s help us prepare for the future?

  • 2. Implementations (software, standards, conventions): how do they perform? Are they true to the theory? How aligned are they?

  • 3. View from practice: the users’ perspective across AECO professions, towards clear specifications of what projects, disciplines and individuals require

  • 4. Legislation and policies about BIM: do they modernise AECO or do they amount to a push without forethought?

Table 1 Four themes for further research into BIM
Full size table