The Common Data Environment: why buying the software is not the same as having one

Who this is for

• You are being sold a CDE and want to know whether the thing in the demo is a methodology or a hard drive with a login page.
• You are writing or answering an ISO 19650 requirement and need the four states to mean something operational rather than diagrammatic.
• You are about to hand a finished building over, and nobody has yet worked out how the model's data reaches the maintenance system.

What the episode says

Transcript

Transcribed from the recording and lightly edited: mis-heard technical terms and broken sentence boundaries are corrected, nothing said was changed or added to. Views expressed are the presenters’ own. The voices in the recording are synthesised with AI, produced with Kamilla Drożdż; the words are the presenters’.

Imagine it is 2021 and there's this massive multi-million dollar infrastructure project and it just grinds to an absolute halt. Just a complete nightmare scenario for anyone involved. Oh, exactly. A contractor has just poured a colossal amount of concrete for a bridge foundation, but there's a fatal problem. Yeah, the blueprints.

Right. They poured it based on a schematic that was named like Foundation Plan 2 instead of Foundation Plan 2 final. Which is such a classic tiny naming error - but the impact is catastrophic. The rebar layout is completely wrong for the structural load. So it all has to be demolished, pushing the timeline back by months and burning through millions in budget.

And the really frustrating part of that scenario is that the correct file actually existed. Like it was sitting right there on a server. Just hidden in some folder somewhere. Exactly. But because there wasn't a rigid governed structure dictating exactly how that data was authorized and shared, the wrong version made its way into the hands of the people pouring the concrete.

Which brings us to our focus today. Welcome to the deep dive. Today we're looking at something that if you're managing any complex project, whether you are literally building a highway or you're, I don't know, coordinating a massive global software rollout, you need to know about. Because you have to know how to manage the sheer avalanche of data without something critical falling through the cracks.

Right. So we are taking a deep dive into the digital architecture designed to prevent that exact concrete catastrophe. It's called the common data environment or the CDE. Yeah, and it's a concept that has essentially become the central nervous system of modern architecture, engineering, and construction. But the underlying principles apply to almost any discipline where complex info changes hands rapidly.

Okay, let's unpack this because before we can understand how a CDE works, we have to clear up what it isn't. The industry seems to be suffering from this massive misconception. Oh, definitely. The marketing hype is out of control right now. Right. Like if you look at the software market, every vendor is slapping a CDE sticker on their product.

But buying a specific software license doesn't magically mean you have a common data environment. No, it really doesn't. That is the trap, right? People confuse buying a tool with implementing a methodology. And under ISO 19650, which is the international standard governing all of this, there's a very sharp distinction between an electronic document management system and EDMS and a true CDE.

So what's the actual difference? Because they both just hold files. Well, an EDMS is fundamentally just a digital storage unit. Think of standard corporate SharePoint setups or Dropbox. They're built for storing, organizing, and retrieving files. But A CDE is defined as an agreed source of information and a strictly managed process.

The analogy I keep coming back to from the sources is, well, it's like air traffic control. An EDMS is just a massive stretch of tarmac. You can park your planes, your files, I mean, anywhere you want. It holds them perfectly fine. But a CDE is the entire air traffic control tower. It's the radar, the communication protocols.

Yeah, it dictates exactly who is allowed to land, what runway they must use, and when they are cleared for takeoff. You can't just buy a stretch of asphalt and claim you have a functioning airport. That is a highly accurate way to look at it. Yeah. What's fascinating here is that if you look at some of the British standard guidance documents, they point out a technicality that kind of bends the mind a bit.

You could theoretically run a fully compliant CDE using a physical postal service and a room full of hard copy filing cabinets. Wait, really? An actual postal service? Yes. But that completely undermines the idea that a CDE is like an IT product, right? Exactly. Because it's all about the workflow, not the tech. If that physical mailroom operates with airtight protocols for how a document is logged, stamped, reviewed, and distributed, it actually meets the requirement.

The software just makes executing that process possible at scale. I mean, going back to your gym analogy earlier, or a similar idea, having a gym membership doesn't make you fit unless you follow the workout process. Right, buying the app doesn't do the push-ups for you. Exactly. So there are really five critical indicators that you're looking at a true CDE process rather than just a glorified hard drive.

Okay, what are they? First, the technology has to support a structured process. Second, it must act as a single source of truth. To prevent people from working off old data. Right. Third, it demands incredibly robust version control. Let me stop you on version control, actually, because from my experience, if users don't trust that they are looking at the absolute latest blueprint, they'll just bypass the system entirely.

Oh, immediately, they'll start texting each other. Yeah, or emailing PDFs just to get quick answers. and then that whole single source of truth just shatters, which is why the version control has to be completely foolproof.

The 4th indicator is effective lifecycle management. The system has to adapt as a building moves from a purely conceptual design into physical construction. And then into decades of maintenance, presumably. Exactly. And 5th is scalability. The system can't just buckle under the weight of hundreds of thousands of files once the project ramps up.

Okay, so if a CDE is fundamentally this managed workflow, let's trace that flow. How does a piece of data actually travel through this environment? So the international standard maps out a journey for what they call an information container, which is just a fancy term for a file or a data set. And it moves through four very specific states.

Work in progress, shared, published, and archived. These 4 states are the absolute core of the whole methodology. Okay, I want to relate this to something everyone listening deals with daily, like the email analogy from our sources. So the first state is work in progress or WIP. This is highly isolated. Like this is the structural engineering team actively tweaking a load calculation.

And crucially, the rest of the project team cannot see it. It's like drafting an email. Exactly. That invisibility is paramount. If you're drafting an email and you're half finished, You wouldn't want the recipient reading it live as you type. No, that sounds terrifying. In construction, if an architect's WIP drawing of a modified floor plan is visible to everyone, an overeager plumbing contractor might just see it and start ordering pipes.

For a layout that hasn't even been finalized. Right. It contains the blast radius of early stage changes. So the team finishes their internal work, they review it, and it moves to the second state, which is shared. Sticking to our analogy, this is like sending that draft email to your manager for approval. Yes. The information is now visible to the broader project team.

But, and this is key, it is not authorized for construction yet. It's shared purely for coordination. This is where clash detection happens, right? Exactly. The mechanical engineers look at the shared architectural model to ensure, say, a major air conditioning duct doesn't suddenly run straight through a steel beam. But if I'm a contractor on the ground and I can see this shared file, what physically stops me from building off it?

Like is there a lock on the file? Well, there isn't necessarily a physical lock preventing you from opening the PDF. What stops you is the strict contractual agreement and the metadata embedded in the file, which dictates its status.

So if a site manager builds off a file marked shared for coordination and it turns out to be wrong, the liability falls entirely on them. they violated the CDE protocol. Got it. So they check it, and if there's a clash, the duct hits the beam, it gets rejected. It bounces back to the work in progress state, like your boss telling you to rewrite the email.

Yep, and the engineers have to try again. But if it passes all the coordination checks, it gets verified, authorized, and advances to the third state, published. That's hitting the send button on the email. Exactly. Published is the holy grail. This is the only information authorized for execution. If a contractor is pouring concrete or, ordering millions in steel, they pull exclusively from published containers.

And finally, there is the 4th state. The archive is like your email client automatically saving the whole thread in your sent folder. But initially, this just sounds like standard backup storage to me, a digital basement. It's far more active than that, actually. The archive is the legal armor of the project. It's the irrefutable journal of all transactions, alterations, and approvals.

So it's about liability. Totally. Let's go back to your scenario of the bridge foundation failing. When a multi-million dollar dispute arises, the archive is what the lawyers look at. the exact time-stamped audit trail. It determines who authored the flawed design, who reviewed it, who changed its status to published, and exactly when they did it.

completely removes the he said she said from project management. That makes total sense. So we have these four distinct states, and on a massive development, you might have 50,000 files ping-ponging between WIP shared and published. You can't track that with just basic file names, right? So the mechanism driving this entire workflow is metadata, and that is what keeps the chaos at bay.

Metadata is the DNA of the CDE. ISO 19650 requires highly specific metadata assignments for every single container. And we aren't just talking about basic file properties like file size or creation date. We're talking about strict mandated codes. Right. You need a revision code, a status code like S1 for coordination or A3 for authorized, and a classification code.

Like Uniclass 2015, which the industry uses a lot. Exactly. So a file isn't just named HVAC plan final. It carries a machine-readable tag, say PM4030, which strictly defines it as design information for a specific system. That's how you prevent the database from devolving into a complete black hole. Yeah, when a project manager needs to assess readiness.

they don't open 50 folders, they just query the database, like applying a filter on a shopping website. Basically, they run a filter that says, Return all mechanical engineering models, where the classification is PM 4030 and the status code is A3 for authorized.

If the metadata is applied correctly, the exact required files appear instantly. Okay, but here is where the theory hits the incredibly messy reality of the industry. So what does this all mean when reality hits and different teams use different software? It's a huge problem. Right. On a major project, the architect is likely using one software suite, the general contractor is using a completely different platform, and the client might mandate a third system.

If the CDE is supposed to be seamless, how does that rich metadata survive the jump? That interoperability friction is arguably the biggest headache in the sector right now, because there isn't a universal exchange protocol. Unlike email where we have POP or IMAP. So A Gmail client renders an Outlook message perfectly.

Right, construction tech doesn't really have that yet for exchanging customized metadata fields. So let's say system a relies heavily on complex tags for that uniclass status.

But the files need to be handed over to System B, which just has a rigid, older architecture. And it doesn't recognize the tags. It doesn't. So if you just transfer the file, the metadata is stripped away. The DNA is erased. and the file becomes dumb again. So how do they get around that? Do they just manually retype everything?

Because that sounds like a nightmare. Sometimes they do, which is incredibly inefficient. But one of the fascinating real-world workarounds developed by groups like the UK BIM Alliance involves mapping metadata to physical folder structures. Wait, mapping it to folders? How does that actually work mechanically? I mean, we just said folders were bad.

I know, it's ironic. Essentially, you build a script that reads the metadata in system a and automatically generates a nested folder path reflecting that data. So it creates a main folder for the status, a subfolder for the revision, and another subfolder named exactly after the classification string, like PM 4030. And it drops the file at the end of that path.

I see. So when system. B ingests the package. It doesn't look for internal file tags. It parses the text of the folder path itself to reconstruct the metadata on its end. Exactly. That sounds incredibly fragile. Like if a single user accidentally drags a file out of that specific PM 4030 folder and drops it one level higher.

The script parses the wrong string and the classification breaks entirely on the receiving end. Wow. It is incredibly fragile. Which really highlights a massive realization. We spend so much time talking about APIs, classification codes, and digital states, but none of this architecture survives without a very specific human architecture enforcing it.

Yes, and here's where it gets really interesting, because it is tempting to look at a CDE as a purely IT implementation challenge. You buy the software and you're done. Exactly. You buy the server, set up the software, and walk away. But the literature, especially insights from training organizations, emphasizes that the technology is actually the easy part.

Managing the people is the actual bottleneck - specifically information managers and BIM managers. And these aren't just IT support staff. No, they are the architects of the process. They map the workflows, define the naming conventions, and strictly control the permissions within the tool. But consider the environment they're operating in.

You have veteran engineers, architects, and site managers who've been building things successfully for 30 years using PDFs and emails. And they don't want to change. Right. When an information manager suddenly mandates that every single sketch must be tagged with a four-part alphanumeric uniclass code before it can even be shared, The pushback is fierce.

It just feels like pure administrative bloat to them. That is exactly why these roles require highly developed soft skills, which let's be honest, isn't always the default in purely technical engineering disciplines. Yeah. An information manager has to be part systems architect and part diplomat. They have to convince a stubborn supply chain that this upfront friction actually prevents catastrophic rework down the line.

And if they fail to drive that culture. Users will get lazy. They will default to naming files, final version 2, they'll skip the metadata tagging, and your multi-million dollar ISO compliant CDE immediately devolves back into a chaotic Dropbox folder. So assuming you do have the right human team in place and the workflows are mapped out, eventually you do have to choose the digital environment itself.

True. Which leads us to a massive philosophical split in how data is managed, open versus closed CDEs, and the harsh reality of the building life cycle. Right. So a closed CDE is a proprietary all-in-one ecosystem tied to a single vendor. Everything happens within their walled garden. The appeal there is obvious, right?

It's highly secure, the interface is standardized, and the administration is simple because you only have one vendor to yell at if something breaks. But the cost is heavy vendor lock-in. You're trapped in their upgrade cycles. And integrating specialized outside tools is notoriously difficult. Okay. And the alternative?

On the other side, you have the OpenCDE philosophy. Platforms built specifically for flexibility, like Catenda Hub, for example. They connect to multiple platforms via open APIs. And they support open formats like IFC and BCF. Exactly. So the architect can design in their preferred proprietary software. The structural engineer can calculate in theirs.

but the open CDE acts as the universal translator in the middle. Okay, but even if you solve the open versus closed debate for the construction phase, don't you run headfirst into what's known as the life cycle challenge? Because the reality is no single software tool covers the entire lifespan of a physical asset perfectly.

That's the big hurdle. But let me ask you this for clarification. If the entire goal of a CDE is a single source of truth, isn't it? contradictory that projects have to use multiple tools across their life cycle, like moving from construction software to maintenance software. I get why it feels contradictory. But if we connect this to the bigger picture, the single source of truth is about the integrity of the data at any given moment, not necessarily permanent loyalty to a single software brand.

During the design and construction phase, you use level 3 CDEs, like BIM 360. They're incredibly powerful for handling massive 3D models and real-time site coordination. But eventually the ribbon is cut, the building is finished. The keys are handed over to the client. Right. And the client enters the operations and maintenance phase, the O&M phase.

And this phase doesn't last for three years. It lasts for 50 years. And the facility manager running that building does not need a hyper-detailed 3D rendering of the rebar inside the concrete pillars. Exactly. They need completely different tools, like a computer-aided facility management system or CAFM. platforms like Glider BIM, Cylon, or Concept Evolution.

Right, because they care about scheduling preventative maintenance on the HVAC system or tracking the warranty expiration on the elevators. Exactly, so the data has to migrate. And this transition is where massive amounts of value are either realized or lost. How do you extract the incredibly rich metadata, the serial numbers, installation dates, manufacturer specs from the 3D construction model and map it cleanly into the 2D maintenance schedules of the new system?

Without someone having to manually re-enter data for 10,000 physical assets? Yes. Ensuring data flows seamlessly from the construction CDE into the facility management system is the holy grail the industry is actively fighting to solve. To bring all this theory down to earth, it's fascinating to look at what a massive client actually demands when they pay for a CDE.

The sources highlight the requirements from a major Polish infrastructure client, GDDKiA. Yeah, the National Highway Authority. Right. And when a client of that scale mandates a CDE, they aren't politely asking for a shared folder. Oh, not at all. Their demands are uncompromising. First, they demand no limit on the number of users or the volume of data stored.

And the CDE must be provided free of charge for the client's internal team to access. But the security demands are where the true weight of the system shows. The security is paramount for them. The provider must meet ISO 27001 information security standards. The system demands authenticated logins, encrypted connections, and critically, all data centers hosting the information must be located exclusively within the European Union.

For data sovereignty reasons, obviously. And here is the element that proves a CDE is more than an IT product. The contract mandates that it acts as the official platform for almost everything.

contractor wants to get a subcontractor approved, it must be submitted in the CDE workflow. Material authorizations, CDE, the monthly progress reports that trigger payments. Meaning if it's not in the CDE, legally it didn't happen. It literally becomes the digital legal record of the entire multi-million dollar investment, which perfectly proves why basic cloud storage completely fails in enterprise projects.

A standard file sharing site simply cannot serve as a legally defensible audit trail of workflow states and metadata approvals. So as we wrap this up, what does this all mean for you, the learner? Whether you are building a bridge or you're just organizing a corporate initiative, applying these principles can revolutionize how you work.

It's about committing to a rigorous process, defining your work in progress versus your published truths, and relying on structured metadata instead of chaotic email threads or fragmented folder habits. A common data environment is not a magic piece of software. It's a managed process of states, metadata, and human collaboration.

And I want to leave I want to leave you with a final thought to ponder that extends beyond our current landscape. Right now, as we've discussed, maintaining a CDE requires immense human effort, information managers constantly policing file states. But as we move toward a future of artificial intelligence and digital twins, What happens when the CDE is no longer just a passive repository managed by humans?

Imagine a future where the CDE itself acts as an autonomous project manager. It could use AI to actively analyze metadata in real time, instantly predict construction delays, and autonomously reject flawed designs back to work in progress before a human ever even sees them. That is wild. The database wakes up and starts doing the quality assurance itself.

It would completely change the paradigm. The role of the information manager would shift from enforcing rules to orchestrating high-level algorithms. That is a profound and honestly very plausible evolution of how we manage complex reality. Well, a huge thank you to you for joining us on this deep dive. As you head back to your own complex projects, take a hard look at the mountain of data you're sitting on and keep questioning how your world is structured.

We'll see you next time.