“What’s incredible to me about (API-first companies) is that each represents something that a company would have had to build on its own previously, that it can now do by writing a few lines of code, and do better than they would have ever been able to in-house.”
Longtime listeners to the Nexus podcast know my favorite question: Why is the technology in buildings so far behind? I love asking it because I keep getting different, but insightful answers, which help us understand the obstacles we need to collectively overcome to make smarter buildings.
However, after asking it 25+ times, there’s still one answer I believe in but haven’t yet heard: Our industry is behind because we don’t yet have enough API-first companies.
Before I explain, a quick primer on APIs: Software applications are just a bunch of functions strung together to get things done. Application programming interfaces (APIs) wrap those functions in easy-to-use interfaces so you can work with them without being an expert or writing those functions from scratch.
Unfortunately, when we talk about APIs in the buildings world, we often talk about the API as the second option. Software as a service (SaaS) vendors want users to interact with their software through Graphical User Interfaces (GUIs). And they have this API, just in case you need to access your data in another way. In other words, the API is an afterthought.
But outside of our industry, we've seen an explosion of companies taking a totally different approach. They build their API (or APIs) as the primary option and their main strategy is to focus on one part of the stack and do it better than anyone else. They’re happy to be the infrastructure for someone else to solve the user’s problems most efficiently. They’re part of the solution, not THE solution.
When Shopify’s developers went to build merchant software that takes payments over the internet, they didn’t dare build it on their own. They used Stripe’s payments API. When Airbnb’s developers went to build the ability for hosts and guests to text each other, they used Twilio’s messaging API. When Uber’s developers went to build automated driver background checks, they used Checkr’s API.
The decision to be API-first is a first-order decision—all other decisions flow from there. For example, while Square makes hardware and software, that’s not what they sell. They sell their core differentiator: payments for small businesses. In fact, they literally give away the hardware and software for free.
That’s because they want you to use their API to accept payments and they don’t really care how you do it.
Compare that to a company in our industry like Density. Density’s core differentiator is that their sensors count humans anonymously and accurately. But that data stream is not what they sell. They sell the entire stack, from hardware to SaaS.
They want you to use their SaaS to “simplify space planning, manage operating expenses, and meet new workplace expectations with a single platform”, even though all of those things depend on more than just occupancy data. They’re not a part of the stack, they want to be the whole stack.
I’m not knocking Density—if every building in the world had accurate occupancy data I would be ecstatic. I’m simply observing that more often than not, our industry makes the API-second decision Density has made. And I think the implications of these collective decisions are a big drain on our progress because instead of everyone focusing on only what they do best, everyone is doing the same sh*t.
To explain further, next week I’ll dive deeper into one piece of the smart building stack that’s ripe for an API-first company to take over: data infrastructure.
For now, what do you think?
At the Nexus
Here’s what we published this week:
🎙️ #049: Rob Brimblecombe on taking Monash University to Net Zero—This is a fun one... and inspiring too! We talked about Monash University's Net Zero Initiative and how that has driven changes in the way their buildings are designed and operated. And of course, how it changes the technology that runs them.
“I used to chase kilowatt hours and now I'm chasing renewable energy.”
🎥 John Petze on the Shiny Object Problem—"Graphics are the tail wagging the dog."
Signal vs. Noise
Only the best smart building resources we consumed this week…
How building digitalization is changing the Master Systems Integrators focus area—Google’s Sabine Lam on a horizontal system architecture and what that means for a building’s service provider roles.
“MSIs are a key element to a successful deployment of this solution. Their role is evolving towards a much more security and data driven focus area where OT protocols are being replaced with everything communicating IT (MQTT/UDMI) and where the data modeling aspect is a means to enable applications across an entire portfolio instead of specific to one building.”
A Framework for Assessing the “Openness” of a Building Management System (BMS)—This is Schneider Electric’s whitepaper on how BMS can be open. Tridium aside, my sense is that the Big 4 have delayed so long on this topic that most neutral and technical people in our industry assume that you just need to get data out of their systems (See Google’s approach above), rather than execute these new “open” visions (where the BMS is “the” platform that connects everything together).
Nonetheless, I like the framework they laid out in the image above and think you all should read the paper. However, I don’t think it’s open enough. You can contrast it with Matt Schwartz’s definition here. Or Andrew Rodgers’ very simple definition here.
What I’d like to see from the Big 4 is the steps they’re taking to close the gap between the smart people that write these sorts of whitepapers and what’s actually happening in practice via their branch offices and resellers.
Do you agree?
That’s all for this week—thanks for reading the Nexus newsletter by Nexus Labs, a blog, podcast, membership community, and online school for smart people applying smart building technology—written by me, James Dice. If you’re new to Nexus, you might want to start here.