A Concise History of Data in the AEC Industry: Part 2

Introduction

In Part 1, we introduced the three main eras of data in the history of the built environment.  This period spanned the majority of the time of our species’ existence, from the neolithic era up until roughly the 1970’s.  Here’s a quick recap of the journey so far:

At the end of the Analogue Era, we predominantly used marks on pieces of paper as the data medium for representing our built environment.  What’s more, the world was growing more complex and buildings and cities were following suit.  The invention and proliferation of electricity into our lives took the built environment into a new domain of complexity as now we were not just storing data for brick and mortar structures, roads, and bridges, but rather, collections of serviced spaces which needed the input of a new breed of expertise in the building services engineer.  This didn’t necessarily change the type of data that was being transmitted or where it was stored (still just marks on paper), but rather, it increased the amount of data needed to describe the built environment before it was built.  The amount of data was solely multiplied by increasing the number of parties needed for the creation of the built environment.

Just to refresh your memories of where we left off, recall the three predominant era’s of data in the design of the built environment are:

• Analogue Era (100,000BCE – 1990’s)
• Digital Era Part 1 (1990’s – 2000’s)
• Digital Era Part 2 (2000’s – Present)

In this Part 2 of the discussion, we will introduce the Digital Era Part 1, which can be divided into two predominant parts:

1. The Building Drawer 2.0:  Draw a Picture of the Thing (on digital paper)
2. The Building Modeler 1.0:  Model the Thing in the Computer

Before we start, it can’t go without saying that if you want a good, in-depth history of the digitization of the data used to create the built environment, Builders of the Vision is a must read and some of the information I’ll be presenting here was inspired by this excellent book.

The Building Drawer 2.0:  Draw a Picture of the Thing (on digital paper)

In the 1970’s, the world began to change with the advent of computers.  It didn’t take long for computers to enter into the paradigm of creating marks on paper with Computer Aided Drafting (CAD) being invented at MIT as part of research for the United States Air Force.  It took a few decades for this technology to proliferate into the industry however, but by the 90s, software like AutoCAD and Microstation were developed enough to be common place in any design office.  These software allowed for the creation of drawings in digital space, which allowed for the relatively rapid creation of drawings.  As opposed to the previous era, now doing something like offsetting a line was as easy as a couple of clicks and it was the same time to offset the line 1, 10, 100, or even 1000 times.  The scalability of the digital age had made its way to the AEC industry.

So as can be seen above, the first steps the AEC industry took into the digital era was to digitize their status-quo processes which manifested itself as the ability to create drawings quicker and faster.  As far as our three main questions for this era:

• Data:  Digital geometrical objects
• Who generated the data: Architects/Engineers/Draftsmen/(Software Company)
• How was data transmitted to reality: Giving drawings over to construction people to copy into reality

A key difference that also entered in this era was the idea of a Graphical User Interface (GUI) as the main medium by which the designer created and controlled their data.  This GUI represented very clearly the addition of one level of separation between the designer and the data that ultimately represented the thing being created.  Before, if you created something, there was just you, a pencil, paper, and marks on that paper.  Now, there was you, a digital pencil (mouse and keyboard), paper (the GUI), and digital marks on that paper which could be printed to arrive at the same output from the previous analogue era.  The subtle, yet key difference that had entered here was the fact that now a software company was an invisible co-creator of the data in the sense that they created the digital paper and ink to be used by designers.  They completely owned the GUI (paper) as well as the definition of the geometric objects (ink) which the designer would place via that GUI.

The Building Modeler 1.0:  Model the Thing in the Computer

Up until now, the trend in creating things in the built environment (or otherwise) was to literally ‘start on paper’ and represent ideas using geometry.  There are two main limitations to this.  First, given that paper is a 2-Dimensional (2D) medium and most of the stuff we create is 3-Dimensional (3D), it meant translating a 3D idea to 2D using a common vernacular such that somebody else could translate the 2D drawing to a 3D reality.  Second, the stuff we create is not only 3D geometrical objects.  Rather, they are objects which have 3D geometry and also other properties.  Therefore, representing these objects as solely geometry precludes the need for the final objects other properties to be portrayed in some way.  In previous era’s, this usually manifested itself as drawing the geometry of an object in 2D and annotating or supplementing that picture with the other relevant properties, such as in the example drawing below:

Regardless of if this is handled in a digital or analogue fashion, the fact remains the same – the drawing becomes a database of unassociated geometry (yellow above), text (blue above), and numbers (orange above) which together defines the objects that are to be created.  The fact that they all come together as marks on a digital piece of paper requires a human designer to place each of them individually and assure they are associated properly.  Each digital object itself is ‘dumb’ in the sense it only exists, not having any digital relationship to any other object.

In the next era, the idea would be to solve the unassociated aspect of using drawings as a database for information by modelling the object as it will be in reality, but in digital space.  This is what is known as Building Information Modelling, or BIM, which if you have been anywhere in the AEC industry since the mid-2000’s, you would know has been the main buzz word for over a decade now.  Given all the hype, it’s important to remind everyone that the original idea of BIM was exactly what we just described – modelling the object to be created, not just drawing it.  Therefore, although most people when they think of BIM tend to think of Revit or another proprietary product, the pure definition of BIM has nothing to do with software, but rather, how the data that represents the object is stored.

Working in this way presents a few immediate benefits. The adoption of BIM (again, don’t just think Revit) meant that designers could still create drawings which still represented the common vernacular of the AEC industry, but the key difference with BIM would be that those drawings would be a byproduct of a model of associated data.  This meant that the geometrical and textual marks on digital paper from the previous era, whilst looking exactly the same, would be digitally linked behind the scenes as they both emanated from the same digital object, meaning the system eliminated one of the main pitfalls of the previous era of disassociated data which represented one object.

Another key benefit was modelling objects as they would be in reality precluded the need for a 3D model to be created.  Again, another misconception of BIM is that its purpose is to model the building/city/sewer system in 3D.  This is a myopic view – the purpose is to model the building/city/sewer system as it will be.  The building/city/sewer system happens to be in 3D and by modelling it as it will be, you should be creating something that is digital and 3-Dimensional.  There is a key benefit however to having a 3D model from a clarity perspective – it’s literally a whole new dimension of information!  Having a 3D model allows for you to literally take a digital tour of the project you are creating and pick out issues which are not readily apparent when using only 2D representations of the project.  Another benefit to working this way was that the information was now structured in a way that lent itself very well to being organized in a database system, allowing for digital management of data.  Now that the data the represented the object to be created was in a structured digital format, it could be stored and queried much easier than before.  But this post isn’t about the pro’s and con’s of BIM and we won’t get into 2D, 3D, or whatever-D BIM here.  We are after understanding ultimately how this new era approached data versus previous eras:

• Data:  Digital Objects which represent the ultimate object’s properties – geometrical, numerical, and textual data included.
• Who generated the data: Architects/Engineers/Draftsmen/(Software Company)
• How was data transmitted to reality: Convert model into drawings and hand over to construction people to copy into reality

The key change in this era from a data perspective is that more and more information is being created via a Software Companies GUI and using the software companies digital definitions and/or templates for digital objects.  And for the most part, this era inherited the vernacular of the previous era such that now there is a model of the building as well as a 2D representation of that model which must be created as it still will represent, for the most part, contractually the thing before it is built.

Conclusion

In the figure above, we can see the key changes of this era of data in the AEC industry.

Key Changes for this era include:

• Software Companies as Co-Designers
  • They are the ones who define the digital definitions of objects which designers use to portray designs
• Speed at which data can be created
  • Just as easy now to create 1000 digital objects as it is 1 or 2
• Levels of Detail
  • Now that its easy to create data, its expected to provide that data
• Fragmentation of Industry Based on Specialism as well as Software
  • More and more specialism beget more and more software specifically tailored for each speciality

It’s important now to make a point about the amount of data that is being generated in each era.  I remember when I was a grad student at MIT going to a seminar run by John Ochsendorf (who would become my thesis professor) at the Boston Public Library celebrating the works of Rafael Guastavino.  In a picture frame on the wall was this drawing which as about A0 size:

I specifically remember John specifically telling me something to the effect of “Pay attention to that drawing.  This is all the detail that used to be created by the designer”.  One drawing, that was it.  Let’s take this drawing, which would have been created during the somewhere between the Master Builder and Building Drawer 1.0 era as a standard unit of data.  This drawing in .jpg format contains about 0.5MB of data.  If we consider that going forward each new discipline will contribute 1 or two drawing each, that will mean that the total data needed to describe the object to be created will be about 2-5MB.  Let us assume that once we enter the CAD era, each discipline creates over 10 drawings each, leading to about 50MB of information created to describe the object to be created.  And finally, in the BIM era, its common to make a Revit model to host all the objects that represent the project. Whilst there doesn’t seem to be an official number on the maximum size of a Revit model, my experience has shown that one Revit model can get up to about 200-300MB of information before starting to get a bit laggy.  Given 3 or 4 parties, that gets you up to about 500MB of data which describes the project:

Now, this graphic is admittedly not so scientific, however, the key here is to understand that as we go through time, more data created is increasing exponentially – hence the need for a logarithmic y-axis on the graph above.  Given the abundance and power of data, we now can see in the graphic above that even the construction personnel have their own software’s for the creating to data the suits their specific jobs (i.e. modelling to a higher level of development and creation of shop drawings).

So post, we have seen an explosion of data given the relative ease to create this data.  However, its creation is still very much directly tied to an analogue interface, i.e. how fast a human can type/click to create objects in the machine.  Equally, we see a fragmentation of not only where data exists, but also, what are the digital definitions of objects.  One object in the project may have a number of discipline stakeholders, each of them representing that object digitally using their software of choice.  Each of those softwares have coded a certain digital vernacular which defines objects by which designers can use to construct their own project.  This means that now one object which will be created is represented in many digital forms, across many different software platforms and disciplines.

In the next era, we will see a key change in terms of who takes responsibility for the digital definitions of objects as well as the digital vernacular used to describe an object.