ICE Knowledge Hub
Access the very latest and best CPD content to help you grow your knowledge and skills.
Ashleigh Rastall, chair of the data and digital task group for the Infrastructure Client Group, explores the evolution of common data environments (CDEs).
Infrastructure projects generate vast amounts of data.
In 2018, a study found that a large infrastructure project will require an average of 130 million emails, 55 million documents and 12 million workflows.
A lot of this information will be managed on different platforms, stored using varying naming practices and require various levels of access.
This causes headaches for project teams all across the industry.
Common data environments (CDEs) have become a central pillar of how projects manage information.
In simple terms, a CDE is a shared space where project information is stored, managed, and distributed so everyone works from the same, trusted data.
Yet despite widespread take-up, frustration remains. Projects often struggle with rigid systems, duplicated effort, and poor integration between tools.
This has sparked an important industry debate: should clients enforce a single, standard system, or is it time to embrace more open and connected data ecosystems?
Recent discussions within the Infrastructure Client Group’s Data and Digital Task Group suggest that the answer lies somewhere in between.
Mandating a single, client-owned CDE can appear attractive. It promises consistency, security, and clear control. However, in practice it often creates new challenges.
Delivery partners may be forced to adapt their workflows to unfamiliar systems, duplicate information across platforms, or absorb additional licensing costs.
Over time, this can stifle innovation and reduce collaboration rather than enhance it.
A key issue is that too much emphasis has historically been placed on software, rather than on how information itself is structured, governed, and shared.
When the system becomes the focus, data risks becoming trapped inside privately owned tools, limiting its long-term value.
In response, the debate points toward a shift in thinking: from single systems to common data ecosystems.
An ecosystem approach recognises that different tools excel at different tasks.
A document management system, a design model platform, an issue tracker, and a geographic information system (GIS) may all coexist - but crucially, they are connected rather than isolated.
What holds this ecosystem together is interoperability, meaning systems can exchange information reliably.
This is achieved not by custom one-off integrations, but by agreeing common standards for data structure and exchange.
Standards such as ISO 19650 (which sets out how information should be managed in BIM-enabled projects) provide a shared framework, while newer standards like ISO 55013 encourage organisations to treat data as a managed asset in its own right, rather than a by-product of delivery.
In practical terms, this means data can flow across organisational and technical boundaries while still preserving the idea of a “single source of truth”.
Another major challenge highlighted is that many CDEs remain document-centric.
Information is uploaded as static files, governed by naming rules and folders, but rarely structured in ways that support automation or insight.
This limits the ability to reuse data, connect it to asset management systems, or feed digital twins and analytics tools later in the lifecycle.
A data-centric approach shifts focus from files to information containers with meaning. For example, structured models, datasets, or issue records that can be queried and reused.
Achieving this requires upfront agreement on data requirements, classifications, and metadata, as well as ongoing governance to ensure quality.
Technology alone is not enough.
The debate strongly emphasises the role of data governance, meaning the policies, roles, and controls that ensure information is accurate, secure, and fit for purpose.
In an ecosystem model, governance is often federated: responsibility is shared across organisations, but rules around access, approval, and audit are consistently applied.
Contracts also play a critical role. Information management requirements should be clearly embedded within appointments, referencing standards, exchange formats, and expected behaviours.
Performance-based clauses, such as requirements to deliver data in open, non-proprietary formats at project close, help protect long-term value and avoid locking in the information.
Importantly, projects are encouraged to conduct a form of “stakeholder rehearsal”.
By testing the CDE against the real workflows of designers, contractors, and asset managers, teams can identify pain points early and ensure the environment genuinely supports collaboration across the lifecycle.
Perhaps the most important takeaway is to avoid binary choices. The future is not about choosing either a single closed system or complete openness.
Instead, organisations should assess their capability, project complexity, and partner relationships, then design an approach that allows for growth and adaptation over time.
As infrastructure projects increasingly incorporates real-time data, sensors, and digital twins, openness and connectivity will become non-negotiable.
The CDE of the future may not look like a single platform at all, but rather a well-governed web of connected services, each optimised for purpose, yet united by shared data standards and principles.

ICE Policy Fellow Paul Mullett takes a critical look at the Competition and Markets Authority's findings and wonders, “are we brave enough?”

Sir Andrew Mitchell, who led the delivery of London’s new super sewer, was recognised for services to the construction industry.

Mentors are needed for the 2026 ICE CityZen Award and Pollution Control Challenge.