Separation of Concerns (SoC) is one of the common design principles used in software development . In more general terms, it means that “The product should be separated into distinct sections where each section addresses a separate concern. A concern is a set of information that affects the product.” Arguably the biggest concern in the construction industry is liability for professionals’ decisions, actions and outcomes. This heavily influences how Common Data Environments (CDEs) are used on construction projects. The common schema you will see will look like this:

This would be perfect in an ideal world where a CDE  would be party-neutral. It would just be a piece of technology which is independent and everybody can use it for their own and other people’s benefit. This is also known as a hub-and-spoke concept. But that is almost never true. One party owns the CDE. That party is likely paying for the CDE (as a platform, as a cloud service, as a hosted service or a set of services). That party is managing everybody’s access to the CDE and can themselves potentially have access to all the content in the CDE. So, it looks more like this:

As you can see, this is quite an asymmetrical relationship and many people don’t like that. Distribution of liability is deeply rooted in the common working and contractual practice of construction projects. As a result, every party is likely to have their own CDE for their work-in-progress (WIP) and only hand data over to a higher tier CDE when it is ready to be shared or published.

While a single CDE (maintaining a single point of truth) is generally desirable in the collaborative environment, ISO 19650 also acknowledges that having multiple CDEs on the project is a possible arrangement. And as long as we continue to work as we do, working in this way is unlikely to change. The OpenCDE API initiative is trying to address this by defining a common API which might be used by CDE solutions to exchange the data with minimal user interaction (download -> store -> find -> upload). But this doesn’t address the issue itself. There will still be a need to manage several CDEs on the project and somebody will have to manage their interactions. OpenCDE API will only help to move data more easily between CDEs.

But what if you don’t want to maintain a complete CDE on your side and still want to provide useful structured data and comply with the project requirement to use a specific CDE? If there is a will, there is a way. Common data environment, as defined in ISO 19650 is an envelope around a large set of containers. Containers have minimal metadata associated to them. And a container is essentially anything. It can be a simple file, it might be a database, it might be a physical soil sample, or it might be a link to other structured data.

Xbim Flex conversations have one very simple feature which makes it possible to save the conversation as a shortcut file (*.url). This makes it very easy to create a file-based handle to the conversation, store it in any CDE (or just a file share like Dropbox or OneDrive) as an ordinary container and associate any necessary metadata with it. While it makes the conversation part of the CDE, the conversation itself; including your data, all the views, 3D models, drawings and the communication itself remains under your control. You may call this a hybrid approach, where all the data is searchable and there is a central record of its existence, but it is not all contained in the central store.

This may not work for everybody. But if you want to separate your concerns (SoC) and keep your models, documents, drawings and related communication under your control, then this set-up might be a lightweight solution.