ISO 19650: Evolution, not revolution – for better or for worse
BIM is, was, and always has been about trying to shift people from unstructured information towards schema-based information exchange, says Alex Plenty.

ISO 19650 Parts 1 and 2 have recently been revised and issued for comment. Part 3 will follow, given that the original Parts 1 and 2 have now effectively been amalgamated. There are a fair number of changes, which is hardly surprising given it’s been eight years since the first ISO editions, and nearly 20 since their BS 1192 roots.
When you consider how much the BIM and information management landscape has shifted in that time, it’s reasonable to ask whether the revision to these drafts should go further.
That said, in an era where everything is either good or bad, right or wrong, nuance often gets lost. For every change you’ll dislike, there will almost certainly be one you’ll welcome, and most changes will pass unnoticed by most of the industry. Yet there are some thoughtful updates here, produced by well-meaning people, trying to move things forward for the right reasons.
For transparency, I deliberately avoided reading other people’s commentary before forming my own view. I also left comments on the drafts themselves – it would be odd to feel strongly enough to write an article without engaging properly in the review process. Most of my comments were minor, but a few themes stood out strongly enough to warrant a deeper look.
Several components
First, BIM, information management, and what’s been lost. Let’s start with some context, with my understanding of what information management and BIM are in relation to published industry standards and practice in 2026.
Information management is made up of several ‘components’, including:
- A process component comprising standards and processes which govern the purpose, specification, production and supply of information across the lifecycle of a built asset.
- A data component, made up of information containers of both unstructured information and structured information.
ISO 19650 is one of many information management standards – it is (currently) information management using building information modelling (BIM). BIM is an information management approach that focuses on structured, schema-based information, often (but not always) integrating geometry.
ISO 16739, Industry Foundation Classes (IFC), is one of many BIM standards and is also the core schema for BIM data exchange.
A digital twin, meanwhile, is an occurrence of the data component which digitally represents a built asset, is continually updated to reflect changes occurring to the physical asset, and can enable decision‑making through analysis, and where appropriate, control of its physical counterpart.
Lost sight
Now that’s over and done with, let’s talk about the issue at hand here. The UK is no doubt a leader in terms of information management in the built environment. However, in terms of structured information following industry standards (BIM), we’re lagging. Look to the Nordics and parts of Asia if you disagree.
I celebrate our energy around information management. However, somehow, we’ve decided that BIM is the old and information management is the new. Many seem to think about BIM as in BIM Level 2, 1192, geometric models, and clash detection. Yes, I totally agree, we’ve moved on from all of that. But we’ve lost sight of what the real intention of BIM was.
BIM is, was, and always has been about trying to shift people from unstructured information towards schema-based information exchange using standards like IFC. The same people who think BIM is about geometry are the same people who think IFC is a pdfb of a BIM model. IFC is the core data structure for the built environment, if BIM is the movement from documents to data, it’s IFC that provides most of the answers to that.
So, back to the draft revisions. In the introduction to the revised Part 1, the standard acknowledges that information management is broader than BIM, and that historical interpretations of BIM have focused too narrowly on 3D modelling.
Definitions
You would expect that the standard would then either decide to draw a clear definition as to what BIM is, or to shift the language away from BIM and towards information modelling. Instead, we get a definition in this introduction as to what they deem information modelling to be, but this definition does not make its way into the terms and references section and so is not being recognised as a definable term.
Equally confusing, building information modelling (BIM) remains as a term. However, the definition has changed to “assembling, organising and interrelating containers to form a digital representation of an asset and using this to facilitate design, construction and operational decision making”. This definition flies very close to what many believe a digital twin to be and simultaneously forgets that BIM is about structured information, which is schema-based and often (but not always) integrates geometry.
In my view, Part 1 needs to do one of two things:
- Keep the BIM terminology, but distinguish it from broader information management. Building information modelling being data science for the built environment, all about structured information, schema-based and capable of integrating geometry; or
- Ditch the BIM terminology altogether and commit to information modelling. However, in doing so, this must be fully defined and should still be as per my definition for what BIM should be.
Despite terminology, in my view, we should be shifting from file-based information exchange to data exchange. When doing so, we should be following industry standards like IFC. We should be thinking about models not as files but as entire data models built in compliance with open standards. This includes data tables about objects and systems, but also beyond that to cover tables like people, tasks, and risks. There’s no greater example of this misunderstanding than my next point.
Why CDEs need to change
First, this is a good opportunity to ensure the understanding of common data environments is correct. Currently, there is an understanding that one technology/platform on a project can be a CDE – however, a project will need to have multiple. This is particularly so considering the different needs of structured and unstructured information.
Second, the understanding in the industry is that CDEs are for unstructured information or for packaged structured information into file-based containers. But that simply should not be the case; it’s called a common data environment, not a common document environment. File-based exchange is necessary, but can’t we move to have both file and data exchange? Here we are stuck in the land of years gone by, as our ‘CDEs’ are simply rebranded document management systems which have barely changed in 20 years or more.
In my view, the Part 1, and then reinforced in Part 2, should explain that projects will have multiple common data environments but a clear ‘source of truth’ for decisions, and that common data environments can and must handle both unstructured and structured information.
Alex Plenty is head of digital construction at Skanska UK
Keep up to date with DC+: sign up for the midweek newsletter.