Open BIM Is Not an Export Button. It Is an Information-Control Strategy.
Updated: Aug 30
Open BIM is often reduced to a file format discussion. Can the model export to IFC? Can another application open it? Did the geometry appear?
Those questions matter. They are not enough.
The stronger signal from NXT BLD 2026 is that AEC firms are looking for greater control over their data, software processes, and institutional knowledge. Open tools and internal development are becoming part of that strategy.
What the industry is reacting to
AEC Magazine’s event review highlighted several connected trends: larger off-site assemblies, firms rebuilding technology stacks, growing interest in open BIM components, more in-house software development, and concern about API restrictions, licensing, AI liability, and ownership.
For DDG, the common thread is control. The practical goal is to keep project information usable beyond one application, one subscription, or one vendor decision.
An export can succeed while the workflow fails
A model may look correct after exchange and still be operationally incomplete.
Objects may lose classifications or become generic geometry.
Parameters may change names, types, units, or values.
Coordinates may shift even when the building looks aligned on screen.
System relationships may disappear.
Issue references and approval status may not travel with the model.
The receiving team may not know which information is authoritative.
Open BIM needs a defined information requirement
Interoperability should be tested against what the next party needs to do, not simply whether the file opens.
For each exchange, the team should define the required geometry, properties, relationships, coordinate basis, status, and acceptance test. The workflow should be checked with representative project data before it is relied on for project delivery.
In-house software creates a second governance problem
AEC practices are building utilities, integrations, and AI-assisted tools internally. Lower development effort makes more of this work practical. It does not remove the need for software governance.
Version control: Which release produced the project output?
Testing: What cases prove the calculation or transformation is correct?
Approval: Who can release the tool for project use?
Ownership: Who maintains it when the original developer moves on?
Security: What systems and project information can it access?
Retirement: How will teams know when the tool is no longer approved?
Questions owners and contractors should ask
What exact information must remain usable at each handoff?
Which open format and version will be used?
What Model View Definition or exchange requirement applies?
How will geometry, data, and coordinates be validated?
Which model or dataset remains authoritative when exchanged information differs?
Can the owner retrieve the required information without maintaining every authoring license?
A practical Open BIM test
Select one real workflow, such as architectural-to-structural coordination, model-to-fabrication transfer, or handover to operations. Define the required information and run the full exchange.
Then test four things: completeness, accuracy, repeatability, and recoverability. For this test, recoverability means being able to retrieve the required information without reconstructing the exchange from the beginning. If the team cannot repeat the result or explain what was lost, the workflow is not ready.
The DDG perspective
At DDG, we do not treat Open BIM as freedom through a single export command. It is a disciplined approach to keeping project information accessible, testable, and useful across tools and project phases.
Firms gain control when their exchange requirements are explicit, their internal software is governed, and their teams can prove that information survives the handoff.
Build stronger BIM information workflows with Detail Design Group
Comments