The API-first Data Layer

Hey friends,

You can understand a lot about today’s API-second smart building software applications by following the data. It all starts with the data-producing systems in the building—the siloed building systems that typically aren’t so smart:

Much has been written about this silo issue—including our whitepaper on the State of O&M Software—so let’s not belabor it today.

In a nutshell, if I want to deploy a new use case, I need to integrate with these systems to communicate with them1. And that integration is hard—it’s labor-intensive and often takes much longer than it should.

Each company sends their integration team on-site and deploys a full-stack overlay solution—complete with integration hardware/software, a historian database, a mostly-custom data model, some sort of analytics or data transformation, and a user application—on top of the existing silos.

In general, this is the state-of-the-art in smart buildings today…

And then when we want to deploy another use case, we deploy another full-stack overlay, sending the next company’s integration engineers on-site to do their thing.

Now we’re doing some cool stuff with data and providing an app to occupants, but we’ve also created new silos. If we need to connect these new silos, we’re then creating new point-to-point integrations that make it difficult to keep the whole thing updated—there’s no single source of truth on what the data is and what it means in context.

Finally, we’ve created an architecture that’s difficult to adjust and adapt. For example, if I want to fire a vendor and pick a better one, I need to literally start over from scratch for that use case. If I want to pilot multiple vendors and compare them to each other, each will be doing redundant work.

Enter: the API-first independent data layer

Luckily, we’re seeing a TON of companies attacking the problem I’ve laid out here: they go by the names “digital twins”, “building operating systems”, “O&M platforms”, and more. I’ve written a lot about how much I believe in these companies and hope they succeed.

Here’s the thing though: if we’re honest, most of them have that same full-stack-first, API-second mindset that we broke down last week. So let’s do a thought experiment today on what an API-first approach might look like.

First, you wouldn’t build the whole stack. You would split the stack and do your slice better than anyone else. The integration, the data model, and (optionally) the data storage. You would provide that independent of the application and provide the data and metadata through an API.

What would that change? A company with this approach would have:

• Focus: API-first companies focus on solving a very specific problem. That focus means that everything the company does is oriented towards solving all of the problems related to that particular area.
• Unity: Everyone who works for these companies is there to solve this exact problem.
• Leverage: Once these companies reach some scale, they’re able to justify small improvements and edge cases that build up to an incredible product over time. Full-stack companies that dabble in each layer can’t do that.
• Network effects: Similarly, the best API-first businesses have data network effects: the more customers that use the product, the better the product gets for each customer, because the API-first business can use data from one customer to improve the product for all of them.
• Stickiness: They’ll do a whole lot of complicated things behind the scenes, and offer it to customers in a few lines of code that abstract away all of the complexity. That’s tough to replace. At the data layer, this complexity is mostly schlep work. SaaS companies don’t really want to do it.
• Customer-led growth: Because they’ll partner with application providers, API-first companies have a model where the onus is on their customer to grow their own customer base. The API-first company goes along for the ride.

Powerful.

And what about those full-stack software providers that just got their stack chopped up? Well, now they’ll need to compete on how great their application is. That might make them nervous, but since they’re not spending time on non-core sh*t, they should be able to move faster than before. So the best of the best apps will win out.

Finally, and perhaps more importantly, the building owner that chooses this architecture will have choice at the application layer.

“You forced me to come up with a one word answer to this question of what is open. And I said choice, and I think that's ultimately the problem that an independent data layer solves for is giving the owner, the operator, the facility manager choice on what kinds of solutions they want to bring to bear for different kinds of problems within the system.”

—Andrew Rodgers

This means building owners can come closer to putting together their smart building all-star team—where everyone is focusing on their core differentiator.

In this month’s members-only deep dive, we dove deep into this concept by:

• defining the independent data layer
• unpacking the nuances and unanswered questions
• updating the Nexus Vendor Landscape with this new category

Members of Nexus Pro can dive right in and nonmembers can get access at the link below. Enjoy!

Get the deep dive