Data Exchange Digitization October 18, 2026 · 10 Min. · DE

Beyond the BIM File – from the digital model to the digital enterprise

A lot has changed in recent years. Especially the rapid developments surrounding artificial intelligence are constantly bringing new technologies, opportunities, and a veritable flood of information.

"With everything moving so quickly, I increasingly wonde whether we are still giving enough thought to the problem we actually want to solve (and need to solve) in AEC. No matter what we do, the next step often seems logical and inevitable – after all, „that’s the way it’s done“. But is it really?

I keep noticing that many in the AEC industry believe that the digital transformation is almost complete, just because they are successfully working with highly detailed BIM models and are already taking the first steps towards AI applications.
But why do we still struggle with the same problems as 10-15 years ago? Information arrives too late, models have to be coordinated meticulously, and with every transition between two project participants, some of the information is lost. How does that add up?

Before we go any further, I'd like to take a quick look back. Although we have often heard about the history of CAD and BIM, I think it is important to recall once again how it all began.

From paper to the digital container

The transition from drawing boards to CAD was undoubtedly a big step. Later on, BIM came along, and from individual lines intelligent components with geometry, properties, and relationships were created. Yet one fundamental principle has changed surprisingly little: We still think in documents and files.
We used to exchange drawings. Today we send a file in RVT, DWG or IFC format. The file is more comprehensive, more intelligent and contains significantly more information – but the principle behind it is basically the same.

A BIM model can quickly become a massive digital container: Instead of extracting the few pieces of information we actually need, we simply ship the whole thing.
Let’s take a simple example: A steel manufacturer might only need certain components, including geometry, material, and a few parameters. Why would they need to download a complete 1 GB model, open it, and then filter out the information relevant to them?

From the perspective of our classic BIM workflow, this is completely normal.

From the perspective of a data-driven workflow, it’s actually quite absurd.

Digitalization is not the same as digital transformation

This is where the crucial difference lies between a company that simply uses digital tools and a true nutzt, und einem echten Digital Enterprise.

Digital transformation doesn’t simply mean running existing processes faster with new software. When I take an analog process and transfer it one-to-one into software, I’ve digitized it—but not necessarily improved it. The more interesting question, therefore, is:

How would we structure this process if data were our starting point from the very beginning?

And with that, the role of our BIM model also changes. The model is then no longer necessarily the package that has to be transported from A to B. Instead, it becomes a source of structured information from which different stakeholders can obtain exactly the data they need for their respective task.

The Dualarity – Customer at the Heart, People as the Soul, Digital as the Oxygen

An interesting concept that fits very well with this discussion comes from Olivier Van Duüren. In his book The Dualarity: Tap Into the Energy of Your Personal and Business Transformation In 2016, he explores how companies can remain successful while continuously evolving.

His approach is based, among other things, on three interconnected principles:

Customer at the Heart: The customer and their needs are at the center.
People as the Soul: People, their abilities, and the corporate culture enable change.
Digital as the Oxygen: Digital technologies are not an additional tool, but a fundamental part of the company.

All three should work together around a common Purpose: The question of why we are doing something and what added value we want to create with it.

What I particularly like about this approach is the realization that technology alone is not enough. No matter how many new tools and platforms we introduce – as long as we do not simultaneously question our processes, collaboration, and thinking, the actual added value remains limited.

Let’s therefore look at how these three principles can be applied to our AEC workflows.

Customer at the Heart – the „customer“ at the center

When we talk about customer focus, in the AEC context we usually think of building owners or future occupants. However, when it comes to data workflows, it’s worth taking this term a little further – because the structural engineer, the cost planner, the steel fabricator, or the construction site team are all consumers of our data. And each of them needs something different.
The structural engineer may be interested in certain geometric and analytical information. Cost planning requires quantities and classifications. The manufacturer, in turn, needs very specific product and manufacturing information. Yet today we often give all parties the same thing: the complete model.

A data-based workflow turns this logic on its head. Instead of asking:

„Which file can I give you?“

we ask:

„What information do you need for your task?“

At first glance, this may seem like a small difference, but it fundamentally changes the architecture of our workflows.

Because suddenly it’s no longer the authoring tool or the file format that is the focus, but the actual needs of the data consumer.

Digital as the Oxygen – Data must be able to flow

What I find particularly exciting is Van Duuren's analogy of Digital as the oxygen of a company.

Oxygen is essential for life, even though we often don’t even consciously perceive it. It must be able to reach wherever it is needed. That’s exactly how digital technologies should work in a modern company: not as isolated solutions for individual departments, but as an integral part of all processes.

I find this analogy particularly apt for AEC.

Because when we look at our current data workflows, we regularly encounter obstacles:

proprietary file formats and different data structures
Manual imports and exports
project-specific scripts
redundant copies of the same information
Lack of context between different systems

The problem isn't necessarily that we lack data. It's how we make that data accessible and exchange it between systems..

And it is here that the difference between a company that uses digital tools and a digital enterprise becomes particularly clear to me.
In a traditional workflow, information is stored in different applications and files. We first have to export, convert, or manually combine it before we can use it elsewhere.
In a data-driven workflow, however, information should be available as independently as possible from the original application.

That’s exactly why I find granular data so interesting. Instead of moving complete files between systems, we can specifically provide the elements and properties that are needed for a specific workflow. A component no longer has to „live“ in a specific file in order for other systems to access it.

One example of this is Autodesk Data Exchange, which allows selected model information to be provided as structured data and used via corresponding interfaces in other applications.

Of course, this does not mean that all information is automatically and in real time synchronized between all applications. Updates, permissions, and supported data structures still depend on the respective workflow and the interfaces used.

Nevertheless, this changes a fundamental principle:

We no longer necessarily exchange files; we exchange only the information we actually need.

This is for me one of the most important steps away from file-based interoperability towards true data interoperability.

This doesn't mean the model goes away.

At this point, however, one thing is important to me: This does not mean that BIM models or files will suddenly become superfluous. For example, a Revit model fulfills many tasks simultaneously. It is a work environment, a database, a geometric model, a documentation basis, and in many cases also part of our quality assurance process. For certain workflows, this combination makes perfect sense.
It becomes problematic only when we automatically assume that Every piece of information must always be transported together with the complete file..

And by the way: This doesn’t only apply to proprietary formats. Even an open format like IFC often relies on the transfer of a complete file in classic exchange processes. Therefore, granular data and classic models are not opposites for me.

We need both – the real question is only which information package is appropriate for which application.

People as the Soul – Technology alone is not enough

And then there is another point that we like to underestimate in technical discussions: people. Van Duüren calls them the soul of the company – and for good reason.

We can build the perfect data platform, API, or cloud infrastructure – but if the involved teams cannot or do not want to adapt their processes, it still won’t be a better workflow.
It is precisely in AEC that we have spent decades optimizing our file-based workflows

We know when a model needs to be reviewed. We know who is releasing a file. We know which version is contractually relevant and how we document changes. These are not unimportant details – quite the contrary.

When we move from files to granular, updatable data, we must therefore also find new answers to familiar questions:

Who is responsible for providing information?
Which version is valid?
Who is allowed to change data?
How do we recognize changes?
How do we document approvals?
Which context must be transmitted along with the data?

In my opinion, the last point is particularly important.

Data are only truly useful when we also understand what they mean and in what context they are used. After all, a single parameter value is of little use to us if we do not know to which component it belongs, where it comes from, and whether we can trust it. That is exactly why, in my opinion, digital transformation is not just an IT project.

Technology can enable the new workflow. However, it must ultimately work for the people and processes behind it.

Performing while Transforming – the balancing act between today and tomorrow

That brings us back to the central idea behind The Dualarity. Van Duüren describes the challenge of working successfully while also continuing to develop for the future.
He distinguishes between Performing, that is, the successful operation of our current business, and Transforming, That is, the ability to question existing processes and develop new possibilities.

And it is precisely in this area of tension that we are also operating in the AEC industry: We ultimately cannot stop all ongoing projects tomorrow and rebuild our entire data landscape. And we should not even try to do that.

In my opinion, the more sensible way is much more pragmatic: Start small. Look for a recurring data exchange that still involves a lot of manual work. Take door schedules, for example: How often do they change? Who needs the information? How often do we manually export and share the data? And could we automate this process using Data Exchange or the AEC Data Model? If we can make this work for one specific use case, we can build on that experience.

That is exactly what Performing while Transforming means to me: We improve our current processes while simultaneously developing the skills we will need tomorrow.