The Interoperability Problem

No single piece of software is best at everything, and no client can force every firm on a project onto one product. Architectural authoring, structural analysis, services design, quantity surveying, energy simulation, construction planning, facility management — each has tools built for its job, often from different vendors, chosen long before this project began and used across every other project the firm runs.

That is not dysfunction; it is the nature of a fragmented industry. The consequence is unavoidable: information *must* cross software boundaries, repeatedly, throughout a project's life. A structural model informs the architect; the coordinated design feeds the contractor; the as-built feeds the operator. Every one of those handoffs is a moment where meaning can be lost — and the more tools, the more boundaries, the more chances for the model to arrive as a shape with its intelligence stripped away.

Interoperability failure is not usually a file that will not open. It is subtler and more dangerous: the file opens, but something has quietly gone. A wall arrives as geometry but its fire rating is gone. A parametric window becomes a dumb block that no longer updates. Classifications, property sets, relationships between elements, the very 'this is a door' intelligence — any of it can fall away in translation, silently, so the receiving team trusts a model that has been hollowed out.

The worst case is the proprietary silo: information locked in one vendor's format that only that vendor's software can fully read. Lock a project's single source of truth inside one product and you have bought a serious risk — that the client cannot get their own data out, that a firm using a different tool is shut out of coordination, that in fifteen years, when the software has moved on, the asset information is trapped in a format nobody can open. A model you cannot get your information out of is not an asset; it is a hostage.

There are only two ways to make information cross these boundaries safely. The first is to force everyone onto the *same software* — a single vendor's ecosystem end to end. It can work inside one firm, but across a whole project supply chain it is usually impossible and always risky: it hands one vendor total control, excludes good firms who use other tools, and bets the asset's fifty-year life on one product's survival.

The second road is an open, shared language that every tool can read and write — a neutral format owned by no vendor, so information can move between products without being trapped in any. This is the idea behind openBIM, and its central data language is IFC (the next lesson). It is not magic — as we will see, open exchange has its own honest limits and does not preserve everything perfectly. But it changes the fundamental bet: instead of trusting one company forever, you trust an open standard the whole industry maintains. For anything that must outlive a software licence — which is to say, a building — that is the road that actually leads somewhere.