Last week, in a fit of despair, I published a piece that touched on a few questions around open formats and proprietary formats, specifically asking whether it was legitimate or advisable for a contracting authority to require the delivery of a model in proprietary format as well.
As I expected, I hit a nerve. Among the most frequent comments, one objection recurred with the regularity I had anticipated: fine, IFC, agreed, open format, sharing, all well and good, but it’s not parametric. You can’t work with it. You can’t take someone else’s model and pick up where they left off.
It’s a legitimate objection. And for once I’m not going to dismantle it. Not straight away, at least.
IFC is a data schema that does not preserve parametric behaviour and the relationships between objects except at an extremely elementary level that’s often insufficient to describe the complexity of an architectural, structural or MEP object. That’s true.
Let’s say it clearly, because minimising serves no one: IFC is not a file format — it is not designed to be an editable model — but a schema designed to standardise the way different software packages describe a building. It was born as a data schema for exchange and reading, not for authoring.
A file format dictates how data is physically encoded and written as bytes on your disk. A data schema is the logical architecture or structure of that data, defining fields, data types, and the relationships between those data.
Importing an IFC into Revit or ARCHICAD and expecting to continue working on it as if it were a native file is, in most cases, an exercise in frustration: families are read differently from how they were conceived, constraints disappear, the parametric structure that someone built with painstaking care flattens into dumb, mute geometry. This is real, it is documented, and anyone who has tried it on complex projects has the scars to prove it.
I’m not here to praise IFC or to bury it: I’m here to ask whether we’re approaching the problem from the right angle, whether the questions we’re asking ourselves start from the right premises.
1. Traumas age badly
Before getting to the right question, it’s worth saying one thing: many of the wounds circulating in this debate are a little dated. IFC has improved. Authoring software has improved, both in exporting it and in reading it. Which means the pipelines have improved.
If we try, for example, to open Revit and insert as a link a well-made structural file coming from Tekla, we will see far fewer of the behaviours that used to appear before Autodesk strengthened its steel modelling module: the geometry is preserved even in connections and details, attributes transfer into their pSets without being nuked out of existence, the result is often usable. The same goes for other disciplinary workflows that until recently were considered impractical.
The problem is that professional debate tends to crystallise around the worst experiences, and the worst experiences age without being retested. People still talk about IFC as if we were importing 2017 files into 2019 software. It is always worth reopening the software, trying again, and checking whether the trauma still holds up against updated versions. Often it doesn’t. Thank goodness.
This does not transform IFC into an authoring format, but it significantly scales back the conviction that nothing can be done with it.
2. The wrong question
Let’s return to the central objection. The typical case being described is this: professional B inherits a job from professional A, who vanished in the night: changed firm, changed country, changed career, ended up in prison, variously unreachable because the client stopped paying them. Often unaware of the reasons, professional B must continue the project, get to grips with the drawings, update the model, deliver. And without professional A’s native file, they find themselves chained to a rock, naked, waiting to be devoured by the sea monster of the deadline.
I understand the situation. I’ve lived it. It’s frustrating and costly.
But over the years I’ve come to understand that this is not a format problem: it’s a workflow problem, as it’s often the case.
In a correct design process — and I realise I’m uttering the most unpopular words in the profession — professional B should not be stepping into professional A’s shoes.
Professional B should be moving towards a different level of development, with different objectives, with documentation produced from scratch based on the requirements of the next phase. Professional A’s model should be a reference, not a starting point. Professional A’s drawings are a source, not a template to update.
The workflow in which B inherits A’s model and continues exactly from where A left off, model and drawings included, is a workflow that doesn’t work well even with the native file: anyone who has received a Revit file from an external firm and tried to “continue from there” knows what I’m talking about. Missing families, or ones so complicated that it’s quicker to rebuild them than to understand them. Incompatible starting templates with bizarre naming conventions. Levels renamed in incomprehensible ways, views that refuse to update, annotations that explode at the wrong moment. The native format does not solve the problem of project inheritance: it only makes it slightly less painful at the beginning, before making it considerably more painful afterwards.
The solution is not to have A’s native file, but to have clear information requirements that define what A must deliver, in what form, and for what subsequent use, so that B can start from a clean base instead of doing archaeology in someone else’s model.
3. In the private sector, the rules change
It’s worth clarifying a point that in the first article was perhaps excessively implicit but deserves to be stated explicitly again: the entire argument about open format as a requirement concerned public sector clients. Between private sector professionals, exchanging native files is perfectly fine. In fact, it’s often the most sensible choice.
BIM works when you share without filters. If two firms are working on the same project, using the same tools, and trust each other, exchanging native files is efficient, reasonable, and in some cases necessary. Nobody ever said otherwise.
The problem is not the native file itself: the problem is the native file as the only acceptable format, because it becomes a barrier to entry and a tool — conscious or otherwise — of exclusion. Because proprietary formats create barriers, unwanted roadblocks, even in the private market, and this is a consequence the debate tends to ignore.
4. The invisible barrier
If the engineering of a complex project were to require all participants to work in Tekla ($7,350 per year), or in a specialist software with prohibitive cost and learning curve, many firms would be excluded. Not because they lack competence, or because they don’t know how to do their job, but because they cannot afford the licence, or don’t have the time to train staff on a tool they will use for a single project.
And so the open format is not merely a question of transparency in public administration, but a question of market accessibility. An ecosystem in which participation in prestigious projects is conditioned on software choice is an ecosystem that concentrates work in the hands of those who can afford the most expensive tools, and this should concern anyone who believes that design quality is not a privilege reserved for large firms.
5. So what do we do with IFC?
Basing our entire industry’s interoperability on a data schema like IFC has real limitations. It is not sufficient to describe parametric behaviour, it is not an authoring format, and it probably never will be in the full sense of the term. Nor should it be, because that is not its purpose.
It is a data exchange schema to be used as a reference. It is the interoperability layer that allows different tools to see each other without anyone having to surrender their internal architecture.
Using it well means understanding what you are asking for and why. It means recognising that in a great many cases — reading, checking, coordination, delivery to the client, asset management — it is exactly the right channel.
A concrete example helps to clarify where the reasoning breaks down. Let’s imagine a fully parametric window: frame, sash, mouldings, everything controlled by parameters, everything modifiable. An elegant, well-built object, the product of hours of work. Transmitted in IFC, that window loses its parametric behaviour. It becomes geometry. The mouldings are still there, but they no longer move.
So what?
The question is: why would anyone need to change that frame moulding?
If it was wrong in the first place — incorrect dimension, non-conforming profile, a design choice to be reconsidered — the answer is not to edit the IFC geometry. The answer is to replace the component with a new one. If it needs replacing because the specification has changed, the answer is exactly the same: replace the component with a new one. If the manufacturer has updated their catalogue and that profile no longer exists, the answer is still the same: replace the component with a new one.
The parametric behaviour of that window was a production tool. It served whoever built it to adapt it during the design phase. Once the window is defined and delivered, what matters is not being able to deform it parametrically, but knowing exactly what it is, where it is, what its properties are, and how to replace it when needed. All things that a well-made IFC contains perfectly.
A framework to describe and preserve some basic parametric relationships is certainly needed, but what is also needed is a little more clarity of thought, starting with stopping the dismissal of IFC based on traumas five years old without reopening the software. And above all, we need to recognise that the real problem has never been the format. The problem is that we keep building workflows as if the project were a parcel passing from hand to hand, always the same, always editable, always continuable. It doesn’t work that way. It didn’t work that way with DWG, it doesn’t work that way with native files, and it won’t work that way with IFC.
The project is not inherited. Phases close, and then you start again. In the next phase, with contributions different in nature, density and purpose.
No Comments