A Primer on CDEs (Common Data Environments) for Architects

LAST DECEMBER, Architosh featured an exclusive story on the Nemetschek Group’s decision to utilize Bluebeam Studio’s technology as its common data environment (CDE) platform and strategy. And while the news was somewhat foreshadowed by comments made at GRAPHISOFT’s 2017 Key Client Conference (KCC) in Kyoto, Japan, the Bluebeam-based CDE developing story should signal to AEC professionals—especially architects—that some basic knowledge of CDEs is becoming mandatory if they want to guide their firms in the right directions.

CDE Primer—What’s a CDE Good For?

The common data environment, or CDE, is a centralized environment for the data of a team of collaborators and project stakeholders. This environment is digital (cannot be analog), exists on a computer server, and is accessible from the Internet.

A crucial distinction of a CDE in the AEC world (and CDE’s exist in non-AEC industries) is that the data includes both graphical model and non-graphical model data. This data is “centralized” by definition and accessible by multiple parties, each with various project roles, permissions, and responsibilities to the data.

 

 

The obvious benefit of a CDE in the AEC industry is to provide all project participants with what is sometimes referred to as a “single source of truth” (SSOT).

The British Standards Institute (BSI) recognizes CDEs in AEC through its initiative (BS 1192:2007) and then in PAS 1192:2013 and notes this in its introductory comments in this report here. It says:

 

 

 

 

In terms of purposes, this statement above should ring both true and relevant for architects, engineers, and contractors alike, whose daily struggles with project information (data) both vary in intensity, frequency, timing, and type. Despite such variance, the CDE winners in the AEC industry will need to address all these aspects in common pain points.

CDE Primer—The Four States of a CDE

The BS 1192:2007 definition of a CDE list four states or phases of the CDE. These four states or phases are (1) Work-in-Progress (WIP), (2) Shared, (3) Published, and (4) Archived. They are described below as:

• Phase 1 — WIP: The first state or phase represents information that is under development (work-in-progress) by its original creator (eg: architects, engineer). Inside a model CDE, this data would sit in a container (see definition below) and be both visible and accessible only by its original creator.
• Phase 2 — Shared: this state is differentiated in the sense that data is now accessible and viewable by others outside of its creator. In this state, an engineer, for example, could check and coordinate her work with the work of an architect. This phase or state also includes sharing work with the client for review, feedback loops, or approvals. The “shared” phase would require CDE’s to layer feature sets based on functionalities appropriate to the parties. (more on that in a below)
• Phase 3 — Published: this state is when information has been “published” for consumption and use related to the construction of a project or the operation of an asset in the construction (eg: building, plant, bridge, roadway, etc). This information is both “coordinated” and “validated” for use by the total project team, which is distinguished from the “shared” state where multi-participants are in the process of coordination and validation.
• Phase 4 — Archived: this state is the “record” state and supersedes all other containers holding information in earlier states of this four-state system.

Few CDE solutions make an explicit reference to meeting the requirements of the CDE framework as defined in the BS 1192:2007  and PAS 1192:2013 standards referenced above. And that is too bad because the four-states approach provides an overview structure that is valuable to the process.

Defining Minimum CDE Requirements—All AEC Stakeholders

Before getting into the needs that architects may specifically have for CDEs, let’s touch on core needs that any CDE solution must address. These are pain-points that exist in AEC workflows because those workflows and standard industry processes were well worked out and ingrained prior to the emergence of the computer. The truth is those processes themselves cannot support an all-digital and fully collaborative construction project.

In other words, the well-worn AEC industry processes must be modified if there is any hope that digital tools can solve collaboration and knowledge exchange issues—issues that cost the global construction industry billions of dollars in errors and omissions, delays, and building failures.

To solve this, a CDE must handle, ideally, all of these core requirements:

• BS and PAS 1192 compliance — supports Four States of a CDE
• Cloud-based — a neutral command (admin) structure assures that all parties participate
• Tablet Access — mobile support for the field is a minimum requirement
• Document Management — access, role-based privileges, central repository, sharing documents
• Version Control — system must support document versions, audit trails, roll-backs
• Change Management — revision support, compare viewing, understanding decision history, accountability
• Collaboration — multi-party viewing, “mark up,” RFI, meetings, and messaging support

These are seven core areas but many will argue that there should be more aspects than this that make up a minimum set of features in a qualifying CDE tool. All of these core features must-have expressions of the tools that support each role in the AEC industry, helping architects, engineers, and construction professionals alike.

The goal with CDEs is to increase “wrench time” for contractors, “pen time” for architects, and “calc time” for engineers by streamlining management workflows that center on the necessary exchange of information. Phil Bernstein, FAIA of Yale University and Autodesk Fellow, has expressed that CDEs are “implicit (available)” systems versus “explicit (send it to me)” systems. Email is the primate culprit of explicit systems and explicit systems demand unnecessary person-to-person communication time.

Defining Minimum CDE Requirements—For Architects

Today’s largest CDE applications are being driven to address the pain points of their earliest and largest customers. In the 1980s, engineers beat architects to punch with computer-aided design (CAD) systems. As a result, the industry ended up with a de facto standard that many architects felt was too engineer-centric. When BIM came along, large architecture firms (big BIM) jumped to the fore to ensure they had a better stake on the table early on. Now, with CDE’s it is the contractors who are embracing the common data environment (CDE) with more gusto than their “A” and “E” colleagues. This explains why the most mature CDE systems out there are very contractor-centric. (see, Architosh, “Ultimate List of CDE (Common Data Environment) Apps for Architects,” 15 Jan 2018).

It is natural to understand why. A single-source of truth (SSOT) gives the contractor more trust and confidence to take action. Implicit (available) systems enable the contractor to stop chasing the architects and engineers for information. The common refrain, “Where is that drawing you promised me?” begins to go away. Yet, contractors are asking for construction project management features in CDEs that sometimes exclusively serve their needs, while engineers and architects also need discipline-specific features.

Architecture Specific CDE Core Requirements:

• CAD/BIM Integration — cloud-based system can link to desktop internal CAD/BIM solutions
• PDF Integration — plugins enable desktop tools to publish PDF output to the “four states” of CDE
• Model Viewing — enables the architect to team-view BIM or 3D models with stakeholders
• Model Dissection — enables architects to section and interrogate the BIM model down to entity level
• BCF Support — supports the issuance of BCF (BIM Collaboration Format) to collaborators (AEC)

Going back to the Four States of a CDE defined above, phase 1 impresses upon a CDE to support the first four items above. Phase 2 (Shared) impresses upon a CDE to support items 4-5 in particular so the architect, engineer, or even fabricator specialist can help troubleshoot and develop building features. You need to be able to get into sections of BIM models to see items and be able to mark up commentary and round-trip exchanges. BCF sessions form critical multi-party decision histories.

For Phase 3 (Publish), items 1-2 address these requirements. A publishing feature in a BIM tool should be able to distinguish items published for any phase, so both engineer and architect can ascertain from within their authoring tools which data got pushed to which containers (four states) of a CDE system meeting the BS 1192:2007 definition.

OpenTree of the UK has developed a system called Cabinet, which delivers a smart way to comply with BS 1192:2007+A2:2016 (BIM Level 2) standards. Cabinet itself is a managed WIP environment—the first container or stage of the BS 1192 CDE standard. It works by offering CAD, BIM, email, and office software integrations with Cabinet. This means that you can have Revit and Cabinet talk directly to each other, wherein Cabinet changes Revit’s title block such that it implements BS 1192 compliance.

This video shows Cabinet by UK-based OpenTree. The solution solves the BS 1192:2007 CDE compliance challenge. 

To understand how this works, take a look at the video above in full. It will give you a clear explanation in faster terms than words can do alone.

Final Thoughts on Selecting a CDE Solution as an Architect

There are two related articles to this one. The first one is a comprehensive list of available cloud-based solutions that function as CDEs for the AEC industry (an INSIDER exclusive guide published alongside this article). They are ranked based on their ability to meet both the minimum “architect” specific CDE requirements (above) and the minimum CDE requirements for all stakeholders (also above).

The second article is based on a talk the author gave at the 2013 Boston ABX conference, which looks at how online project document and project management tools (CDEs) can be divided across two hemispheral challenges that all architects face— the “complexity of the building” versus the “complexity of the brief” (and its communication frequency). This could also be restated as the complexity of solutions (architects must generate or solve) versus the intensity of client input.

Some CDE solutions directly created for architects lay the emphasis on tools that help architects address one or the other better.

It is imperative that architects understand their practice is unique in terms of both its project types and its client types. Client types influence the nature of the communication of the project brief (program) and, in particular, its frequency of communication. (see image 02). 

Overall, CDEs can help address the challenges architects face in both hemispheres of the overall problem, managing input of data (specifically client input) and generating solutions that respond to it.

 

Editor’s Note: This article has been updated on 17 Nov 2023. Additional edits and updated links have been made. 

SaveSave

SaveSave