Interoperability is a problem that companies have been trying to solve for a long time. Interoperability or interop for short is about getting all the programs to communicate effectively with each other. The exchange of data means that we, the users, don’s have to deal with different file formats and incompatibility issues between programs.

But, the reality is that as long as different companies produce these programs, there will always be an inherent disconnect between them. This disconnect is so apparent that there are services and tools dedicated to bridging this gap between these programs.

The Current Interoperability Strategies

Currently, there are two strategies that tackle the interop problem. The first is what I call direct links, which are direct connections from one program to another. These are typically program specific plugins.

The second strategy is platform links. Instead of building a program-to-program connection, you connect a program to a platform. This platform becomes the central place where your data is stored.

Direct Links

Direct links allow a program to communicate with another program. These links are normally third-party plugins that you have to install manually. And they are typically one way, meaning data can go from program A to program B but not the other way around.

Also, depending on the quality of the direct link, significant data can get “lost in translation”, especially when the two programs have very different philosophies.

For example, SketchUp supports the import of Revit files but family and parameter data are lost because SketchUp doesn’t have any way to store that information. The two programs are designed for very different things — one is documentation and the other for modelling. This is precisely why many direct links are one-way because data that is lost in translation cannot be recovered and sent back.

It’s also hard to scale direct links because you have to keep building links for every new program you use. If you use 5 programs, you would have to make 120 links to connect all these programs.

One way to solve this issue of scalability is through the use of a centralised platform which brings us to Platform Links.

Platform Links

Using a platform to handle all our inter-program links means that for each new program, you only have to make one new link. But the problem of data loss in translation will still be there. In fact, we might be making this problem worse because the data needs to be translated twice. For Program B to receive data from Program A, the data has to be translated first to the platform and then to Program B.

The upside to this is that if the platform is flexible and robust enough, you won’t lose any data when transferring it to the platform but you will still lose data when you get to program B. I am skeptical that we can eliminate this problem because you can’t transfer data into a program that it was never designed for. This isn’t an issue for one-way connections but it’s an issue if you want to create a two-way data flow.

Platform links are naturally scalable, which is why most companies trying to solve the interop problem tend to prefer this strategy. Some solutions aim to minimize this data loss by letting you select which data to transfer. But the more control we have, the harder it is to use these tools. With that in mind, let’s look at some of the current solutions out there.

Current Solutions

There are many plugins and services that offer interop solutions. However, there are two notable services that I use at work that are worth mentioning. These are also the two services that I think are making great progress in solving the interop problem.

Speckle

Speckle an open-source, fully featured platform. It’s got a lot of features, but the most notables one are, cloud data storage, version control and a web 3D viewer for your data. You can even opt to pay them to build a server for you, so that you can maintain your data instead of uploading it to their server.

Because of the extensive user and developer documentation, the platform has a lot of existing connectors for many popular programs used in the AEC — Architecture, Engineering, and Construction — industry.

Not to mention, Speckle also has a user-friendly interface that caters to both regular users and super users. If you just wanted to transfer data, the user interface lets you do so with a couple of buttons. And if you wanted more control, the interface also exposes more advance options over how your data is handled.

But Speckle still faces the issue of your data being loss in translation. Even though it’s platform is impressive and feature-rich, you can’t be intentional over what kind of data to transfer unless you write your own connection.

Rhino.Inside Revit (RiR)

This is where the benefit of direct links come in. RiR is one of the best examples of a direct link solution. it let’s you exchange data between Rhino and Revit through the use of Grasshopper components.

By using Grasshopper components, you can tailor the type of data you want to transfer and how that data maps to each program. It’s a lot like working directly with the Revit API but made easier with Grasshopper components. You can now build bespoke Grasshopper scripts that let you dictate how data is interpreted in each program.

The trade-off here is that you need to have a good understanding of Grasshopper to use RiR and it only exists for Revit.

Honourable Mention (BHoM)

Before solutions like Speckle or RiR existed, one of the most popular interop tools out there was the BHoM — Buildings and Habitats Object Model. BHoM was an early attempt at creating platform links. It has gone through several changes over the past few years. In it’s current state, it’s more of a common language for data than a platform like Speckle.

Being open-sourced, BHoM had many contributors who wrote “adapters” for various programs -- which were mostly structural engineering focused. An adapter is the name of a connection between a program and BHoM. This was useful because, the programs that I was using at work were already supported by BHoM and I used their Grasshopper components a lot exchange data between Rhino, Revit and ETABS before Speckle and RiR came along.

Today, I would still recommend using the BHoM if you use Grasshopper and have to interact with a lot of structural engineering tools because Speckle doesn’t have as many connectors as the BHoM. Also, because BHoM is just an interpreter, you don’t have to worry about uploading your data to third party service like Speckle.

But overall Speckle is a more refined product and I think is a better experience than using BHoM.

Final Thoughts

That being said, the current interop strategies and solutions are still far from the perfect answer to this problem. It’s not enough to just create a platform, we need to actually control how the data between the programs interact. Solutions like Speckle make me hopeful that we might have a centralised platform for all our data in the future. And solutions like RiR help me understand what managing that data will look like. I think that all interoperability between programs will always need human intervention but we can make tools that help us do that more effectively.