Tim Dufault, FAIA – Concert CRO
Everyone is looking for the silver bullet – that one thing that solves all the world’s problems. The latest “silver bullet” in digital design and construction is the Common Data Environment or CDE. The idea is simple – get everybody in the project to agree to store their data in a single cloud server with authorized access and share only published data.
The problem is that data doesn’t live that way!
Interestingly, we describe data as “living” when it is clearly not. But it is an apropos description since, in many ways, data is constantly changing, evolving, and growing just like other living organisms. But data is controlled by those who own and author it and a part of that control is where and how it is stored, and this is idiosyncratic to the data owner. Expecting that all the data owners in a design and construction system will only store their data in one common storage system is altruistic, at best. The reality is data is going to be replicated and live in lots of different systems throughout the life of the project. CDEs are a good idea on paper, but the practical application is unrealistic.
If a core goal of a CDE is for it to be the single source of truth, can this be accomplished with data being copied and stored in other locations? It is easy to argue – no it will not be the single source of truth. Leica files want to live in Leica, ESRI in ESRI, Tekla in Tekla, Procore in Procore, etc. It is unnatural to move them all to one place when they are usable and valuable somewhere else. Additionally, members of the project team who don’t have access to the CDE (aren’t authorized) cannot determine if the data they have is current or relevant.
At Concert, we believe that data is valuable when it is decentralized and distributed, recognizing the nature of how data is created, stored, and shared. We also value systems that allow all participants in the project process to be certain the data is current and relevant. Therefore, we created the Concert data exchange platform. Decentralized data systems don’t care where the data lives, only that the identity of that data is recorded in a manner that all project participants can query or test versions in their control, to determine if what they have is relevant and current. This is where Blockchain becomes a valuable tool. Because of the public nature of Blockchain, anyone can query a data file and determine its agency, without any special license or user privilege.
The core to protecting and valuing decentralized data is the mechanism for giving each file a unique fingerprint. At Concert, we use a cryptographic hashing process that is compliant with SHA-3 security standards, one of the strictest data security standards in use today. Each organization, person, data file, and activity on the platform is given one of these unique cryptographic hashes. This creates certainty that identity, authority, and ownership can be definitively established, regardless of where the data resides. For project participants outside the platform, they can use the Concert website to query data they are in possession of to determine if it is current, who the author/owner is, and whether it is authorized for the use they are contemplating. None of this requires a license, special software, knowledge, or applications. This provides all participants with a single source of truth, one that is robust and protected because, importantly, the public record of the data does not contain the actual data.
Data is going to live everywhere on multiple servers. What is important in the design and construction process is the knowledge of what is the current and relevant data for the desired activity. Decentralized data records recognize that the owner and authors of each data component will always have the most relevant versions but creates a mechanism for recording the authorized version for access by all project participants.
That’s Concert!
