A Better Data Model for BIM in AECO

The Architecture, Engineering, Construction, and Operations (AECO) industry needs a new data standard inspired by browser standardization. This article suggests a path forward based on the clear goals that made web standards successful.

The internet changed from static pages to interactive applications because browsers became standardized around a common purpose. In the 1990s, the internet was fragmented. Browsers like Netscape Navigator and Internet Explorer had different rules for displaying web pages. Developers had to make multiple website versions, which slowed innovation. The key turning point came when the industry aligned behind a shared goal: ensuring the same content could be accessed by anyone regardless of their hardware or software.

The World Wide Web Consortium (W3C) formed in 1994 with this clear mission. Tim Berners-Lee guided the organization to create common rules that would help the web grow while ensuring content worked the same way everywhere. This shared purpose - universal access to the same content - drove cooperation even among competing companies.

The benefits went beyond technical fixes. Standards made development simpler by letting developers write code once instead of multiple versions. Users got a more reliable experience with consistent content across different browsers. New technologies like AJAX became possible because everyone built on the same foundation. Most importantly, innovation flourished because everyone understood what they were working toward - a web where content was universally accessible, regardless of device or browser choice.

The BIM Standards Problem

In the last 15 years, the AECO industry has adopted Building Information Modeling (BIM). While BIM has improved project management and design, its standards lack what made web standards successful: a clear, unifying purpose.

When BIM started in the early 2000s, each firm used different software, causing compatibility issues and inefficient workflows. This mirrors the early fragmented web. But unlike web standardization, BIM standards developed without a common goal everyone could rally behind.

Software compatibility remains a major challenge. The Industry Foundation Classes (IFC) standard helps, but without a shared vision, software vendors implement it inconsistently or resist it entirely. BIM standards also face problems with regional differences in building codes and practices. Standards like PAS 1192 in the UK and the National BIM Standard in the US represent progress, but highlight the absence of a universal purpose that transcends regional interests.

Despite these challenges, standards have improved collaboration in the AECO industry. Projects are more integrated, with better communication and fewer errors. Better BIM tools have emerged for building design, construction, and management. Specialized BIM education and certifications have improved industry skills.

BIM standardization continues to evolve, but my main critique is that these standards lack a common frame of reference to guide their development. Without this shared vision, organizations assign their own meaning or expectations to standards, often serving narrow interests rather than benefiting the broader community. While we've seen progress with formats like IFC, we need more than technical solutions. The web standards community had a clear, unifying goal: ensuring the same content could be accessed by anyone regardless of their hardware or software. This clarity of purpose drove cooperation. The AECO industry needs a similar unifying vision. Just as HTML, CSS, and JavaScript form the foundation of web development with a common purpose, BIM needs a protocol framework with clear goals to ensure compatibility across software. The W3C model of bringing together diverse stakeholders—from browser makers to developers—shows how AECO could unite architects, engineers, contractors, software developers, and industry groups around shared objectives. Like web standards, BIM standards should be open rather than controlled by single companies, fostering innovation and adoption driven by a common purpose rather than fragmented interests.

A Purpose-Driven Framework for BIM

A 'web stack for BIM' would need more than just layers of technologies—it needs a clear purpose that all stakeholders can support. I propose this purpose should be: "Leveraging web-native languages and browser technologies as the universal platform for building information, making BIM accessible anywhere, on any device, throughout the entire building lifecycle."

With this guiding principle, we can develop a layered framework inspired by, and most likely using web technologies:

Universal Data Language

A UDL would serve as the foundation, similar to HTML. Just as HTML ensures content structure is understood by any browser, UDL would ensure building data is understood by any BIM software. Without a common purpose, existing efforts from companies like Autodesk and Bentley Systems focus more on their own ecosystems than on universal access.

While BuildingSMART has developed the library Industry-Foundry-Class IFC, the industry lacks a unifying vision for it's implementation. The spotty and difficult adoption is evident when examining construction technology startups, where IFC rarely serves as a foundational element—unlike how Node.js underpins web applications. This fragmentation within the construction industry stems largely from the absence of a clear, shared purpose that transcends individual commercial interests.

The open-source approach of Speckle Systems shows promise because it aligns more naturally with the purpose of universal data access, as does NVIDIA's Universal Scene Description (USD). What makes these efforts particularly interesting is their connection to web technologies. Speckle, for instance, uses web-native languages and protocols to underpin its system, recognizing that the web already solved many similar problems of universal access and interoperability.

These efforts must ultimately converge around a common goal rather than competing commercial interests. Looking at how HTML succeeded not just as a technical specification but as a philosophically coherent approach to structured information, we see that UDL must similarly balance technical functionality with a clear vision of universal accessibility. Just as HTML was designed to be human-readable, device-agnostic, and forgiving of errors, a successful UDL would prioritize openness, accessibility, and resilience over technical sophistication or vendor control.

Design & Visualization Layer

A DVL would manage visual representation, similar to CSS in web standards. But unlike today's visualization tools that often lock users into specific platforms, DVL would ensure visual information works across systems. This layer must preserve the graphical communication that engineers and architects rely on while ensuring representations work anywhere—from desktop applications to mobile devices to web browsers.

The key success metric isn't visual sophistication but universal accessibility of visual information. The DVL would need to encapsulate the intended communication of 'building information' which is currently being served by 'The Document Set.' This represents a significant challenge, as while 3D models provide the framework and basic information about materials, the drawing set has traditionally been the place for architects and engineers to convey design intent on connections, interfaces, and assembly details. This is where building design is actually communicated.

The current disconnect between 3D models and 2D documentation creates inefficiencies similar to how early websites looked completely different across browsers. A true DVL would bridge this gap by creating a standard way to express visual information that maintains consistency regardless of viewing platform. Just as CSS separated content structure from visual presentation on the web, DVL would separate building data from its visual representation, allowing stakeholders to view the same information in ways appropriate to their needs while maintaining the design intent's integrity.

Interactive Functionality Protocol

An IFP would add dynamic features, similar to JavaScript. The web's success came when JavaScript allowed the same interactive functions to work across browsers. Similarly, IFP would ensure that collaborative features, data manipulations, and user interactions work consistently regardless of software platform. This concept builds upon buildingSMART International's BIM Collaboration Format (BCF), which currently enables model-based issue communication between different BIM applications by leveraging previously shared IFC models. BCF allows stakeholders to mark specific locations, assign tasks, and track resolution status without exchanging entire models. While BCF addresses issue tracking and communication, a true IFP would go further to standardize actual functionality like analysis tools, simulation capabilities, and real-time collaborative features across platforms, rather than just communication about static issues.

BCF enables conversation about issues, but IFP would enable shared functionality—ensuring that valuable tools work consistently for all stakeholders throughout a building's lifecycle. The future of AEC collaboration isn't just about communication standardization but about standardizing how functionality itself works across the entire ecosystem.

Integration and Communication Standard

An ICS would connect different systems, similar to web APIs. Rather than creating proprietary connections between tools, ICS would establish open methods for data exchange focused on the common purpose of universal access and usability throughout the building lifecycle.

ICS would need to address security, change management, data ownership, and performance in ways that current standards don't fully tackle. Without these considerations, we'll continue to have fragmented data silos despite superficial connectivity. Software companies developing integration tools must commit to this shared goal of universal data access rather than using integration as a competitive advantage.

While IFP and ICS address different aspects of the BIM framework, they would need to work in concert—just as JavaScript and web APIs work together on the internet. The communication infrastructure provided by ICS would create the highways on which IFP's functional components could travel between systems. The challenges to this framework are significant but not insurmountable. Industry adoption depends on communicating the clear purpose and shared benefits. Technical complexity can be managed by focusing on the guiding principle rather than trying to solve every problem at once. Most importantly, innovation will flourish within this framework precisely because it establishes clear goals—just as web innovation exploded once standards with a clear purpose were established. The true test of any proposed standard should be: "Does this help ensure building data can be accessed, understood, and utilized by all stakeholders across the entire building lifecycle?" This simple question would transform our approach to BIM standardization.

By learning from browser standardization's clarity of purpose, the AECO industry can move toward a more integrated, efficient future. This vision of a purpose-driven 'web stack for BIM' addresses current compatibility issues and opens new possibilities in digital construction and design. Just as web standards transformed the internet by ensuring universal access to content, BIM standards with a clear purpose can transform how we create and manage our built environment.

Web Stack Eats AECO