Business benefits of openBIM

Communicating the business benefits of openBIM is difficult.

We’re up against armies of marketers from large corporations with multi-million pound budgets to lobby and appeal to the major industry players, as well as to spread Fear, Uncertainty, and Doubt about alternatives that could hurt their bottom line.

Unfortunately believing and following the big monopolistic companies is often the default safe bet for IT and digital departments, after all “Nobody gets fired for buying IBM“.

This post is my attempt to summarise the business benefits of adopting openBIM as a construction business’s underlying digital strategy. The benefits are split into the following three areas.

  1. Flexibility, choosing from many options
  2. Agility, being able to change
  3. Stability, keeping consistency


Sticking to solutions from just one company gives you a small box to work within, there are generally limited options and you will end up changing your process to fit the tool rather than the other way around.

Adopting openBIM doesn’t mean you can’t continue using your existing favourite software but it does increase your available options, and it allows you to always choose the best tool for the job.

If software suppliers know that you do not have any flexibility or little to no options, it gives them tremendous power to dictate cost and quality to you.

By adopting openBIM formats you are showing them that you have a wide choice of suppliers and they will have to work hard to get your money, driving competition and innovation.


Once you decide to use a single company’s platform or tool you are effectively locked in.

And you can do all the due diligence in the world and be 100% certain they have the best tools for the job at the time of deciding, but what happens if in 12 months time things aren’t as good as they first appeared and competitors with better solutions start to enter the market? Bad luck, you’re stuck with the initial decision and their proprietary solutions you can’t easily escape from. The cost of change would be very significant.

(My favourite example of this is the cutting edge UK Navy aircraft carrier powered by Windows XP. That project clearly had no room for agility and to change as new developments occured.)

However, if you adopt openBIM as your underlying strategy the cost of change is vastly decreased. All your data will be highly compatible with IFC so you will be able to easily open your existing data in new systems with minimal migration costs.

openBIM also reduces dependancies. You can upgrade your software to take advantages of new features without having to wait for others to also upgrade theirs (if they ever do).

The costs will never be zero because even little changes always cost money for businesses, but the cost will be reduced and the ability to react to technological advances can a key competitive advantage.


In this age of rapid technological change it would be a fool who tried to predict or plan how we’re going to be working in just a couple of years time.

So how does a company create a medium or long term digital strategy needed for investment decisions?

The answer is to not standardise around something as temporary and ephemeral as a tool or a platform, but to standardise around data structures. And openBIM provides the best data structures to do this with.

To be clear, we want tools and platforms to rapidly evolve and to help improve our efficiency, but the underlying data should be far more stable.

If the fundemental underlying data structures keep changing, say by changing file formats every year, then that can cause huge legacy and compatibility difficulties. For example, if you build a tool around a proprietary piece of software it can become a sunk cost which works against change. If your tools are based on underlying standard data they’ll have a greater life span and Return On Investment.

openBIM provides stable and comprehensive data structures you can base your construction data on.

With openBIM you can chop and change and overhaul your tools and processes frequently but maintain a stable foundation of a standard data structure.


If this blog post is too long for an elevator pitch to the CEO, here’s my attempt to boil the business benefits of openBIM down to a single snappy sentence:

Adopting openBIM gives a business the flexibility to choose the best tool for the job, the agility to change tools, and the stability to make long term decisions.


GUIDs are the key

In my previous post, The impossible problem of naming things, I mentioned how GUIDs are a great way to make a document unique. In fact, they are a great reference for any thing in construction and can form the backbone of integrated systems. But first…

What is a GUID?

A Globally Unique IDentifier (GUID) is a 128 bit random integer.

Sometimes pronounced “GOO-IDD” or refered to as Universally Unique IDentifier (UUID).

In layman’s terms, a bit is a 1 or 0 so a GUID is a list of 128 1s and 0s. A full example would be:


This is in binary (base 2). If converted to the more familiar decimal (base 10) that we use in everyday life the number would look similar to:


Which is a staggeringly large number. This is still a very awkward way of writing this number so for convinience sake it is often displayed as hexadecimal (base 16) and formatted into groups of 8, 4, 4, 4, and 12 characters, like below:


GUIDs are used extensively in all sorts of databases and data environment and the above may have a familiar looking structure.

In IFC the GUID (under the attribute name GlobalId) is converted to base 64 which looks like this:


What’s important is that all these are the same underlying random number.

Note: The hexadecimal (base 16) version is not case sensative, but the IFC base 64 version is. Some software, such as Navisworks, Excel, and SQL Server have search functions that are not always case sensative so may pick up the wrong IFC GUID.

There is a specification that details how to generate these random numbers, but that is way beyond the scope of this blog post.

Phew! That’s a enough geeky computer science for now, let’s get back to construction…

Back to Reality

One of the biggest differences between BIM tools like Revit, ArchiCAD, and Tekla and the traditional CAD software is the idea that you’re modelling actual objects and we can create links, references, and constraints.

That’s all well and good when the object is within one piece of software only, but increasingly this is not the case.

And despite all the marketing, no tool or platform is suitable for everything. Inevitably data about a particular object will get spread across many pieces of software.

The challenge then becomes, how do we connect together objects between each software?

For example, we have a 3D model with a piece of rebar in it. Often this is all anyone thinks about when it comes to BIM. The 3D model describes its geometry and some specification properties. But let’s have a think where else that rebar is actually referenced…

  1. Project plan
  2. Procurement
  3. Accounts and finance
  4. Delivery management
  5. Cost analysis
  6. Employee work time tracking
  7. Manufacturing traceability
  8. On site material tracking
  9. Fabrication models
  10. Structural analysis
  11. Environmental impact
  12. Quality records
  13. O&M documents
  14. Productivity tracking

How are on earth are we going to be able to track a simple piece of rebar through all those systems and integrate the data together?

What we need is a common and constant way to refer to objects.

Traditionally tags, marks, or ref with values like “R01” for Radiator 01, or recently more sophisticated values such as 01-Z1-55-UR-01 have been used. However, as previously discussed naming things is incredibly difficult. And it’s very possible the tag for a particular object may change at some point.

This is where GUIDs come in!

When an object is created it should have a GUID assigned. This GUID will be the only attribute that we can garauntee to be effectively 100% unique and constant throughout the life cycle of that object.

When integrating systems to create tools or data analytics, you would use the GUID as your common value (primary key) between multiple systems.

To extend the golden thread metaphor then surely the GUIDs are the sewing needles that tie the data together.

Streamlining IFC

With previous new IFC versions there has been much celebration on how many new entities have been added and how large and comprehensive IFC now is (an astonishing 776 classes and counting).

But if it isn’t already, there is a serious danger of IFC becoming bloated.

Rather than extending, I think now is the right time to be talking about streamlining and modernising the fundamentals of the standard to improve the ease of implementation and accessibility into the future.

Here are some ideas based on practical usage experience.

Remove all property sets

Currently IFC is a schema (entities and attributes) and property sets. I believe IFC would be much stronger if it was schema only.

While a schema can be universally adopted across every project in the world, the properties can change completely depending on client requirements and project specific processes.

I would remove all predefined property sets (like Pset_SanitaryTerminalTypeCommon) because compared to the schema, they add relatively little value.

This would be a good first step to slimming down and focusing on the IFC schema.

Properties are very important, but should be handled by an entirely separate standard, such as the buildingSMART Data Dictionary.

Remove the ‘Ifc’ prefix from all entities

A simple one, but it is incredible how much more readable and clear the standard becomes once the ‘Ifc’ prefix is removed. A wall should be a Wall, not an IfcWall.

Clean up the inheritance tree

(The following are based on IFC4add2, but the same applies to most versions)

Microsoft advises that having classes with more than 4 levels of inheritance is bad design and “can be difficult to follow, understand, and maintain”.

The IFC specification has 353 classes that are 5 or more levels deep, of those an incredible 117 are 9 levels deep!

Having that many layers of abstraction is incredibly excessive. Just because some entities share attributes doesn’t mean a parent class should be created at the expense of readability.

As a start, Relationships can be removed from the main Rooted tree. A relationship does not really need a name, description, or owner history. It is debatable whether they even need a GlobalId.

I also don’t think anyone could convincingly argue that nearly 50 different classes are required to meaningfully represent relationships and remain easily implementable.

Remove IfcPropertySets from the rooted tree too and then IfcObject and IfcTypeObject can be the new top level entities. This reduces the maximum inheritance to 7, which is still extremely high!

A single IfcPropertySet class

The property set concept of a list of name-value pairs is very simple and highly universal. There’s no need for all the predefined sets, including quantity sets, and templates. I’m certain a single IfcPropertySet class would be sufficient for 99% of use cases and also does not need to inherit from Root.

Remove Base64 GlobalIds

It is for purely historical storage reasons that IFC uses GUIDs converted to Base64 using a unique character mapping scheme. The amount of space that it saves in the modern IT environment is nothing.

GlobalIds should now be in the standard Base16 format so that more existing software libraries can read, process, and create them, rather than requiring a custom algorithm.

Scrap the ISO10303 support

Currently there is an XSD and a ISO10303 EXPRESS schema definitions. Rather than continue with such an outdated and unsupported format, the EXPRESS schema should be scrapped with the focus on the XSD schema definition that is far easier to develop against. I’m aware that there are some aspects that can’t be specified in XSD, but if thousands of other formats can be specified using just XSD, then I don’t believe IFC is so special as to be an exception.

Because the STEP file format has relatively very few tools supporting it, IFC in XML format and zipped should be the only format recognised by buildingSMART.

A zipped XML file is the standard approach for all Open Office and Microsoft Office files and should be more than sufficient.


The aim of this blog post  is to encourage people to consider streamlining the IFC standard to make it easier to use, understand, and implement by everyone.

These are just a few ideas to get things rolling, and I’ve not even mentioned issues like the complexity of interpreting IFC geometry and possible improvements to how it’s documented.

If you have any ideas please free to add them below.

The impossible problem of naming things

Is there any situation more socially awkward than not knowing someone’s name and having to describe them to someone else?

“Erm, you know that tall guy? Kinda slim? Talks fast? Short brown hair? In the engineering department?”

Even deciding what attributes to use to describe them is fraught with difficulties.

And in Building Information Modelling is there anything more contentious than how to name something?

No system ever seems to satisfy everyone’s requirements. The British Standard, Publicly Available Standard, and International Standard documents do a good job but they’re far from perfect. Whether it’s zone, document type, or classification system, there’s always some part of it that just doesn’t seem to work properly for users.

Files, library objects, layers, instances of objects, and even classification systems themselves suffer from this problem.


Why is it so difficult to name things?

Many decry “dinosaurs” who don’t want to change, or the standards bodies that don’t know about the real world, or simply poor implementation.

But I believe it is because of the unresolvable conflicts between human needs and information management needs.

Humans need names to be readable, simple, understandable, and easy to remember. For information management we need names to be easy to process, flexible, yet also rigidly structured.

Human needs

There’s a good reason why giving people names is a concept used in every human society, it allows us to make reference to people easily.

Sure, a person’s name doesn’t really tell us anything about that person, but given context at least we can work out who is being talked about.

Construction projects have many documents and we need a way to reference specific ones, so naturally we use “names”. However, we can’t just give them names like Steve or Roger, instead we try to inject some context and logic into them with names like AH-CHT-Z1-00-DR-M-55_11_20-1001.

Assuming we have memorised the standard, we can have a good guess about what this document contains, but it still leaves an awful lot to the imagination and is not very readable.

It is also a huge assumption that everyone would know what all the codes stand for, so it’s not very simple.

It’s not particularly memorable either,

Information needs

The concatenation problem

To create a contextual name we have to concatenate different information, and we have to be selective about which information to include, which means potentially useful information is excluded.

We also have to shorten down descriptions to simple codes, e.g. DR = Drawing, M2 = Model, ZZ / XX =???.

And then to actually process that name back into useful data it must be split up and inferred based on the position and short codes. It’s all very difficult to process.

The multiple problem

There’s the multiple problem, what happens when a document covers more than one zone, level, type, role, or classification? Ideally there should be a list of possible values, but we can’t put that in a concatenated name, certainly not without making it overly long. The workaround is to just class them as multiple or none applicable without specifying what the multiple even are. A name isn’t flexible enough to allow for these possibilities.

The string problem

There’s also the problem that a name is always just a string of characters. To enforce the structure of a string of characters is a very difficult thing to do. See the code needed just to validate email addresses, which doesn’t even take into account the content itself. In this respect, names are too flexible and not rigidly structured enough.

Are names necessary?

With all these problems, it brings us to an important point. In a digital, structured data environment do we even need names or naming conventions?

Rather than a name, uniqueness could be ensured using proper Globally Unique IDs.

All the current fields in a name could instead be a list of properties that, without the restriction of having to form a name, could eliminate the need for short codes and use much more readable full words.

For humans, we could have unlimited length descriptions, and even additional fields in any format appropriate.

This could avoid the concept of concatenating fields which is just a compromise between humans and information and makes data dumber.


Let’s forget about names. A name should be anything anyone wants it to be. If we need more context then look at the attached raw data. Because after all, the data is where the focus should be.

4 predictions I got wrong

After deciding that a blog post listing the things I don’t know hasn’t reduced my employment chances enough, I’m following it up with a look back at some technology predictions I made when I was younger that I got wrong.

Engineers are at the cutting edge of technology

As a kid I was super excited to go do some work experience at a real engineering office. “These guys are going to be super cool and using amazing technology to produce awesome designs” I thought to myself.

Imagine my surprise when I’m placed in front of a black screen and told to draw 2D lines by typing commands. #WhatYearIsIt! I was blown away by the dumbness of it and knew there must be a better way. (hint: there is)

Tablets will never catch on

This is probably the most embarrassing failed prediction seeing as I now use a tablet everyday at work and my role is to get others to use them too.

But when the iPad first came out I struggled to envision any serious uses. It may seem obvious now, but ‘a big iPhone’ was not intuitively something useful.

Widespread parametric IFC support

When I saw the demonstration of parametric IFC all that time ago it blew my mind so much I was sure it was going to take off, sadly I’ve not heard of anything since and interest has fizzled out.

All engineers would know programming

One of my philosophies is to learn the skills of tomorrow today. When I was 18 I saw the rise of software and it’s power to do work 100s of times faster than humans so I taught myself programming thinking it was going to become a base skill all engineers would need to know.

This has turned out to not be the case, but I’m very glad I do know programming now because it has opened many doors in my career.

The Scourge of Acronyms

“Do you want a chuddy?”, “That teacher is proper dry.”, “Don’t get caught wagging it!”.

As kids everyone loved making up their own words and secret codes. A big part of the fun is that those outside of your group don’t know what you’re talking about, but you feel special because you’re an informed insider.

Unfortunately it seems to me that this behaviour unconsciously carries through into adulthood.

“We need to raise an RFI about an NCR, the FCR on CCSC about BIM MEP IFC is DOA. We need an IDS ASAP”.

It feels great to talk like that, it makes us feel clever and like we’re in on a secret code that only the insiders can understand, just like when we were kids.

But acronyms are truly a scourge in any multi-disciplinary team based environment, which is basically every construction project. They hinder communication, they are inaccessible, and isolate those people that haven’t memorised them yet.


Over usage of acronyms make things become more abstract as the original terms lose meaning.

A recent Twitter poll showed that people can’t even agree what the P in MEP stands for! The acronym has become so far detached from its original meaning that no one knows what words it comes from anymore.

I once queried someone who was using an unfamiliar acronym in an email who subsequently admitted they didn’t actually know what it stood for. The acronym had taken on a life of its own.

Tesla and SpaceX CEO Elon Musk stated in a company wide memoExcessive use of made up acronyms is a significant impediment to communication” (The whole memo is worth reading).

Some people even specifically try to change an acronym’s meaning, like changing the M in BIM from Modelling to Management. This does nothing but cause confusion, for example compare the title and heading and first line of this Tekla article.

In fact, BIM is a great example of when the scope of an acronym expands way beyond its original meaning without thought to the underlying fundemental concepts.

Advantages of acronyms

Writing this post challenged me to think if there are any legitimate reasons for ever using acronyms.

In written documents it can save space, but in this age of becoming increasingly paperless, is saving a very extra bytes really worth it? I reckon that most people’s typing speeds are fast enough these days that the time saving is negligible.

On services drawings acronyms are used frequently to describe systems, for example SA (Supply Air), DHW (Domestic Hot Water), and LTHW (Low Temperature Hot Water). However, I’ve seen the likes of CWS (Cold Water Service / System), MCWS (Mains Cold Water Service), and DCW (Domestic Cold Water) all referring to the exact same type of system.

Even with explanatory legends this can cause confusion and is inaccessible to newcomers.

It is only due to physical paper size limitations and space that means having the full description is unfeasible, however as we move further towards digital ways of working and are less restricted by dead trees, this should become less of a problem.

In speech an acronym does decrease the amount of syllables needed so perhaps they’re useful here? (“WWW” being an interesting exception!)

Unfortunately, I think the area where acronyms are worst is in spoken communication. Whether thats meetings, phone calls, or casual conversations, because unlike a reader who can at least pause and research an acronym, a listener will either have to ask the speaker to explain or continue despite not fully understanding.

Stopping the spread

About 12 months ago to counter the acronym scourge I started to restrict my usage of acronyms to those I was sure that my specific discipline understood.

Then I realised how often I’m interacting with other disciplines so I began using only general construction acronyms.

Recently I’ve been working with apprentices and others brand new to the construction industry to whom even “RFI” (Request For Information) is a new and confusing term.

So while it is only a little thing and may well go unnoticed by many, in all emails, documents, and speech I try to always spell out full phrases every time. This way there is no ambiguity.

I did consider the convention of explaining the full phrase the first time with the acronym explained, e.g. “Bar Bending Schedule (BBS)”, but I still wasn’t happy that I was being as clear as I could be so now I just stick to the full phrase every single time.

The only exceptions are those acronyms understood by the general populace, such as ICT, HMRC, or ASAP.

I now feel the quality of my communication is far better and I am much better understood by others.

I encourage all others to try this and see how much clearer your communication becomes.

(NB: Anyone daring to point out the difference between acronyms and initialisms gets a Special Loser Award for Pedantary.)

Fair criticisms of IFC

IFC is the best schema for exchanging construction and facilities management project information.

There are many unfair criticisms of Industry Foundation Classes (IFC) files when often it is bad software implementation, bad setup, or bad model management at fault.

But that’s doesn’t absolve IFC from any criticism at all.

This article is based on my day-to-day experience of creating, exporting, importing, developing, and managing data with IFC and is where I believe it is fair to say IFC has got it wrong.

Version numbering


Why is it an X instead of a full stop like every other app or schema in the world? IFC 2.3 makes much more sense. Not to mention the latest IFC2 version is actually IFC2X3 TC1. Again, how much more understandable would IFC2.3.1 be?


IFC was skipping version numbers before Windows and iPhones made it popular. Skipping number 9 is pure marketing strategy but there’s no excuse for missing 3 in this context.


Obviously with IFC4 people realised that X is a bit silly, but then instead of adopting best practise and going for IFC 4.1 we now have IFC4add1 and IFC4add2 in the works. There’s even discussions of IFC5. Or perhaps it’ll be IFC5x2TC5Add1ITVBBQ?

Ugly documentation

Once you get used to it, the online documentation is actually quite functional but my goodness, it looks appalling and fails massively from a user experience point of view. Documentation can be both functional (for the power user) and visually appealing (for the new comer). Introductory diagrams full of circles, triangles, and hexagons talking about “resource domains” and “geometry topologies” are not helpful to wide adoption.

Emma Hooper of Bond Bryon BIM put together a great tutorial on using the documentation, but when an animated tutorial is needed to use documentation you know that something somewhere has gone very very wrong.

Ancient schema language

I’m certainly not suggesting that just because something is old it is not useful (my Dad is still good at DIY) and just because something is popular doesn’t mean it is good.

But, with the EXPRESS schema language and STEP file format being over 25 years old and in little use outside of IFC, there are very few people able to transfer existing knowledge or apply existing technologies to IFC.

This means almost every technology for IFC has to be learnt and built from scratch specifically for IFC, increasing cost significantly and meaning we’re unable to take advantage of developments in other domains. For the vast majority of people understanding IFC is still a very steep learning curve.

Too flexible

IFC proudly claims to support a huge array of geometry, but with very little restriction.

For example, one of the simplest possible construction items is rebar. Its just a bent bar of metal. But I’ve seen an exported piece of rebar’s IFC geometry described differently in nearly every rebar detailing tool. This causes inconsistency in how it is displayed in different tools and makes implementation of custom tools very difficult.

The Coordination View MVD (helpfully renamed to Reference View in IFC4) restricts geometry somewhat, but still leaves a little too much wriggle room. And of course usage of MVDs is still not widely understood and implemented.


Too many acronyms.

Emphasis on file based exchange

The emphasis on a file based approach is increasingly at odds with modern cloud and web based approaches.

The emphasis needs to switch to APIs and databases instead of files to allow for microservices and lightweight apps. The likes of is headed in the right direction.


As I always say, IFC is the best available schema for construction and facilities management project information. But, I believe it needs to modernise to be suitable for the next generation.