Five Years of Progress: From Individual Use-Case Standards to Industry-Wide Interoperability
This month marks the fifth anniversary of the buildingSMART Technical Roadmap, first published in April 2020. The roadmap laid out an ambitious agenda: a renewed bSDD, a more transparent system for maintaining and publishing IFC, a standardized approach to information requirements, an API strategy, and the modernization of IFC through version 5.
At the outset, the buildingSMART ecosystem featured several diverging initiatives. IFC and bSDD were often seen as competing rather than complementary. Discussions around mvdXML were polarized, with views ranging from “unworkable” to “essential”. There was also widespread confusion about the purpose and nature of IDMs and MVDs.
As the work progressed, the objectives evolved. At the request of the Strategic Advisory Council (SAC)—representing some of our most important stakeholders—we added IFC Software Certification to the task list, which had not been part of the original roadmap.
While IFC version 5 is still in development, the other key components of the roadmap have been delivered and are seeing adoption at an encouraging pace. These achievements deserve recognition on their own, but they also contribute to a broader picture—one that may not always be immediately visible.
From Fragmentation to Unity
In the years before the roadmap, buildingSMART’s strategy focused on defining a separate standard for each data exchange use-case. There were dedicated standards for design coordination, referencing, quantity take-off, precast elements, energy analysis, bridges, roads, and more. Each came with its own interpretation of required data, distinct expectations for software behavior, and its own certification pathway.
These were known as Model View Definitions (MVDs)—structured subsets of the IFC definitions tailored for specific data exchange scenarios. The idea was that software vendors would implement these MVDs individually, with the option to expand into more use-cases over time. In theory, this would ease adoption.
However, in practice, this approach presented several challenges. Differences in regional requirements, dynamic project-specific requirements other evolving needs meant that each use-case standard was subject to exceptions and adaptations. Additionally, since MVDs were developed largely in isolation from one another, the overlap between them often led to inconsistencies rather than synergies. For example, data structured for a precast exchange is not usable in software supporting the reference view.
IFC 4.x grew significantly in scope, incorporating a wide array of use-cases and leading to a complex structure with over 300 documented exceptions. While this breadth was well-intentioned, it also created barriers to adoption and maintainability. Until recently, even buildingSMART had not published fully valid IFC dataset that conformed to the standard. Only last year, through significant effort, were the PCERT sample files released as the first fully valid examples for IFC 4 and 4.3.
In hindsight, the challenges of repeatedly implementing specialized MVDs may seem obvious—but at the time, it was the prevailing methodology.
A Shift in Direction: Back to Basics
buildingSMART’s mission has always been to support open, vendor-neutral interoperability across the industry. The MVD methodology was a risk for achieving that objective. Luckily most end-users have always perceived IFC as a single, unified standard—something that underpins interoperability across the built environment. Regardless of the MVD concept within buildingSMART, users recognize IFC as the common denominator behind the “export IFC” function in their software.
Over the past five years, the roadmap has pushed reality closer to that end-user perception. Notable milestones include the normalization of properties in IFC 4.3, a closer alignment between bSDD and IFC, the introduction of the Information Delivery Specification (IDS), and the creation of a unified global software certification framework.
A key symbol of this more integrated approach is the rethinking of software certification. Our strategic members identified critical limitations in the MVD-based model—particularly the burden of requiring vendors to certify for each use-case separately. This led to the development of the Global Software Certification program, which takes a broader, more scalable view. This is done while keeping the use-case specific certification in place as an optional add-on.
Figure 1: Scorecard how an anonoumised software tool supports IFC. Green is all good; red means there have been errors found; grey means we did not see any support for this part of IFC in this tool. Yellow means 'we found a deviation from common practise'.
The updated certification framework evaluates software against the full IFC standard and provides a clear scorecard showing which functional parts are supported and to what degree. This not only improves transparency for users but also reflects a return to the original vision—championed by Jeff Wix in the early 2000s—of IFC as a single, comprehensive foundation for multiple use-cases. In fact, Jeff’s term “functional parts” has been reintroduced to underscore this intent.
The Last Piece of the Puzzle: IFC Version 5
Transitioning from use-case specialised MVDs to a unified, scalable IFC standard has not been without its challenges. It requires a shift in mindset—from optimizing individual exchanges to enabling holistic, industry-wide interoperability between all domains. For many, this shift has come naturally. For others, it remains a significant challenge.
But there is no way back. With the growing digitalization of construction and infrastructure, isolated, point-to-point data exchanges are no longer sufficient. The future demands robust foundations for integrated simulations, Common Data Environments (CDEs), and interoperability with adjacent domains such as point clouds, geospatial data, and more.
All the puzzle pieces developed over the past five years have pointed in this direction. As the final component of the current roadmap, IFC 5 represents an opportunity to reaffirm the original fundamentals. It will demystify the IFC core, clarify its structure, and establish a truly use-case-agnostic foundation. While technology enhancements such as JSON serialization and APIs improve usability, they cannot replace the need for a coherent and maintainable core. Supporting the needs of modern workflows requires further refinement at the heart of the standard.
IFC Version 5 is the cornerstone that brings together the progress of the past five years of actual interoperability. It also serves as the stepping stone to the next phase—focused on APIs and deeper integration of IDS and BCF into IFCx. More on that to come in the next edition of the roadmap.
Conclusion
While we celebrate individual achievements like the new bSDD, IDS, global software certification, and a significant improvement in the readability of IFC documentation, these elements have always been part of a larger puzzle. A puzzle that positions interoperability as an industry-wide objective.
The journey of the past five years has demonstrated that real interoperability requires more than just technical solutions—it demands alignment of purpose, shared definitions, and a willingness to listen to external stakeholders. It also highlights the challenge of advocating for cross-domain (or transdisciplinary) interoperability in the face of narrowly focused point-to-point approaches.
The return to a unified IFC standard is clearly not following the easy route, but it is essential. At buildingSMART, we remain committed to doing the hard work—so the industry can move forward more easily.
Author: Léon van Berlo, Technical Director