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, and in fact it is why the industry has produced standards such as the Construction Specification Institute's MasterFormat, Uniformat and OmniClass. Standards like these exist so that we 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.
Different Construction Pros and Phases Need Different Things
The problem is that different phases need different things. Designing focuses on what gets built, whereas construction focuses on how it gets built. 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 on 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 we went digital.
Where Digitization Comes In
Greater visibility across jobs. Moving data easily. Software does that, but it’s a poor translator. It can’t make up for missing context, and it can’t fill in gaps as humans can.
In the past decade or so, we’ve seen a wave of digitization of construction information. Plans have become models, binders have become databases, 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. Whereas humans are poor transcribers, but great translators; digital systems have the opposite pattern: software is a perfect transcriber, but often a poor translator. Software cannot make up for missing context, cannot fill in the gaps like a human naturally will.
A common complaint is some software systems won’t talk to other systems and that leads to greater frustration levels for all.
Across the construction value chain, one hears the same concerns about data exchanges: this system won’t talk to that system. Because the systems we’re talking about are all actually products from companies who 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.
People Get Frustrated When Data Can’t Be Passed Between Systems
The status quo then has become increasingly powerful tools for collecting data, analyzing that data, and passing the data around within 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 humans get frustrated.
The idea of application programming interfaces is to allow software companies to get around their data silos. APIs can accept and produce data about almost everything going on at a jobsite. They become bridges between data flows or general integration platforms as a service. Or they organize the standards for MasterFormat, Uniformat and OmniClass so they’re easily translatable for all architecture, engineering, construction and building operations professionals. Think Google Translate for construction.
So, the solution to this largely technology-created problem is simply more technology. Specifically, the almighty API.
Enter the API
APIs are exactly what the name implies – they are interfaces where applications can pass information back and forth. Companies such as 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 Zapier can do some of this as well. And of course, the standards that organize all of this can be delivered by CSI's own CROSSWALK API.
We’ll see greater uses of APIs because they power the format-to-format translations that different systems, job phases, and professionals need.
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, and this is why suddenly everything has an API. You can expect to see this newfound ability to easily communicate across systems to continue to knit together different systems, different formats, and different silos as the coming years see networks of APIs flourish, and software systems 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.
Hugh Seaton is product lead for CROSSWALK by Construction Specifications Institute (CSI), a standards-based API for construction. Previously, he was general manager of AdeptXR Learning, a VR/AR software provider.
