The Ultimate Guide to the Common Data Environment (CDE) in 2024

Information Management and BIM

It wasn’t long ago that ‘information management’ meant wall-to-wall filing cabinets and ‘collaboration’ involved a bumbling fax machine and a trusty red marker.

New tools and technologies have unquestionably transformed the industry. Built assets can now be designed, delivered, operated, and maintained using federated 3D BIM models and information-rich digital twins.

However, with these new BIM processes, come new challenges. Namely around how information is generated, coordinated, and exchanged.

ISO 19650 and the term common data environment (CDE) have evolved to provide an international best practice framework for how information is managed across the full lifecycle of a built asset or project.

What is a Common Data Environment?

Definition

A common data environment (CDE) is a single platform or group of integrated IT solutions which provide a centralised repository for the collection, management and dissemination of project and asset information through a managed process.

Put simply, a CDE is a collaborative environment where all stakeholders on a project or asset work on and share information. The CDE is essential for the effective and efficient implementation of BIM processes and technologies.

The purpose of the common data environment and ISO 19650 is to ensure the right people work on the right information at the right time. Ultimately so built assets and projects are delivered on time, within budget, and to standard.

The CDE represents both technology (the ‘CDE solution’) and a process (the ‘CDE workflow’).

The CDE concept was first established in BS 1192:2007, a superseded British information management standard developed by BSI Group. CDE later evolved through the UK’s PAS 1192-2:2013 (also superseded) and more recently by the international ISO 19650 series.

Importance of the CDE for the Built Environment

Before we delve into the details of what a common data environment is, let’s first establish its importance. What benefits can a CDE provide built assets and projects?

Benefits of a common data environment (CDE):

• Facilitating access to the latest, most up-to-date information within a centralised environment
• Project information is managed in a controlled and secure environment ensuring the right people have the right access to the right information at the right time
• The right information is readily accessible to all appropriate teams, regardless of location or device: i.e., onsite with a mobile device
• An audit trail of information development and exchange is captured across the delivery and operation of a built asset
• Information is progressively developed through a managed process (the CDE Workflow), with permissions controlled accordingly
• Information is coordinated and reused across disciplines and teams, reducing clashes, rework, and duplication
• Greater collaboration is facilitated amongst disciplines and teams, rather working in isolation (information silos)
• Information is clearly identifiable with common standards and associated meta-data (attributes)

What is ISO 19650?

In short, it’s an international best practice process for creating, sharing, and exchanging information on built assets and projects. Where the appointing party (i.e., the client or asset owner) provides clear requirements for information and a collaborative environment (the CDE) within which delivery team(s) can produce information in an effective and efficient manner.

The series is intended for use across all built assets and projects by all parties, including procurement, design, construction, and asset owners and operators.

The standard mandates the use of a common data environment on projects or assets where ISO 19650 is specified.

About the Standard

ISO 19650 is a series made up of six parts: 4 are published and 2 are in development (at the time of publishing this guide). We provide an overview of these in our Ultimate Guide to ISO 19650.

Importantly, clients and authorities may define their own requirements for ISO 19650 and CDEs, as seen in Australia with TfNSW’s Digital Engineering Framework and the Victorian Digital Asset Strategy (VDAS) in Victoria.

Note: The 19650 series “should be applied in a way that is proportionate and appropriate to the scale and complexity of the asset or project” (ISO 19650-1). Many of the concepts and principles contained in the series and the above-mentioned guide may be beyond the needs of your asset or project. If in doubt about your role or responsibilities, please refer to the standards or seek specialised assistance from a qualified third-party.

ISO 19650 Parties & Teams

Before going any further it’s important to understand the ‘who’ of the standard, and to familiarise yourself with its terminology so the industry can speak a ‘common tongue’. Below is an overview of the parties and teams involved in the ISO 19650 information management process, as outlined in ISO 19650-1.

Parties

Teams

ISO 19650 Information Management Process Summarised

Below is a high-level overview of the structured 8-stage information management process set out by ISO 19650. Please read our Ultimate Guide to ISO 19650 to understand the process in greater detail or refer to the standards directly.

Summary of the ISO 19650 Information Management Stages, Phases and Involvement

Information Models

The result of the ISO 19650 information management process is the creation of a project information model (PIM) and asset information model (AIM). These models are repositories of published information that inform decision making by stakeholders around the project or asset.

These information models can include both structured information (geometrical models, schedules, and databases) and unstructured information (documentation, reports and multimedia).

PIM and AIM only contain contractual (authorised) information in the published and archived states that has been authorised by the appointing party. This ensures decision-making, such as the construction of the asset, is not based upon draft or unauthorised information.

Project Information Model (PIM)

The PIM is a collection of information that provides all the information required to carry out the delivery phase (i.e., design & construction) of the asset, in accordance with the appointing party’s exchange information requirements (EIR).

Example of information which may be included: project geometry, location of equipment, performance requirements, method of construction, scheduling, costs and details of installed systems, components, and equipment during project construction.

At the completion of a project, elements of the PIM may be transferred to the AIM to enable the ongoing operation and maintenance of the asset. After which, the PIM is archived enabling a long-term record and audit trail of the project in case information is needed.

Asset Information Model (AIM)

The ultimate output of the information management process is the creation of an AIM, which provides all the information required to perform the operation phase of the asset.

The AIM can include graphical models, non-graphical data and all necessary documentation for the ongoing maintenance, operation, and management of the asset.

Example information includes equipment registers, cumulative maintenance costs, records of installation and maintenance dates, and property ownership details.

Information Containers

ISO 19650 uses the term ‘information container’ to denote files, models, documents, or datasets, etc.

Each information container (i.e., file or set of information) should have a ‘unique ID’ (i.e., file name) to ensure information is easily identifiable and retrievable from the CDE. This will be in accordance with an agreed and documented convention, comprised of one or many fields, separated by a delimiter. Wherein, each field is assigned a value from an agreed and documented codification standard, such as Uniclass 2015.

Recommendations for these conventions might be outlined in your national annex. For example the UK national annex BS EN ISO 19650-2 recommends the following format:

Project – Originator – Functional Breakdown – Spatial Breakdown – Form – Discipline – Number Identifier

Model Federation

Federation involves the combining of multiple information containers (i.e., BIM models) into one amalgamated information model. A federated model can comprise information containers from different parties, teams, and/or disciplines.

The common data environment aids model federation by enabling the controlled and secure coordination of information between varying models and teams.

Delivery teams are required by ISO 19650 to propose a federation strategy as part of their BIM Execution Plan (BEP). This federation strategy defines the proposed approach to break down the information model into one or more manageable units.

Benefits of Model Federation:

• Supports simultaneous working: Multiple components of the federated model can be worked upon simultaneously within a CDE workflow without introducing coordination issues, overwriting edits, or duplication.
• Supports information security: The information model can be compartmentalised according to the security requirements of the asset or project.
• Supports multi-disciplinary collaboration: The information models of various disciplines can be combined into one model, enabling better clash detection and collaboration across disciplines.
• Supports information exchange: The information model may need to be broken down into smaller information containers for easier transferring and accessing. For instance, to reduce file size for remote teams accessing information onsite with poor internet connections.
• Enables large or complex projects to be compartmentalised: for instance, breaking up a highway project into zones.

Graphic illustrates the model federation process. Information containers produced by the task teams are shared into a discipline model, which is later federated into a combined model with other discipline models.

CDE Workflow Overview

The CDE Workflow describes the managed process through which information is produced, shared, and exchanged within the CDE solution.

The CDE workflow was first established in the UK’s BS 1192:2007 and later evolved in the PAS 11920-2:2013 standards, and more recently in ISO 19650.

The workflow is a process where information is controlled across four States:

1. Work in Progress (WIP) – draft information being developed by a task team
2. Shared – information approved for sharing with other appropriate task teams, i.e., for comment or coordination
3. Published – contractual information authorised by the appointing party for a specific use, i.e., for construction
4. Archived – journal of information providing an audit trail of information container development

ISO 19650 Common Data Environment (CDE) Workflow. Source: UK BIM Framework Information Management According to BS EN ISO 19650 Guidance Part C

Characteristics of the CDE Workflow

The CDE workflow is a gated process where transition from one state to another is subject to approval and authorisation at each information container level.

Access is controlled at each State by the CDE solution, ensuring the right people have the right access to the right information at the right time. This safeguards against the misuse of information, such as draft information being used for coordination or decision making.

Note not all information passes all four states, some information may never reach the published state. For example, an initial survey pick-up for planning purposes.

The workflow is also not a linear one-way process. Instead, Information may pass between WIP and shared states several times before being eventually published. Information container development can involve multiple iterations, multiple reviews, approvals and authorsations, and multiple ‘journal entries’ into the archived state.

A summary of the CDE workflow process, including states, steps and parties as specified in ISO 19650-1 and ISO 19650-2.

Work In Progress (WIP) State

The work in progress (WIP) state is where information is created and amended by the task team responsible for its production. Authors produce information which they control and check, only sourcing approved information (shared or published) through reference, federation, or direct information exchange.

WIP is the only state where information is editable and where information development occurs.

Information in WIP is draft information that is unapproved for sharing outside the task team responsible for its creation. Access is controlled accordingly by the CDE solution to prevent other parties from viewing, working on, referencing, or issuing draft information.

At any time, information can be rejected and returned to a WIP state for amendment or further development, with the exception of information that has been archived.

Even if an information container is shared or federated, responsibility for the information remains with the author(s) that produced it.

Important: although WIP information is not shared or coordinated it should still be created and worked upon within the CDE solution. This is to ensure best practice for data management, including access, versioning, change history, back-ups, etc. The CDE is for all files not just the outputs. This means that the CDE solution must be able to manage the specific packages used for the creation of information, such as 3D models and final  drawings.

WIP to Shared Transition

Before information moves to the shared state, the information container must first pass a QA check and then a technical review by the authoring task team.

The QA check reviews the information container’s metadata (such as file name and attributes), not the contents. While the technical review is concerned with its contents. If passed, the information container transitions to a shared state; if rejected, it remains in WIP to be amended and resubmitted.

Shared State

Information in the Shared state is information that has been approved for sharing for a specific purpose. Often, with the delivery team or a draft shared with the appointing party, sometimes via a Client Shared state (more information on this below).

Information sharing enables constructive and collaborative development of the information within the team. Information containers in the shared state should be consulted by all appropriate appointed parties for the purpose of coordination with their own information.

Shared information must only be used for the permitted use or purpose for which the information has been shared, denoted by the information container’s Status (suitability) Code.

Shared information is visible and accessible by authorised users but is read-only. If editing is required, the information container should be returned to WIP for amendment by its author(s).

Shared information must be the most current approved revision of the information container.

Sharing should NOT cause duplication; each information container should be unique within the CDE. The CDE enables a secure and controlled environment for the sharing of information to occur.

Client Shared

Some interpretations of ISO 19650, such as TfNSW’s Digital Engineering Framework also use a Client Shared state. Client Shared is used for information containers that are shared with the client, such as ‘for information’, ‘for review’, or ‘for comment’, but are not being issued for Publishing.

Generally, information containers are first shared internally amongst the delivery team, and then once approved, shared externally to the appointing party or other external stakeholders.

This information is read-only and must only be used for the specific purpose, as denoted by the information container’s Status Code.

Client Shared could be a restricted shared location within the delivery team’s CDE, or if the appointing party has their own separate CDE, the information container could be transmitted to the Client CDE, either by integration or by a document controller.

Shared to Published Transition

At documented project milestones information containers are coordinated into an information model and published with the appointing party. Information undergoes an internal technical review by the lead appointed party, and later an external review by the appointing party. The information model is reviewed against the relevant information requirements for coordination, completeness, and accuracy.

If the appointing party’s commercial review is successful, the information model is accepted as a contractual deliverable and transitions to a Published state.

If rejected, the information model is returned to WIP for amendment and resubmission.

Published State

Information in the Published state is contractual information that has been accepted as a deliverable by the appointing party (i.e., the client).

Published information is authorised for a specific use, such as ‘for construction’ of a project or ‘for the operation of an asset’, as defined by the information container’s Status Code.

Published information is read-only and must be the most current authorised revision of the information container. Published information is accessible by authorised persons within the project team, such as with the document controller, appointing party and CDE administrator(s).

Not all information produced will reach the published state. As an example with drawings it is typically only be the outputs that transition, while the working files remain in WIP (such as a PDF produced from a DWG drawing, where the DWG remains in WIP).

Archived State

The Archived state is for information that has been superseded or otherwise archived. The archival process ensures there’s a definitive version of the PIM and AIM available in case it is needed after the project has been completed. For instance to inform a refurbishment of the asset.

Information is archived:

• • To provide a record of information development and exchange in case of a legal dispute
  • To inform the ongoing operation and maintenance of the asset; and
  • To help lessons learnt at the completion of the project.

Archived information is read-only and only accessible to the appointing party and the CDE administrator(s).

The archive should contain a journal of the latest revision of all information containers in the Shared and Published state, all superseded revisions, as well as a complete journal of information developed in the WIP state. The timescale for retaining project information should be defined in the appointing party’s EIR.

This journal of information development, such as the file change history, should include:

• • Who checked it and when
  • Who approved it and when
  • What status was assigned to it before it was shared
  • Who authorised it and when
  • Who accepted it and when

CDE Metadata Overview

Metadata is used in the common data environment to give further information to an information container, usually using file attributes, such as author, creation data and/or file size.

ISO 19650 identifies that each information container should be assigned the following metadata within the CDE:

1. State – the above four stages (WIP, Shared, Published and Archived)
2. Status code (suitability) – the purpose or permitted use of an information container (e.g., ‘for coordination’ or ‘suitable for PIM authorisation’)
3. Revision – tracks the version of shared and published information, in accordance with an agreed standard
4. Classification – categorisation of information contents, in accordance with an agreed classification convention (i.e., ISO 12006-2 or Uniclass 2015)

An example of metadata attributes for information containers within the CDE solution. Source: UK BIM Framework ISO 19650 Guidance C: Facilitating the CDE Workflow and Technical Solutions

ISO 19650 recommends the following should be agreed upon by the project team prior to information generation:

1. 1. Information formats
   2. Delivery formats
   3. Structure of the information model
   4. The means of structuring and classifying information
   5. Attribute names for metadata

Status (Suitability) Codes

Status codes are metadata used to indicate the purpose or permitted use of an information container.

Status codes are applied to information that is Shared/Client Shared, Published or Archived. All WIP information is given a default ‘S0’ Status code of ‘preliminary revision and version – not suitable for any purpose or use’.

This Status Code can be applied as an attribute/metadata attached to the information container within the CDE.

Below is some examples of Status Codes specified in ISO 19650.

Status codes for information containers according to BS EN ISO 19650-2. Source: UK BIM Framework ISO 19650 Guidance C: Facilitating the CDE Workflow and Technical Solutions

Status (Suitability) Codes for information containers specified by the TfNSW’s Digital Engineering Framework – Part 2 Requirements (pages 22-23)

Revision and Versioning

ISO 19650 requires all information within the common data environment to be revision and version controlled.

Versioning

The version of information is controlled during WIP by the CDE solution. This creates an auditable history of the information development which is used by the author to manage their work and avoid losing information during development. As well as, enabling roll-back to a previous version if required, for instance if the client requests an earlier option. Version control also allows the author to view previous versions and copy elements from it to the current live file.

Only task teams responsible for the information container’s production can see the versions of a revision.

Revisioning

Different from versioning, revision is used to track information that is being shared outside the author’s task team (Shared & Published information). An information container’s revision is incremented after each time it is shared or published.

ISO 19650 does not define a revision numbering scheme or standardised status codes. Instead, it’s up to the appointing party and delivery team(s) to agree upon this and to document and communicate it with the broader team. The revision system used must accommodate the iterative approach of multiple WIP and shared revisions for a single information container.

Example Revision Metadata System

Below is an example of a revision and versioning naming scheme identified by the UK national annex BS EN ISO 19650-2.

• • A letter prefix defines the permitted use of the information container: ‘P’ for non-published preliminary information, ‘C’ for published contractual information
  • A two numerical integer value denotes revision of the information container that has been approved for sharing with other teams
  • A second two numerical integer value defines the WIP version of the primary revision, separated by a period delimiter

Source: UK BIM Framework ISO 19650 Guidance C: Facilitating the CDE Workflow and Technical Solutions

Example Development of an Information Container (BS EN ISO 19650-2)

Example development of an information container through the revision metadata, in accordance with BS EN ISO 19650-2. Source: UK BIM Framework ISO 19650 Guidance C: Facilitating the CDE Workflow and Technical Solutions

Classification Codes

ISO 19650 recommends assigning each information container to a common classification for the whole project. Classification codes are used to indicate the type of information of an information container, for instance, discipline, zone, project, etc.

Classification codes should be set in accordance with an agreed upon standard before information production commences, such as Uniclass 2015 or ISO 12006-2. Once established, they should be documented in the project’s information standard and communicated to the project team for use.

Classification should not duplicate other metadata values, such as State or Status.

CDE Workflow Practical Application

Below is a diagram from TfNSW’s Digital Engineering Framework Part 2 Requirements illustrating a practical implementation of the ISO 19650 information management process and CDE workflow. The standard uses ‘Client-CDE’ to denote the appointing party’s CDE, and ‘Contractor-CDE’ for the delivery team’s – or delivery teams’ – CDEs.

TfNSW CDE Diagram spanning both the Contractor-CDE and Client-CDE. Source: TfNSW Digital Engineering Framework Establishing the Contractor CDE

A diagram illustrating the approval states, status (suitability) codes and review outcomes of the TfNSW’s Digital Engineering Framework’s CDE process. Source: TfNSW Digital Engineering Framework Part 2 – Requirements.

For more information on this, you can read UK BIM Framework’s ISO 19650 guidance documentation, or refer to the standards directly.

CDE Solution Overview

The CDE Solution is the technology which enables the CDE workflow process.

Due to the complex nature of AEC projects that include BIM and information models, one product may be insufficient to handle all aspects of the project or asset. Therefore, the CDE can be a group of integrated IT systems. The CDE may comprise data management systems, geospatial information systems, project management software, contract management systems, etc.

The purpose of the CDE is to act as a central repository of information for the project or built asset and to enable the CDE workflow process.

CDE Ecosystem: Client CDE & Contractor CDE

ISO 19650-2 clause 5.1.7 places onus on the appointing party to implement, configure and support the project’s CDE. However, in practice delivery teams will likely operate in separate, but connected, CDEs, forming an ecosystem of CDE solutions.

Like all big changes, the industry will be hesitant to adjust. There are concerns to having design, construction and the client all operate from the same system, and the legal and financial ramifications associated.

Regardless, the CDE’s fundamental principle of a centralised repository for all project parties can still be realised through an ecosystem of separate but connected common data environments.

ISO 19650 acknowledges this and hence allows each party to operate their own CDEs as long as they are integrated in a way that enables the seamless sharing of files and for the CDE workflow to occur.

The separation of CDEs has been implemented by the TfNSW’s Digital Engineering Framework, which establishes the Client CDE (used by the appointing party) and Contractor CDEs (used by lead appointed parties and their appointed parties). Together, the Client CDE and Contractor CDE forms the Project CDE.

“Treating [the Client CDE and Contractor-CDE] as distinct parts provides more freedom to each contractor (or group of contractors working under one contract) to work efficiently according to their own systems and processes, so long as these comply with high level principles and requirements.”

– TFNSW Digital Engineering Framework: Establishing the Contractor CDE

Diagram illustrating an ecosystem of separate but connected CDE solutions

‘Common data environment (CDE) in the ISO 19650 World‘; a presentation presented by Mitch McPherson at our online 12d Tech Forum 2021. Mitch explores some of the core ISO 19650 requirements of a CDE, their practical application, the CDE ecosystem and how one size almost never fits all.

Open Data Formats

ISO 19650 and the CDE workflow requires the interoperability of information across different systems, disciplines, and parties. This is because the CDE Solution may not be a single product, but rather a group of integrated and interconnected IT systems. Different CDE solutions may also be used at different stages throughout the asset lifecycle.

ISO 19650 recommends the use of open data formats wherever possible to ensure the interoperability of information.

Data is considered open when it is not restricted to specific software solutions. An example of open data formats could include MP3, PDF, XML, and IFC file types. While proprietary data is restricted to specific software solutions.

Proprietary data may require translation, manipulation, or configuration to different formats, which can harm the information’s integrity and hinder the open exchange and collaboration of information.

buildingSMART is an international organisation that champions open data across design, construction & operation through initiatives including openBIM and openCDE.

Requirements of a CDE Solution

Below is a list of basic requirements that a system must support to function as a common data environment. Note this list is not exhaustive.

• • Permission controls at each information container level & state
  • Handle working files and datasets, not just outputs (ensure WIP stage managed)
  • Ability for information to transition between states
  • Ability to assign and control the assignment of metadata attributes to files
  • Integrations with other systems to enable the overall CDE solution
  • Accessibility and remote access by all appropriate users within the project team, including professionals on-site or working remotely
  • Configure and enforce naming conventions, ensuring all information containers have a unique ID
  • Audit trail/ versioning and revisioning system
  • Ability to archive information

For more information about requirements for a CDE solution in compliance with ISO 19650, download our CDE Requirements Checklist below.

Conclusion

The common data environment (CDE) is a collaborative environment for the collection, management and dissemination of project and asset information by stakeholders through a managed process.

The concepts and principles of the CDE were established in BS 1192:2007, and later evolved in PAS 1192 and more recently by ISO 19650. The CDE represents both the CDE solution – a group of integrated IT systems – and the CDE workflow – a controlled gated process for information development and exchange.

The objective of the CDE is to provide a platform for the efficient and effective collaborative production and exchange of information in accordance with ISO 19650. The CDE ensures the right people work on the right information at the right time. Ultimately so built assets and projects are delivered on time, within budget, and to standard. As well as to enable faster, easier, and more accurate decisions to be made by stakeholders across the asset lifecycle.

If you found this guide helpful, please share it with your colleagues/ network and help broaden understanding of the common data environment (CDE) and ISO 19650 amongst our industry.

We welcome your thoughts and feedback. Get in touch with us at info@12dsynergy.com.

Resources

Below is a list of recommended resources for learning further about CDE and the ISO 19650 series:

• The Ultimate Guide to ISO 19650 (12d Synergy)
• Australia and New Zealand Guide to ISO 19650
• UK BIM Framework Guidance, especially Part C Facilitating the CDE Workflow and Technical Solutions
• BS 1192:2007+A2:2016 (superseded UK BIM standard) available here
• PAS 1192 (superseded UK BIM standard)
• PD 19650-0:2019 Transition guidance to BS EN ISO 19650 (BSI)
• ISO 19650 Standard (ISO), particularly Part 1 and Part 2
• The New Zealand BIM Handbook
• TfNSW Digital Engineering Framework, particularly Part 2
• Victorian Digital Asset Strategy (VDAS)
• NATSPEC National BIM Guide (AUS)
• The B1M – What is a Common Data Environment?
• BIM Dictionary, ISO 19650 Terms