The Problem with BIM
15.12.2025
Author: Jiri Hietanen, CEO and Co-Founder of Datacubist
Executive summary
The mindset that BIM exchange problems are caused by people and software leads to a complex process that has low chances of working in real projects, despite three decades of concentrated international work. At the root of this mindset is the definition of ‘machine readable’ from the 1990s.
Updating the definition of ‘machine readable’ to what it means today, allows us to approach BIM exchange with a new mindset that leads to a significantly simpler process.
This new process is characterized by radically reduced BIM requirements and diminishing reliance on specifications, laws, agreements, model checking, issue management and BIM coordination.
The new process is enabled in practice by a new kind of software like Simplebim® that we have developed already for 16 years and is already in everyday use in thousands of projects worldwide.
There is a problem with BIM
Clearly there is some problem with BIM because it is still not living up to its promise after three decades of concentrated international effort. Over these years there have been a lot of developments that were supposed to fix the situation. These include using XML and later JSON instead of STEP, new IFC versions, model views, model servers, model validation in different flavours, issue management, software and professional certification, model servers, common data environments – and the list goes on.
In this post I’m introducing an explanation and a solution to this situation.
The mainstream BIM mindset
BIM works fairly well in internal use, but the problems really begin in BIM based data exchange. It is a difficult task to get reliable, consistent good quality BIM data from others. The mainstream approach in BIM exchange today tries to solve how to get the designers to deliver such data. With this mindset, we can identify two culprits for the current situation: the people and the software.
Solving the problem of people and software
The problem with people could be solved through education and by setting BIM exchange requirements, even by mandating these by law. But because humans make mistakes, the secondary solution would be to develop model checking formats (like IDS), model checking and issue management software and related communication tools in common data environments, and all this is overseen by BIM coordinators. And because software can cause issues, we have MVDs, software certification and long lists of feature requests to software vendors…
The actual problem is the mindset
This all sounds good – but there are two major problems with this mindset.
The first one is that the whole system is very complex, and complexity always reduces the chances of anything working in real-life situations.
We already proved around 2005-2006 here in Finland in ‘laboratory conditions’, with a lot of research money, that BIM exchange can technically work in real projects. But making the same work in ‘normal’ projects is another question all together. Finland can for example put together nationally one decent soccer team, but this does not mean we Finns as a nation are any good at soccer. In the same way it was possible to set up a winning BIM team already 20 years ago, but this does not mean… you get the picture.
The second problem relates to the timeline. I have personally worked on solving BIM exchange issues already for 28 years. The question is: How much time can we reasonably give an idea, before we start accepting that there might be something fundamentally wrong with it?
Re-evaluating ‘machine readable’
Based on these considerations I’m proposing another mindset. The major goal of BIM exchange is to transfer information in a machine readable form. This is what makes BIM different from drawings and other documents, it’s kind of the whole point of the exercise. This remains true, but the international BIM community has been marching on since the 1990s without ever really stopping to re-evaluate what ‘machine readable’ means, even though nobody in their right mind would argue that machine readable today means the same thing as machine readable 30 years ago! Our common goal on the ‘idea level’ is still the same, but at the same time it has changed on the ‘technical level’ and we need to acknowledge this change.
‘Machine readable’ in the 1990s
The 1990s definition of machine readable is very strict and the current use of the IFC model reflects this. If you want for example to exchange a piece of information, you need to use exactly the right IFC object class with the right predefined type. Then you have to use an exact property set and property, both of which must be spelled exactly right, including spaces and upper/lowercase characters. Finally, you must use property values that are again exactly from a list of allowed values again with exactly matching spelling. Only when all this is in place, is the result considered to be ‘machine readable’.
‘Machine readable’ today
But really: Does anything else you do on your computer today work any more like this? At the time, the reason for that strict definition of machine readable was limited computing power and limited software capabilities.
Now that we have more powerful computers and more advanced software, we should be able to loosen up the definition of machine readable. In practice this means that we can have less BIM requirements and related laws, specifications, agreements, model checking, issue management and BIM coordination – and still reach the desired machine readability.
No, I’m not talking about AI
Now you might immediately think of AI, but in this picture, AI is just the tip of the iceberg. AI can be part of the solution, but it is not the full solution – and most things can be solved without AI, using this new mindset.
What do you trust?
Over the years, it has turned out that in real use one of the key factors in BIM exchange is “trust”. The question is: What we choose to trust?
This is a complex question, but the short answer is that we can trust information model authors needs for ‘their own’ work. And we can trust this information most, when it is structured in a way that ‘that’ model author understands and uses anyway. We can for example trust that an architect gets the name of a room right, because rooms are essential to the architect’s own work. But we can have less trust in the exact spelling (‘Electrical Room’ might be ‘ELEC’) and even less trust in the mapping of this information to IFC (the information might be in a custom property). But what if it is enough just to have the room name written in an understandable way, anywhere in the model? If this was possible, we could drop almost all current BIM specific requirements related to room names, and only the pure information requirements would remain.
New mindset, new kind of software
You can see that re-defining machine readable by itself, as an idea, does not solve anything in real life, but it opens our eyes to new possibilities. We can start thinking about what kind of software we need for making this idea work.
Luckily, we started on this track already 16 years ago with the development of Simplebim: We can’t expect every software to embrace and implement this contemporary definition of machine readable, but we can have software that bridges the semantic gap between humans and computers, letting humans be humans and still getting the automation benefits of BIM.
Enter dataflows with Simplebim
In Simplebim the room name example would work like this by using a dataflow, that is defined once and re-used for fully automating the process.
First, we need to find the room objects, typically IfcSpace objects; but not all IfcSpace objects are rooms, because there can also be gross/net areas, apartments and similar. For Simplebim, the rooms don’t necessarily even have to be IfcSpace objects. Then, for the room objects, we scan typical properties for the room name information, adding new properties to the list as needed. Next, we copy the room name from where we found it to where it should be according to the strict definition of machine readable, which is the LongName property of IfcSpace. Finally, we can do simple find and replace operations to replace for example ‘ELEC’ with ‘Electrical Room’.
If needed, we can even convert the object class – for example from IfcBuildingElementProxy to IfcSpace. We can also calculate quantities and dimensions from the room geometry, generate floor and wall surfaces, associate windows, doors, electrical outlets etc. with rooms and so on.
The last step is to export the result back to IFC and use in any IFC enabled application.
A better process solves the problem
For the BIM process this means, in our example, that the architects still can’t do whatever. The requirement remains that rooms must be modelled with appropriate geometric accuracy and that rooms must be given a name. But these are all things that we can trust the architect to get right, because the architects need this information also for ther owi work. What changes is that we are no longer requiring things that architects do not need or understand, such as using IfcSpace, predefined type SPACE, IfcSpace.LongName and that space names must be exactly from our own list. Some things are also clearly out-of-scope for architects, for example associating electrical outlets with rooms, which would require merging the electrical model.
In the end, all this simplifies the BIM exchange process significantly – and makes it much more likely that even a 3rd division soccer team will score a goal in every game!
About the author
Jiri Hietanen is Co-founder and CEO of Datacubist and the principal architect of Simplebim. Trained as an architect, he has over 25 years of experience in IFC, BIM and software engineering, with a focus on finding new solutions for scalable BIM data processing, automation, and OpenBIM workflows.
