Overview
This post challenges the traditional approach to market analysis, arguing that a Magic Quadrant is ill-suited for the nascent Building Operating System (BOS) market. Instead, it proposes a new, pragmatic framework for evaluation.
The framework defines a BOS not by its name, but by what it’s not (e.g., an API gateway, a BMS supervisor) and then categorizes offerings using a T-Shaped Framework. This framework provides a multi-dimensional lens to assess a platform’s deep, vertical capabilities against its broad, horizontal reach across all key stakeholders (Owners, Operators, Occupants).
The article also introduces the concept of a Performance Digital Twin as a more accurate term for a BOS. This is a conceptual unifier that ties together disparate data types—from static BIM to dynamic BMS—into a living, actionable model of a building, thereby providing a framework for plugging the project-operations gap.
Crucially, this new approach is anchored in a human-centered design lens, which forces a shift from a “data push to data pull” and makes the evaluation vectors a “strategic shopping list” for tangible business outcomes. The post concludes by inviting further discussion to refine this framework.
You can also listen to a summary of this article as an AI podcast if you’d prefer to listen rather than read.
With news of PassiveLogic raising $74 million in Series B funding, I anticipate it won’t be long before one of the market analysts releases a Magic Quadrant or report on the Building Operating System (BOS) market.
I’ve been facilitating a discussion around this in the Start With Smart group I’ve established, which now has over 60 participants. That’s why I think it will be intriguing to see how the market analysts ultimately define a BOS, especially considering the significant product repositioning that has occurred since the BOS concept was launched a few years ago.
One potential source for a definition could be the Smart Buildings Alliance for Smart Cities (SBA) in France; however, adopting their criteria might exclude a substantial number of entities claiming to offer a BOS, potentially making it less commercially viable for analysts.
The “Magic Quadrant” Challenge:
Rather than a Magic Quadrant, perhaps the report could categorize the various platforms claiming to be BOS by their core capabilities:
API Gateways:
These platforms excel at connecting systems and managing data flows (“get data, transform the data, and provide data to someone else”). However, they typically lack a persistent, unified database or knowledge base, managing APIs on the front end without creating a core digital twin model on the back end.
OT Middleware:
These systems are effective in converging data from various operational technology (OT) systems (such as BMS, HVAC, and lighting). Their focus, however, is almost exclusively on the OT layer. The standards they use, like Haystack or Brick, are limited to OT data and often do not accommodate all data types and schemas.
Smart Building Platforms:
Often, these are application-layer solutions that offer user-facing services. While they may connect to multiple data sources, they do not serve as the foundational operating system.
BMS Supervisors:
These are visualisation and control tools for building management systems, serving as a component within the OT ecosystem but not functioning as the overarching system that integrates all data types.
The reason for suggesting this type of analysis is because I think a traditional Magic Quadrant is ill-suited for this market. By proposing to define platforms by their core capabilities (API Gateways, OT Middleware, etc.) or as a kind of strategic shopping list instead, I am trying to avoid forcing a messy market into a clean box. Instead, I am trying to provide a new taxonomy that is, hopefully, more accurate and useful.
The T-Shaped Framework:
Building on this, we could assess offerings through a T-Shaped framework.
Horizontally:
We might examine the breadth of their application across Owners, Operators, and Occupants, including their integration with specialist platforms like IWMS, CAFM, and FDD in the Operator area. This analysis could also consider the modularity of the platforms and their partner strategies, particularly where there are capability gaps and overlaps.
Vertically:
This would be about evaluating the platforms in terms of their full-stack capabilities, viewing this as a layered approach. In the (Independent) Data Layer, it’s crucial to assess their data convergence—whether that includes only OT and IoT data, or encompasses IT, BIM, and other schemas as well. Additionally, examining how they handle Device Naming (agnostically) could yield valuable insights.
At the Device Integration Layer, we would likely focus on two key vectors:
Platform dependencies:
For example, hardware gateways (e.g. Beckhoff, JACE, Delta, etc), specific protocols (e.g. UDMI), middleware (e.g. Niagara), etc.
API library:
Specifically, how far it extends beyond just OT and IoT, encompassing areas like IT and AV.
The idea behind the T-Shaped framework is to provide a multi-dimensional lens. The vertical/horizontal approach is like a SWOT tool for diagnosing a platform’s strengths and weaknesses. That’s because a platform can have deep vertical expertise (e.g., in BMS analytics) but lack the horizontal breadth (e.g., integrations with Owners, Operators, and Occupants). The hope being that the framework gives buyers a clear way to see where a platform’s true value lies.
That’s why another perspective on BOS platforms could involve analysing their historical development trajectory. For instance, does the platform merely layer on top of an existing BMS solution or BMS analytics? Or is it a genuine evolution from a smart building analytics platform or customer engagement app or just the reposition of those solutions?
There may also be an opportunity for an analysis focused on deployment context—where and how the platform is implemented, the extent of its deployment scenarios (i.e., retrofit versus new build), and the markets it serves (i.e., CRE, healthcare, retail, data centres, residential, airports, etc.).
The “Performance Digital Twin”:
Perhaps one distinguishing factor analysts could use to separate the wheat from the chaff is whether BOS platforms provide a genuine Digital Twin. This aspect ties back to the data convergence discussed earlier, as it reveals whether the model is constructed with the BMS at its core or if it adopts a more holistic and relational architecture. Put another way, it’s the conceptual unifier that could tie together all the disparate data types—from BIM (static) to BMS (dynamic)—into a living, actionable model of a buildings.
I can’t shake the feeling that a Performance Digital Twin might be a more accurate term for some in the BOS market, now that so many are claiming to possess one.
A Human-Centred Design Lens?
Lastly, it has also struck me that a human-centred design lens could be integrated more directly into any evaluation vectors and not least by reframing thinking from “data push to data pull.” For example, for each of the horizontal categories (Owners, Operators, Occupants), you could propose a set of questions that a buyer should ask, based on the pains, gains, and jobs-to-be-done.
Operators:
The question isn’t just about “integrating with FDD.” It’s about, “How does this platform’s user interface and functionality reduce a technician’s ‘firefighting’ workload and enable autonomous maintenance?”
Owners:
It’s not just about “integration with IWMS,” it could also be about, “How does this platform directly contribute to tangible business outcomes, including improved Smart Score, WELL or NABERS rating?
That would potentially make the evaluation vectors even more actionable and would firmly position any framework as the perfect antithesis to a purely engineering-centric approach.
Conclusion
While I’m not particularly interested in market analysis per se, I’d love to hear your thoughts on the evaluation vectors I’ve proposed, and if you believe I’ve overlooked anything.
The concept of the Performance Digital Twin, howver, intrigues me, as it might serve as a conceptual framework for addressing the Project-Operations gap. Specifically, it could fit within a Digital Soft Landings framework, exploring how a Minimum Viable Handover Requirement might be integrated. This is why I highlighted the importance of data convergence in the (Independent) Data Layer.
I look forward to further discussion in the Start With Smart group on these data types as we continue to explore this topic. If you would like to join this and related discussion the DM me on LinkedIn.
