Innate Interoperability

Interoperability is a word that is thrown around often, especially when discussing topics like open data. However, while two concepts can be synergetic, they aren’t necessarily connected. This blog post explores what interoperability is and how prevalent it is within the built environment.

So, first thing’s first, what is interoperability? As defined within ISO 2382, the international standard for IT vocabulary, interoperability is defined as:

Put simply, if you are able to share between two functional units (i.e. different hardware or software), then that data is interoperable. Considering the number of different supply chain organizations who work together, being interoperable is vital to ensure the success of a project by enabling each organization to send and receive data in a sharable and consumable format.

These organizations can do so in one of two ways, using proprietary data or using open data. As defined within ISO 5127, the international standard for information and documentation vocabulary, open data is defined as:

If data can’t be freely used, re-used, re-published and redistributed by anyone, then it isn’t open and is therefore considered proprietary. While I am a supporter of open data, I won’t provide an argument on which method is preferable here. For balance, I will acknowledge that interoperability can be achieved using either proprietary or open data. What I intend to focus on is the prevalence of proprietary and open data within construction projects. Figures vary, but a construction project will typically exchange thousands of digital files. What I find astounding is the amount of these files which utilize open data. Almost all of them!

Some quick maths. Following a discussion with several peers, there is a consensus that ~5% of files on a construction project are model files, such as topographical models, or building / infrastructure models. While these files can be exchanged using open data formats, for example using IFC data models defined within ISO 16739-1, they are more often than not exchanged using a proprietary file formats. In contrast, the remaining 95% of files are correspondence, documents, drawings, photographs, minutes, presentations, reports, schedules, specifications, or visualizations. For these files, we default to open data formats:

• Document-based files, such as: correspondence, drawings, minutes, reports and specifications are typically exchanged in PDF, an open data format defined within ISO 32000
• Image-based files, such as: photographs, and visualizations are typically exchange in JPEG or PNG, open data formats defined within ISO 10918 and ISO 15948 respectively.
• Office-based files, such as: documents, presentations, and schedules are typically exchanged in DOCX, PPTX, XLSX open data formats defined within ISO 29500.

Of course, these aren’t exact figures and there are contrary examples on both sides. However, I find it shocking that the issues being discussed around the suitability of open data solutions are normally restricted to model files; affecting less than 5% of the total files being exchanged on construction projects.

And there we have it. As we undergo our sector’s digital transformation, we need to be conscious that almost all of the data we exchange is already in an open, interoperable form. If the digitalization our processes results in a higher percentage of model-based exchanges, we need to ensure that the data provided hasn’t inadvertently become restrictive by using proprietary data formats. If we manage to control the shift in how we exchange data, we can ensure that the built environment retains its innate interoperability.

Dan Rossiter, Sector Lead at BSI