This blog is an introduction to the openCDE-API (CDE = Common Data Environment, API = Application Programming Interface) project. It is an open initiative by the same group responsible for development of the BuildingSMART BIM Collaboration Format (BCF) project.
Project Background
Common Data Environment(CDE)’s are used to manage construction projects and is responsible for creating a central record of all digital transactions or a “single source of truth”. Typically provided by the main contractor or client, not everyone will work through the same CDE through the lifecycle of the project. Often this presents challenges when moving data between systems and results in project data sources being manually tracked and exchanged which often ends up in lost and/or replicated project data leaving project teams questioning the quality of the CDE system and lead to rework that can be costly for all involved.
These complaints seem to have made it up the chain of command and CDE providers are “pulling the finger out”. This project aims to define an open specification for systems to support open data exchange and to provide project stakeholders confidence in their systems through a common set of interfaces (or “language”) for systems to communicate. If a project supports the openCDE-API interface, information containers (Topic for another article) can automa’gically stream seamlessly between them with little loss in metadata and eliminating costly data errors. (According to Source: JLL State of Construction Technology Research 2019, individuals in construction project management spend 5.5 hours per week looking for project information.)
The Interface
The OpenCDE project aims to create a common interface standard so that a CDE provider can “plug” into other CDE’s and to other Client software providers. Collectively this is referred to as the ecosystem. Examples (From companies in attendance at the openCDE-API hackathon - November 2019), as follows:
CDE providers - Aconex, ThinkProject
Client providers - GraphiSoft Archicad, Solibri, BIMLauncher and XBIM.
This spec will be supported by the development teams in each of the providers and the development is formalised around an OpenAPI (Swagger) spec that describes the interface (REST) supported by compatible CDE providers. Client providers can connect with any CDE supporting this single interface implementation. This means that as a startup, you can create one “integration” for CDE providers supporting this spec and without any further development effort integrate with all of the others.
The interface currently supports two discrete “interactive” and “non interactive” flows, that I will describe in the following sections:
The interactive flow
The interactive flow is designed so that the user can work with their CDE project data directly within the Client environment. Supporting this implementation requires the CDE to return a web page that can be viewed by the user in the Client UI environment. The user interacts with the webpage for the Client - CDE communications. Currently only downloading and uploading a file is supported and the implementation can be reviewed on the github page [Link Here].
From the perspective of the vendor the interactive flow is much easier to implement. It is an easier sell internally to make investment in. The proof is in the pudding - This is the only side of this spec with development work done to date. The CDE provider can use their native data query tools and metadata schemas. However, this process is very rigid as it requires agreement on each individual user workflow to support prior to supporting them. It also has very poor automation capacity for handling metadata which means that the user must handle the metadata which is time intensive and error prone.
The non-interactive flow
The non interactive flow provides greater flexibility to the Client provider for dynamic features and workflows. As there is no UI/User involvement required, it is powered exclusively by a specification compliant RESTful API service provided by the CDE, and this means that the Client can optionally manage the data in the CDE on behalf of the user.
Single REST API for vendor partner ecosystem compatibility.
Supports connections from one vendor to many vendors.
The non interactive flow takes more effort to support on part of CDE vendor and Client. It is seen as a huge challenge by the CDE providers as the scope for technical specifics require much more alignment. For example, the data schema for each information container type that each provider uses within their system is completely different. For example, when one project CDE provider uses a GUID type to represent a document version and the other CDE provider refers to it as an integer. Both are completely valid within the context of their own internal data model.
Another challenge is that CDE providers often provide project defined schemas that can change on a project basis. This results in a requirement to create individual property maps between these systems make it increasingly difficult to standardise as it creates an additional mapping requirement for end users if they want to maintain a consistent flow of metadata between CDE providers.
The Future
We have been building tools to provide solutions to the complex data exchange scenarios outlined above within BIMLauncher and we agree that it is no easy task to resolve. However, the success of the project depends on the cooperation of CDE vendors to agree on how their systems should exchange data.
Standardising and enforcing a unified API interface for an openCDE-API that providers must comply with (an approach tried before) could be a big mistake and could jeopardise the project success resulting in only a small percentage of CDE providers adopting it due to barriers to entry created by infeasible technical requirements for them to comply with. This non compliance would in turn have a knock on effect reducing the demand from Client providers to support it and weaken the overall project value.
Instead, the project is opting for a collaborative approach to develop a technology framework and tooling that caters for changing requirements between CDE providers and projects.
The group continues to collaborate in bi-weekly online meetings and in particular, we require more interest from organisations or individuals interested in developing the non-interactive flow. To join the conversations, drop me a line and I can make appropriate introductions to the leaders of the initiative.
The BIMLauncher - openCDE-API relationship
BIMLauncher is a third party independent system integrator focused on improving the connectivity of an evolving ecosystem of construction project management tools. We believe sharing our experience from developing our own internal standards for data exchange could be greatly leveraged in this effort and as a result, we are proud to be involved in this initiative.
If you are a vendor that would like to discuss this further or part of a project information management team interested in adopting best “open” principals for data exchange, we would love to hear from you.
Photo taken at openCDE-API hackathon @ Nemetsheks offices Wednesday 28th November 2019.