Executive summary

For fifteen years, BIM's goal was to produce a model. The shift underway is that the model stops being the central deliverable and becomes one node in an information architecture that includes classifications, requirements, manufacturer data, GIS, ERP, CMMS, and sensors. The change has a technical basis: IFC can be represented as an RDF graph linkable to external data [5], bSDD distributes classifications and properties via API [7], and IFC5 is being rebuilt on a layered composition logic [4]. The consequence: "which software do we use?" matters less than "how do our data relate across systems, and who's accountable for each relationship?"

The real problem and what's changing

The familiar symptom: a mechanical equipment property exists simultaneously in the Revit model, in the procurement spreadsheet, in the manufacturer's submittal, in the owner's maintenance system, and in a spec PDF. Five copies, none authoritative, zero traceability on which is correct. That's the problem a data architecture solves — not a new platform.

The difference between "BIM model" and "connected data architecture" is the unit of management: in the first approach, information travels in files and each exchange produces a copy; in the second, it's referenced — the model points to a published classification, to a property defined in a dictionary, and to an asset identifier the owner recognizes. The copy is replaced by the link.

Three developments support this shift: representing IFC data as RDF graphs via ifcOWL, which links the building to materials, GIS, manufacturer, sensor, and classification data [5][8]; lightweight ontologies like BOT (Building Topology Ontology), developed by the W3C's Linked Building Data group to describe a building's topology — floors, spaces, contained elements — in a web-friendly way [6]; and bSDD, which hosts classifications, properties, allowed values, and units accessible via REST API, implementing concepts from ISO 12006-3, 23386, and 23387 [7].

Why now

The main driver is economic. Most AEC firms accumulate historical files — drawings, RFIs, specs, closeout reports — that are unusable because they're inconsistent, on paper, or siloed in disconnected systems [1]. Data becomes an advantage only when it's captured at creation, structured for reuse, tracked for provenance, and the company retains the right to learn from it [1].

The second driver is standard evolution: IFC 4.3 was ratified as ISO 16739-1:2024, extending scope to linear infrastructure [2][3], while IFC faces a major refactor under the name IFC5 [2], whose repository publishes alpha examples of the IFCX format [4]. To be precise: IFC5 is still alpha material, not a foundation for short-term production planning.

The third driver is contractual: whoever doesn't negotiate portability, client-data separation, and platform exit terms risks losing control over their own information asset [1].

How it works and where it applies

It's organized into five layers: identity (stable identifiers, so a fan stays the same object across design, construction, and operations), semantics (what each class and property means, referencing published dictionaries instead of undocumented internal conventions [7]), requirements (what information must exist at each exchange, in a verifiable format), exchange (open formats and APIs), and governance (who's accountable for each dataset and how it changes).

Concrete applications:

Connected takeoff and procurement: quantities aren't exported, they're queried; a design change propagates to the procurement package without manual re-entry.
BIM-GIS integration for infrastructure: IFC 4.3 provides the alignment and linear-asset definitions that relate the model to its territorial context [2][3].
Handover to maintenance: instead of a model plus a folder of PDFs, a set of identified assets with properties referenced to a shared dictionary, consumable by the owner's CMMS.
Cross-system graph queries: questions a file can't answer well, like "which equipment feeds critical spaces and lacks verified maintenance access" [5][6].

Business and team impact

The direct impact is on the marginal cost of information. With files, every new use of a data point requires re-entering or reconciling it; in a connected architecture, the cost of reuse trends toward zero while the cost of initial definition rises. It's a shift from variable spend to fixed investment, and that calculation determines whether it makes sense for each organization.

A role appears on teams that many AEC firms don't have: someone accountable for the data model, not the 3D model. The BIM Manager takes on information-architecture decisions that used to be made implicitly by whichever software was chosen, and discipline specialists have to make explicit the conventions that used to live only in their heads.

Barriers, risks, and maturity level

The dominant barrier is the semantic gap: IFC was designed as an exchange schema, and the literature on semantic technologies in AEC documents the need for heavy transformation and preprocessing to get structures fit for querying and reasoning [9]; the authors of the EXPRESS-to-OWL conversion already flagged its limitations [8]. Next come vendor dependency, greater when the connection layer lives inside a commercial platform [1]; maintenance cost, since an architecture with no owner degrades faster than a file; and security, an area covered by ISO 19650-5 [10].

Maturity: early and very uneven adoption. The normative components are stable (IFC as ISO 16739-1:2024, bSDD live with a public API, peer-reviewed ontologies); what's not consolidated is the practice, since most projects still operate by file exchange and IFC5 remains in alpha [4].

How to prepare

Define an asset identity model before any platform: what gets identified, with what coding, and who administers it.
Reference published dictionaries instead of inventing properties, relying on bSDD and on ISO 12006-3, 23386, and 23387 [7].
Start with a business case that has a named recipient — handover to maintenance, procurement, progress control — not a general data migration.
Separate the data from the tool: require full export, documented API, and portability in every platform contract [1].
Assign explicit ownership of each dataset, with an owner, a quality criterion, and an update cycle; without this the architecture degrades within a semester.

Future outlook and conclusion

The likely evolution over three to five years is a long coexistence: IFC file exchange as the contractual baseline, complemented by API queries over data subsets with operational value. IFC5 targets more advanced use cases [2], but its real timeline depends on software vendor implementation. It's speculative to assume semantic graphs will replace file exchange within that horizon.

The strategic conclusion: treating BIM as a data architecture isn't an IT project, it's a decision about what assets the company retains. A firm that delivers models without keeping a reusable information structure sells hours; one that accumulates consistent, traceable data across projects builds an asset that appreciates. The difference doesn't show on the first project — it shows on the twentieth.

Frequently asked questions

Does this mean abandoning IFC files? No. IFC 4.3 is a current ISO standard [3] and remains the contractual basis for exchange. The connected architecture is built on top of it, not against it.

Do we need to implement ontologies and RDF to get started? No. Most of the initial value comes from simpler decisions: stable identifiers, properties referenced to a shared dictionary [7], and verifiable requirements. Semantic graphs are useful for complex query scenarios, not an entry requirement.

Should we wait for IFC5? Not for operational decisions. IFC5 is alpha material under open development [4]; the data-architecture decisions being made today — identity, semantics, governance — will remain valid regardless of schema version.

Sources and references

[1] Ahmoye, D.; Sjödin, E.; Blanco, J. L. and others. "How AI is reshaping the future of the AEC industry." McKinsey & Company, July 15, 2026.

[2] buildingSMART International. "Industry Foundation Classes (IFC)" — official IFC 4.3.2.0 version and the refactor toward IFC5.

[3] ISO. ISO 16739-1:2024, "Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema."

[4] buildingSMART International. IFC5-development repository (alpha examples, IFCX format, schema under development).

[5] buildingSMART Technical. "ifcOWL" — representing IFC data as RDF graphs, linked to materials, GIS, manufacturer, and sensor data.

[6] Rasmussen, M. H.; Lefrançois, M.; Schneider, G. F.; Pauwels, P. "BOT: The Building Topology Ontology of the W3C Linked Building Data Group." Semantic Web, vol. 12, no. 1, 2021.

[7] buildingSMART International. "buildingSMART Data Dictionary (bSDD)" — dictionary service, API, and alignment with ISO 12006-3, 23386, and 23387.

[8] Pauwels, P.; Terkaj, W. "EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology." Automation in Construction, vol. 63, 2016, pp. 100-133.

[9] "Knowledge-based semantic web technologies in the AEC sector." Automation in Construction, 2024.

[10] ISO. ISO 19650-5:2020 — Security-minded approach to information management.