Construction is famously fragmented, with dozens of companies on a given job using their own software, processes, and formats for working, producing information and communicating data and materials. This problem is not new—in fact, it is why the industry has produced standards such as MasterFormat, Uniformat and OmniClass. Standards like these exist so contractors can organize and keep track of the hundreds of thousands of items that come together to become a building, and communicate the quantities, costs and schedules required for that coming together—otherwise known as construction.

The problem is that different phases of construction need different things. Designing focuses on what gets built, whereas construction focuses on how it gets built, and so on. Translating the work product of different teams in different phases wasn’t an issue when that meant a human looking at one sheet of paper and interpreting information to fill in another sheet of paper. Humans are much better at this than is often recognized, despite the odd transcription error. So the industry adopted practices such as material takeoffs—it’s easy to forget that term means the process of “taking” the number of some item, like wall panels, windows or door knobs, “off” a plan. The trouble is that humans are fantastic translators, because we understand the context of a plan, and the numbers in it; but we are not great transcribers, so errors creep in. The speed, expense and errors of humans as transcribers is one of the reasons why many contractors went digital.

In the past decade or so, the industry has experienced a wave of digitization of construction information. Plans have become models, binders have become databases, and entirely new capabilities like process optimization and analytics have become possible as a result. The benefits of digitization are truly new levels of visibility into individual jobs, and across jobs. Moving data from one place to another doesn’t require a person to do the transcribing, it often just takes a few keystrokes. On the other hand, just like humans are poor transcribers but great translators, digital systems have the opposite pattern: software is a perfect transcriber, but poor translator. Software cannot make up for missing context, cannot fill in the gaps like a human naturally will.

Across the construction value chain, one hears the same concerns about data exchanges: this system won’t talk to that system. Because the systems are all actually products from companies that have to invest significant time and resources to create those products, they’ll often create their own barriers to exchanging data—internal standards and formats that don’t translate to other systems and products. To say this has driven some product users a little nuts is an understatement, especially sub-trade contractors who often have to support multiple platforms for their different general contractor partners.

The status quo then has become increasingly powerful tools for collecting data, analyzing that data and passing the data around in a given system. We have come to expect digital data to be instantly, frictionlessly useful and available wherever we need it, so when we can’t pass it between systems easily, we get frustrated.

The solution to this largely technology-created problem is...more technology. Specifically, the almighty API. Application Programming Interfaces are exactly what the name implies: interfaces where applications can pass information back and forth. Companies like Procore and Autodesk are getting around the data across silos problem with a marketplace and huge APIs that accept and produce data about almost everything going on at a jobsite. Consultants are building customized bridges between data flows, general integration platforms as a service (IPaaS) like Tray.io and the much-loved Zapier can do some of this as well. The standards that organize all of this can be delivered by CROSSWALK API.

APIs don’t automatically solve the translation problem, but they provide a fast and reliable “pipe” that can power the format to format translations that different systems need. On either end of the API, there will need to be some data-mapping, but that’s also a process we’re getting pretty good at, and once mapped, how data goes from one system to another gets much easier to manage.

APIs have been around for decades, the advent of REST APIs made them easy to use, which is why suddenly everything has an API. Expect to see this newfound ability to easily communicate across systems to continue to knit together different systems, different formats and different silos. In the coming years, networks of APIs will flourish and software systems will become just as good at translating data from one phase of a construction process and from one system to another as they have always been at faithfully transcribing them.