BIM, Revit, and the Database Dream
Despite being perceived as a traditional, unchanging industry, construction isn’t immune from the hype of some new technology or idea that’s poised to revolutionize the industry. In some ways, it’s actually worse in construction - because construction processes change so slowly, the hype cycle gets stretched out, and something can be the next big thing for years or even decades. Prefabrication and mass timber are two examples; BIM (Building Information Modeling) is another. A little bit of searching will yield approximately 100,000 articles about how BIM is the future of construction, stretching back to the early 2000s.
Despite-slash-because of the hype around it, it’s often very hard to untangle exactly what BIM lets you accomplish. Like with any piece of technology, popular descriptions of BIM are usually non-technical, and tend to devolve into amorphous abstractions. Autodesk describes BIM as “the holistic process of creating and managing information for a built asset”, and that “BIM integrates structured, multi-disciplinary data to produce a digital representation of an asset”. Trimble describes it as “a process of collaboration facilitated by digital technology” and that a BIM model “includes details of performance characteristics, specifications, and other non-physical data embedded in a shared 3D digital model of the project”.
Peeling back the buzzwords, we get BIM as the process of creating a digital model of the building. This often gets rounded off to “designing a building with 3D modeling tools” - whereas mechanical engineers design things with 3D modeling tools like Solidworks or Fusion, building engineers design things with 3D modeling tools like Revit or Tekla - simple!
But this conception of BIM is slightly off the mark, and misses the problem BIM was created to try to solve. To really understand BIM, we need to look at the history of how building information has been represented and communicated.
A brief history of building information
A building is typically designed by a team of architects and engineers, and then handed off to a team of contractors who will do the actual building. Because the people building it aren’t the people who designed it (and because the design team may in fact be many independent groups), designers need a way to communicate their intent to the rest of the project team - to make it clear what, exactly, should be built.
Traditionally, this was done via hand-drawn blueprints - drawings which combined a graphical representation of the building (drawings showing the floorplans, elevations, location of the various elements) and text annotations. A drawing of the foundations might show where they needed to be located and how big they should be, and have labels indicating the concrete strength, the type of reinforcing needed, how to prepare the ground prior to pouring the concrete, and so on.
As buildings became more complex, different aspects of the building would be drawn by different disciplines - one set of drawings would show the mechanical systems, one would show the structural systems, and so on. To coordinate between the different disciplines (and increasingly complex architectural drawings), drawings would be created using a layered approach. Each drawing sheet would show one aspect of the building, and these could be layered on top of each other, either by printing them on clear Mylar sheets, or using something like a light-table, making it possible to pick and choose which aspects of the building you wanted to see.
In the 1980s, hand-drafting began to be replaced by computer drafting (the first version of AutoCAD was released in 1982). AutoCAD and other CAD tools digitized the previous paper-based process - your drawing sheets now existed in a computer file instead of as an actual sheet of paper. Drawing files were a collection of geometry - a series of lines, curves, shapes, and text, that could be assigned to different layers, and which could be turned off and on within a drawing file.
This greatly simplified the process of drawing creation (though like with any construction technology, it took a surprisingly long time to displace its predecessor), but information was still represented and communicated purely visually - you were still creating a set of drawings that would ultimately be printed out and read by the contractor. If you drew a wall, the software didn’t “know” it was a wall - all it saw was a collection of linework attached to a particular layer.
Early building information research
In parallel with the development of computer-based drafting systems, there were also CAD systems being developed that were designed to manipulate building information directly. Instead of software based around manipulating geometry (points, lines, etc.), like traditional CAD tools, these “building modeling” systems were based around the concept of structured data objects - with these sorts of tools, a wall wouldn’t just be a collection of lines, it would be a digital object that contained geometric information (size, extents, etc.) but also other information such as cost, material properties thermal properties, as well as rules for interacting with other building elements.
An example of these early efforts is the SSHA system, which began to be developed as far back as 1969. In the SSHA system, a building would be assembled from various data primitives that had geometric information, cost data, material properties, rules for combining them, etc. It had some surprisingly advanced features given for the time - it was capable of automatically producing joist layouts, and automatically calculating the amount of natural light at a location based on glazing locations.
These systems were focused on the problem of knowledge representation - figuring out how to use the capabilities of digital computers to store information in a useful way. Both GLIDE II and CAEDS were first and foremost databases that the user could interact with via specially designed languages to produce building specifications. The goal was to have a single building “model” - a central repository of all building information that could be accessed, viewed, and manipulated in various ways depending on the task at hand. These efforts drew heavily from other work on computer-based information structuring, such as object-oriented programming/databases, type checking, and expert systems.
This concern about information structuring makes sense given how many thorny information problems building design entails:
The information describing a building is built up gradually, by many different people at many different times, who may or may not be able to interact with each other.
Each discipline only needs/accesses a portion of the information, but their decisions impact all the other disciplines in ways that are not always obvious (if I specify a metal strap, that may prevent the electrician from drilling through the stud to run their wiring).
Coupling between different disciplines means that the design process is fundamentally iterative; for instance, the architect’s space plan affects the structural systems, but the structural systems chosen affect what sort of space plans are feasible. Any information structure thus needs to be flexible enough to accommodate significant changes, complex dependencies, and recursive relationships.
Building information is most naturally structured hierarchically (a building contains rooms, which contain walls, which contain wall studs, etc.), but different users and trades will construct different hierarchies which won’t map cleanly onto each other. An HVAC design will break the building down into different air volumes, a structural lateral design will break it down into shear tributary areas, etc.
Much of the information in a building isn’t specified directly, but instead exists as craft expertise or traditions of practice. The architectural drawings don’t indicate where exactly each sheet of drywall needs to be placed, for instance - it’s up to the site crews to figure it out.
The thing that buildings create, usable space, isn’t constructed directly, but exists between the building elements.
These problems influenced the way modeling of building information developed - for instance, a great deal of effort was expended on figuring out “views” - ways of accessing only the information that was relevant to the task at hand, similar to how the you could overlay just the drawing sheets that you cared about in the layer-based approach.
Most of these systems remained niche or as purely academic projects, but over time commercial CAD software added capabilities for manipulating building information. AutoCAD eventually added “object CAD” features, where geometric elements could have additional building data attached to them. Pro/Engineer, a constraint based parametric mechanical design program, was released in 1988. SONATA, and its successor REfLEX (later Pro/Reflex) were building modeling programs in the late 80s/early 90s inspired by the C++ programming language, and which allowed for user-created data objects.
An early example of the potential of building design based on digital models comes from Frank Gehry (ironic, as Gehry apparently does not know how to use a computer). Gehry is famous for extraordinarily complex building exteriors, with lots of sweeping curves and few straight lines. Because his buildings were so different from standard construction practice, Gehry had difficulty dealing with contractors, who had trouble even pricing, much less building, the complex shapes, and he was often forced to compromise his designs in the name of constructability
To address this problem, in the 1990s Gehry’s firm turned to CATIA, a 3D modeling software originally built for the aerospace industry. Using CATIA, a very precise digital model was created of the building, which could then be optimized for cost (flat surfaces are cheap, single- and double-curves are expensive, so break the building into as many flat surfaces as possible). The model could then be used to generate a construction sequence, so contractors could see exactly how the building needed to be assembled. The result was that previously unconstructable designs could have their costs predicted extremely accurately, enabling the construction of buildings that might otherwise be impossible to create. This effort would ultimately be spun off into a separate company, Gehry Technologies (later acquired by Trimble).
The era of BIM
In the late 90s, these trends towards modeling buildings out of structured data objects would finally gain traction.
In 1994, Autodesk, in concert with several other building software companies, began developing “Industry Foundation Classes” (IFC), a set of standard C++ classes that would allow for data exchange between different AEC software. In 1997 it was reconstituted as a nonprofit, with the goal of defining a standard way of structuring building data and relationships. IFC theoretically allows different pieces of software to work on the same building model by exchanging IFC data. Today most BIM and AEC design software is capable of importing and exporting IFC files.
In 1997, several PTC engineers would leave to start Charles River Software, and create the first version of Revit. Revit was developed as a software for architectural design, and designed to overcome the many limitations of 2D CAD-based drawing creation.
In software such as AutoCAD, architectural drawings consisted of dozens of drawing files, each one a collection of lines, shapes, text, etc. Any change that occurred in one location (such as changing a wall type) would often need to be made in many other locations, a time consuming and error-prone process. In Revit, on the other hand, drawings were generated by creating a 3D model of the building, which could then be used to generate all the necessary drawing views. Instead of a huge collection of drawing sheets, section cuts, elevations and details which were all independent from each other, in Revit changes to the model would automatically propagate to the different elevations, section cuts, plan blow-ups, etc.
Revit was heavily influenced by the previous structured data building modeling applications (there is apparently a dispute between the founders of Revit and the designer of Reflex, regarding whether Revit was based on copied Reflex code). Buildings were assembled, not from simple geometric primitives (like most 3D modelers), but from structured data objects known as “families”. Families contained geometric data about the object in question (size, thickness, etc.) but could also include any other data the family creator wanted to include - an HVAC family might include a 3D model of a cooling unit, as well as cooling capacity, weight, manufacturer, and a link to the manufacturer’s website. Revit came with several built-in families (such as walls and windows), and allowed the user to create their own. Previous software for modeling building data, such as Reflex, required the designer to use complex programming languages to define the data objects. Revit, on the other hand, was designed to be as simple and intuitive as possible, and allowed the creation of families using drop-down menus and a simple point-and-click interface. Rather than a 3D modeler, Revit was occasionally referred to as a visual programming environment, a way of creating a building information database through a user-friendly interface.
In 2002, Autodesk acquired Revit. Their whitepaper outlining their BIM strategy remains one of the clearest explanations of what the goal of BIM is - to move from a drawing- and document-based information workflow, to one where all information about a building is stored and managed via a central database. Rather than a simple 3D modeling tool (“3D” does not appear a single time in the whitepaper; “database” occurs 23 times), BIM was intended to be a radical rethinking of how construction information was interacted with.
Where we are today
So did we get the BIM revolution that we were promised?
In a certain sense, yes. Today, Revit is everywhere in the AEC industry - somewhere around 80% of architects and engineers model their buildings in Revit, and buildings are generally designed by interacting with a shared model of the building, which allows things like clash detection. IFC (now under the purview of buildingSMART) continues to be updated, and most AEC design software supports import and export of IFC files, allowing different users with different software to all (theoretically) manipulate the same data model.
However, like so many other things in construction, the technology has made inroads in a way that doesn’t disrupt the overall process. Revit, and BIM in general, exist in a context where drawings and documents - information communicated visually - is still the primary method of information management on a construction project. Revit’s building information database is still used to generate a 2D set of non-changing drawings, and it’s these drawings that get submitted to the permitting office, get used on-site by the construction crews to put up the building, etc. And in practice, much of the data in a Revit file often consists of 2D drafting views that are essentially simple sketches, unconnected from the building model.
There’s also a huge amount of building information that gets created and manipulated entirely outside of Revit. Specifications, RFIs, shop drawings, and engineering calculations are all generally disconnected from any sort of BIM workflow.
If anything, the drawing and document workflow is becoming more entrenched, thanks to software tools that make it easier to handle the relentless flow of PDFs on a construction project. Tools like Bluebeam and Procore are built for streamlining construction information management, but are entirely predicated on a document-based workflow - Bluebeam is a fancy PDF reader with a lot of construction-specific features (like calculating areas, and letting multiple people markup the same document) and Procore is a project management tool for storing and distributing construction documents (i.e.: PDFs).
In a truly BIM-based world, where information was entirely managed by collaborating on one central database, there would be no place for this sort of document management software. But tools like this are ubiquitous, used by nearly every contractor, architect, and engineer.
We can also see the incomplete adoption of BIM in the rise of other, similar buzzwords that fill in the gaps left by BIM. VDC, “virtual design and construction” is another term that’s hard to pin down, but is basically the creation of a very accurate building model by the contractor, that’s used as an aid to the construction project. “Single Source of Truth” is a term you’ll sometimes hear on particularly complex projects, where the project is arranged so all the information gets generated from a single source - exactly what BIM was intended to be (bizarrely, a blog on Autodesk’s website has an entire article on Single Source of Truth that doesn’t mention BIM once).
What stopped BIM from taking hold completely?
Why hasn’t BIM managed to replace document-based information management? There’s a few factors at work.
Part of it is due to permitting requirements - as long as building departments require submissions to be in the form of 2D drawings (typically PDFs, but some departments still require actual paper drawings), moving away from them will be an uphill climb.
Part of it is due to software limitations. A combination of first mover advantage and strong network effects meant that BIM in many ways became synonymous with Revit, and Revit lacks features that would make it suitable for a TRULY centralized building database - it has trouble modeling some building elements at the required level of detail (such as stud walls), it lacks good ways of storing purely text-based information, it has poor tools for version control or tracking how information changes over time, it has serious compatibility issues (buildings created in one version of Revit can’t be opened in previous versions, and it’s not uncommon for designers to have 5 or 6 versions of Revit installed) - the list goes on.
There are limitations in IFC as well. It has not always handled parametric data well, and in general does not export or import data with 100% fidelity, making it difficult to use as a centralized information store.
And there are coordination costs of getting multiple parties to agree on how information should be exchanged. Buildings tend to be constructed by a different project team every time - using a central database means devoting significant time and effort to getting everyone on the same page for how data should be exchanged. The one-off nature of construction projects pushes against spending this effort, though this is likely something that could be addressed with better, more capable software.
There are also some fundamental drawbacks to using a database as the way building information is managed.
For one, a truly complete database of building information requires an enormous amount of effort to create. Even a medium-sized building might have hundreds of thousands of parts, hundreds of different specifications and standards, and an endless number of parameters to specify. Specifying all that up front would be an enormous amount of work, and also require a massive amount of ongoing maintenance to ensure that it stayed up to date. Most design professionals learn quickly to purge their drawings of unnecessary details and elements in the name of expediency and maintainability - every element you put on your drawings needs to be coordinated with every other element; every new detail is a potential error attack surface. This hasn’t changed with BIM. For buildings based on well-established construction methods and techniques, the effort to create and maintain the information in your database could easily exceed the value you can extract from it. (In practice, BIM-heavy projects tend to be large, complex ones where the cost of coordination failure makes creating and managing this information store worth it.)
For another, a database of structured information is useful for communicating with a machine, but it’s a restrictive way of mediating communication between people.
Communicating intent via drawings and text provides infinite degrees of freedom - a drawing can be any possible arrangement of lines and shapes that I think will get my point across most effectively. And that drawing can be created and transmitted using any number of possible tools - I can create it in Revit and upload it to BIM360, I can draw it in CAD and send it via email, I can sketch something on a notepad and text a picture of it (I’ve sent drawings all these ways and more).
A structured database, on the other hand, is naturally much more constricting - I’m forced to figure out how to arrange the information I want to send in a way that the database understands, and the person on the other end must do the same. And since any construction information will bottom out with a person on the jobsite performing some task, in practice this tends to simply add a layer of communication overhead rather than simplifying the process. With drawings, on the other hand, there's almost zero barrier between thinking of information and communicating it.
The Future of BIM
This suggests that BIM will become more prevalent as machines take a greater role in the construction process.
Of the various technologies with the potential to do this (prefabrication, on-site robots, etc.) I think the one likely to have the greatest effect is AR/VR. This has such obvious construction potential that it seems impossible that it won’t become ubiquitous on jobsites, and thus require the creation of much more robust building data models. As AR/VR comes down in price and gains capabilities, we may see it pull forward BIM adoption.
(Thanks to Jeffrey McGrew for the initial discussion which led to this article).
Feel free to contact me!