The ‘Common’ in Common Data Environment

1. Introduction

1.1. Why the Word “Common” deserves Scrutiny

Let’s get something out of the way: in the world of digital construction, “common” is a loaded word. It evokes a sense of unity, standardisation, and shared purpose. It conjures images of centralised vaults of truth — the One Platform to rule them all — with neatly structured folders, managed with military precision by your legion of orcs, governed by iron-clad access rights.

But common isn’t synonymous with centralised, and a Common Data Environment — the mythical CDE sung in the verses of ISO 19650 and whispered about in coordination meetings — isn’t a monolith. Instead, it’s something far more unruly. And far more powerful.

The problem? We’ve taken the word “common” and shackled it to a 1990s concept of file servers. We’ve turned it into a synonym for “shared drive with rules,” with a dash of Autodesk Construction Cloud or Aconex on top. We think common means everyone uses the same tool the same way all the time. That’s not common. That’s uniform. And if science fiction has taught us anything — from The Matrix to the Borg Collective — enforced uniformity kills creativity, flexibility, and freedom.

The common in CDE needs to be reclaimed not as a synonym for sameness, but as a rallying cry for interoperable connection, shared intent, and coordinated freedom.

1.2. The Misconception of the CDE as a Single Tool

I know many of you are very familiar with the concept, as it’s spelt in clear letters across the ISO 19650 series, but I recently stumbled upon a set of situations where I realised it’s worth repeating this: somewhere along the line, someone decided that digital transformation in construction meant buying software. That someone was selling software, of course. They got people convinced that the Common Data Environment was something you could install, subscribe to, or lock into a five-year enterprise contract. If your BIM execution plan reads “our CDE is [insert vendor here]”, congratulations — you’ve missed the point.

A Common Data Environment is not a platform. It’s not a folder structure. It’s not a feature checklist in a procurement spec. It’s a strategy that combines processes, tools, and human behaviours to ensure that the right information gets to the right people, at the right time, in the right format. If it sounds difficoult, that’s why we need a CDE manager in the first place.

Think of it like a well-run rebel alliance: the pilots don’t all fly the same ship; the engineers don’t all speak the same language; robots are welding stuff five minutes before launch. But they share a communication protocol, a control centre that coordinates the attack, and a common mission. That’s the Common Data Environment: not the tool, but the glue that makes different tools work together without forcing them into a one-size-fits-all regime.

Best practices, particularly in the context of ISO 19650, reinforce this: the standard explicitly doesn’t define the CDE as a product, but as a set of capabilities to collaborate, share, review, and approve. These can — and should — span multiple platforms. What matters is the interconnection, not the interface.

If we want a CDE that supports digital delivery in the real world — a world of messy legacy systems, fragmented supply chains, and varying digital maturity — then we need to shift the conversation from “What tool do we use?” to “How do our tools talk to each other?” From “Where’s the folder?” to “Where’s the workflow?” From compliance to connection.

Are you ready to see how?

2. Designing a CDE that’s really Common

2.1. Principles of Interoperability

If “common” doesn’t mean same, then what holds a Common Data Environment together? One word: interoperability.

Defined by the European Union’s Interoperability Framework (EIF), interoperability is:

“The ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between organisations, through the business processes they support, by means of the exchange of data between their ICT systems.”

Not integration. Not standardisation. Not vendor consolidation. Exchange. Interaction. Purpose.

This is the conceptual spine of a truly “common” environment. Interoperability is what allows different teams to work with different tools, yet contribute to the same digital project without friction or rework. It’s the difference between a jazz band and an assembly line: the players aren’t using the same instrument, but they’re playing the same tune.

In the world of Building Information Modelling, ISO 19650 embraces this: the standard outlines functions, not platforms; it describes processes, not software; it calls for well-structured information to move between parties, not for everyone to open the same interface.

Yet many CDE implementations betray this principle and trade the messy, pluralistic nature of real projects for the illusion of control: “If everyone uses our platform, there won’t be problems.” But here’s the rub: in practice, there will be. No contractor, architect, or supplier is an island; everyone brings their own tech stack, their own standards, their own scars. A Common Data Environment doesn’t erase that complexity: it embraces it, and makes it work.

2.2. The Role of APIs and Middleware in Connecting Tools

In video game terms, think of your CDE like a multiplayer open-world RPG. Not everyone’s playing the same class or even on the same console, but the server — the glue — makes sure actions sync up. The middleware is your glue.

In technical terms: APIs (Application Programming Interfaces) and middleware layers are what allow your various tools — authoring platforms, document management systems, field apps, databases — to talk to each other. They’re the unsung heroes of the Common Data Environment. They don’t show up in flashy BIM dashboards, but they’re what makes the difference between a siloed dataset and a truly connected digital workflow.

Want to automatically push approved drawings from a modelling tool into a CDE and notify the site team? You need to leverage APIs. Want to sync metadata from your asset database into your GIS system? You need APIs. Want to build a dashboard that aggregates model status, issue tracking, and progress photos from three different platforms? You guessed it.

Middleware isn’t a luxury. It’s the translation layer of the modern CDE, and it’s the enabler of federated environments, where different tools retain their local independence while contributing to a shared digital narrative.

Relying solely on manual uploads and folder permissions? That’s not a CDE. That’s a digital filing cabinet. And in 2025, we should be doing better than that.

2.3. Ok, but what are these API things?

You can skip this part if you know, but do you really know? If the word API is making your eyes glaze over, you’re not alone: for most people working in architecture, engineering, or construction, API sounds like either a brand of screws or a bit of technical black magic best left to the IT department, and that’s why we’re struggling with integration: we lack the basic knowldge to duct-tape our tools ourselves, and relying on third-parties isn’t working.

Understanding what an API is — even in simple terms — can change the way you think about how tools should work together. It’s the starting point to stop being stuck with disconnected apps and start building a truly integrated Common Data Environment

So. Here goes.

Imagine you’re the waiter in a fancy restaurant. You have clients on one side, and they have no idea of what happens behind the kitchen’s closed doors (trust me, it’s better that way). You have the kitchen staff on the other side, and they lack the skills to be in direct contact with people (if you’ve ever met a chef, you know what I’m talking about).
On one side, the client places their order through their specific set of codes (by pointing at a menu, for instance). “One pizza, extra olives.”
On the other side, the order needs to be brought to the kitchen using their specific language: “One pizza, extra olives” becomes “one 24 at nr.12, olives ++”. When the pizza is ready, the kitchen signals it using the bell, and you can bring it to the client, translating back, “Here’s your pizza, sir, with extra olives. Enjoy your meal.”
The API for the client is in plain language; the API for the kitchen is the set of codes associated with each dish.

Now here’s the catch.

The APIs alone won’t produce a pizza, nor will they bring it to the table. In short, if you’re the waiter, you’re the programmer who, knowing both languages, can provide that valuable connection. But the connection still needs to be produced. By you.

Still with me? Let’s get even more practical. Here are some real-world CDE use cases where APIs are making communication possible, and someone else already coded a mechanical waiter to do the heavy lifting for you.

• Model coordination: Solibri checks model clashes, then automatically sends issues to BIMcollab or Jira via API, so the right person can fix them without double entry;
• Field apps and site photos: a field management app like PlanRadar collects snag photos on-site, and uploads them to a central platform, where they’re linked to rooms and drawing references;
• Power BI dashboards: instead of exporting CSVs manually, APIs let dashboards pull live data from multiple platforms (like Autodesk Construction Cloud, as we’ve seen a couple of months ago), updating daily without human input;
• Automatic version control: when someone uploads a new version of a model to a design platform, an API makes it possible to alert the project team on Microsoft Teams or Slack, instantly and accurately.

None of these happened by magic: someone within the software houses decided they wanted to open that specific function and someone else encoded that instruction in a piece of software.

Now, I think I know what you’re thinking.

So… do I need to learn How to Code?

Not really. Unless you want to, coding isn’t your job here.

What you do need to understand is that the presence of APIs just means that integration is possible, but someone still needs to craft it. None of the integrations we just described happened by magic: someone at the software house decided “this is a function worth exposing”, and someone else — a programmer, the waiter in our restaurant metaphor — wrote the instructions to make it usable.

Your role might be different if you’re on the demand side of the equation. You need to be the restaurant owner bold enough to ask:

• “Can this platform talk to that one?”
• “What APIs are available, and which functions do they expose?”
• “If I want workflow X automated, does the software even allow it?”

You don’t need to know how to carry the plates back and forth from the kitchen — but you do need to know that you need to hire professional waiters, and that if the restaurant refuses to let them do their job, this means no pizza, which is very sad indeed.

2.4. What about Middleware?

The connection often isn’t a full-blown product, with a fancy interface, that everybody can use. That’s what we mean by middleware: the glue that connects different systems so they can work together without you having to move data around by hand.

Think of it as the automation layer that makes APIs practical. APIs open the doors, but middleware is what walks through them, carrying information from one room to another at the right time, in the right format.

Practical Examples in Construction

1. Automatic model publishing:
   • Without middleware: a modeller finishes their Revit file, manually exports an IFC, uploads it to a platform, and emails the coordinator;
   • With middleware: the middleware has a button in Revit (via API), the modeller pushes it and it triggers an export on save, checks naming conventions, and uploads the IFC automatically to the right folder in the CDE, moving the task to the correct folder in Trello and pinging the coordinator in Slack.
2. Issue management between tools:
   • Without middleware: clash issues identified in Navisworks are exported to XML, imported into Excel, reformatted, and uploaded into BIMcollab;
   • With middleware: the middleware does the heavy lifting once the XML is out, pushes issues directly to BIMcollab (or Jira, or whichever issue tracker), assigning them to the right people with zero manual steps.
3. Document synchronisation:
   • Without middleware: the site team uses one app for snagging, the design team another for drawings. Snag reports are emailed, then copied into PDFs in the CDE.
   • With middleware: snag data is automatically synchronised between the field app and the central CDE, so that drawings and issues always align.
4. Dashboards and reporting:
   • Without middleware: every Friday, someone downloads progress data from Primavera and cost data from SAP, then uploads them into Power BI.
   • With middleware: APIs feed live data into Power BI every night. Dashboards update automatically, no human bottlenecks.
5. Asset information handover:
   • Without middleware: data in accordance with the COBie scheme is emailed around, validated by hand, and uploaded into the CAFM system.
   • With middleware: data in accordance with the COBie scheme is validated automatically against requirements and pushed into the facilities management platform directly.

Middleware in the Wild

You’ve probably already seen middleware in action, even if you didn’t call it that. Examples include:

• iPaaS (Integration Platform as a Service) tools like Zapier, Mulesoft, or Microsoft Power Automate, connecting hundreds of apps without custom coding;
• AEC-specific connectors like BIM 360–Power BI integration, we’ve seen here or ACC–Procore sync;
• Custom scripts and plugins built with Python, Dynamo, or Node.js that shuttle data between platforms.

Why Middleware Matters for the CDE

The core idea is simple: without middleware, a CDE collapses into a shared folder system. Every data handoff depends on humans exporting, uploading, and emailing. And that’s not an environment: that’s paperwork with a digital face.

With middleware, the CDE becomes what ISO 19650 envisions: a living ecosystem of connected functions — collaboration, review, approval, archival — happening across platforms without bottlenecks.

Middleware makes sure your tools work together.

Conclusion: Building a CDE That Actually Works

So what does “common” really mean in a Common Data Environment?
Not sameness. Not a monolithic platform. Not endless folder structures policed like some digital dystopia. Common means connected. It means your tools, your teams, your processes can talk to each other without you having to play postman between systems. It means workflows that flow, not workflows that choke.

But this doesn’t happen by magic. To build a CDE that lives up to the spirit of ISO 19650, you need to design it deliberately, strategically, and with the right mix of people and technology.

Here’s your checklist to do so.

The Common Data Environment Checklist

• Clear Information Requirements
  Define what data needs to move, in what format, at what stage (EIR, AIR, PIR). Without this, your CDE will just be noise.
• Workflow Design
  Map the flows: who approves, who publishes, who reviews, who archives. Then identify the points where automation can replace manual effort.
• Open Tools
  Choose software that doesn’t lock you in. Look for platforms with open APIs, support for standards, and flexible connectors.
• API Keys in Place
  APIs are doors. Keys open them. Make sure you have access to the keys (sometimes vendors keep them locked unless you ask, or they’re behind a different paywall than the tool itself). Without them, your “integration” is marketing hype.
• Middleware Strategy
  Decide how you’ll connect systems: Zapier for quick wins, Power Automate for Microsoft-heavy workflows, or enterprise iPaaS for larger projects. Don’t settle for “manual upload” as your default.
• Automation Expertise
  Someone on your team (or close to it) needs to be the automation expert. Not necessarily a full-stack developer but a person who understands workflows, can wrangle APIs, and isn’t afraid to build and maintain integrations.
• Governance and Culture
  Remember: technology is the easy part. People are harder. Train teams on how to use the environment, explain why workflows matter, and keep governance light enough to support flexibility but strong enough to ensure accountability.

The CDE is not a single platform but an ecosystem: federated, interoperable, alive.

If you want compliance, you can buy a tool and use it as an archive. If you want connection, you have to design an environment. And if you design it right, your CDE won’t just be common: it’ll be extraordinary.