In all AEC -- Architecture, Engineering, and Construction -- projects, there are many different types of problems to solve. Like how to best simulate the current building condition or how to document the building process. The solution to these problems is usually found with the help of computer programs.

Because each problem has a different nature, we often use several programs, like Revit for model documentation or Grasshopper for geometry creation. But these programs often contain similar data and, because they are made by different companies, we have to manually enter that data twice -- or as many times as the number of programs are in use.

It then makes a lot of sense to get these programs to talk to each other and share the data among them. This will reduce a lot of unneeded manual work, human errors and your stress level on the project.

This dialogue between programs is formally known as interoperability and is something that the world has been trying to solve for a long time now. Solutions like using common file formats and the Open standards criteria are attempts at solving this problem. But the problem will always be there for many reasons -- companies wanting proprietary formats, different formats having different performances, etc.

The good news is that there are at least three ways of getting the programs to talk to each other. All of them have to be done manually, but you at least get the option of defining how data is shared amongst your programs.

File Formats

The classic way of getting programs to communicate with each other is through common file formats. This is the idea that if all programs can import and export the same file format, then all programs can share data. Formats like .DWG, and .IFC are accepted by most AEC programs.

But the problem here is that each program interprets these formats differently. An analysis program will treat a .DWG file differently than a documentation program. An analysis program typically only cares about the connectivity of the geometry but a documentation program will want to keep the nuances of the model.

To put it simply, analysis programs only need data that simulates real life, while documentation programs need data that represents real life.

By using file formats, there isn't a good way to solve this issue, there needs to be a mapping between the analysis world and the real world. And no one file format will solve that. Yet we still see file formats used everywhere because it is the easiest and most predictable way to transfer data around -- they just aren't that useful.

APIs

So, instead of relying on common file formats, you can directly control what data you want through a program's API -- Application Programing Interface. APIs are a program's way of letting you directly interface with their process. It's about dealing with the raw data that the program is using. This granularity lets you build direct relationships between programs -- giving you almost full control on the data exchange. But to use APIs, you need to have some idea of software development.

This control means that you can build bespoke relationships between programs for your project. But this uniqueness also means you must build a relationship between every program and every project. Which means you have to put in extra effort in every project. The good news is, the more connections you build, the faster and better you will get at building subsequent connections.

APIs are definitely the way forward in terms of getting programs to talk to each other but they require extra skills and time that most people don't have. They are also too granular, in that you have to build the connection for every program in every project.

Services

In recognizing that re-building the connections each time is a waste of effort, there are services out there that aim to make these connections more generic. There are currently two schools of thought around this, direct connections and platform services.

Direct Connections

Direct connections are similar to using APIs but they are services that generalize the connections. Meaning you don't have to build a relationship for each project. These services normally come in the form of plugins in some programs. CSiXRevit is an example of a direct connection service that connects Revit and ETABS together.

Platform Services

Platform services are this idea of centralizing all connections. So, instead of building direct connections between programs, you build one to a platform and that in turn connects to multiple programs.

This means that every time you need to connect to a new program, you just have to build one connection to the platform and leverage the other connections you built before. Services like Speckle and BHoM are already trying to do this by providing you with a platform and some existing connections to popular programs. Not to mention, they are both open-sourced too.

Final Thoughts

While the problem of interoperability is still being worked on, there are already a few solutions out there that can help you out. None of them are perfect and with each of them, you are balancing the effort it takes and your control over the data. I frequently use a combination of these methods depending on the size and complexity of my project.

Thanks for reading

Braden