Introduction: Unpacking the “Start with Smart” Conversation
The “Start with Smart” group, now just over ten days old, has rapidly grown into a vibrant community of over 50 participants from across the smart buildings ecosystem. This collective expertise has generated incredibly active and insightful discussions. While many conversations have focused on bridging the BIM-to-Smart gap and operationalising data, a deeper, more philosophical debate has been brewing just beneath the surface.
Having spent over a year facilitating discussions around BIM to Smart Enablement, and previously exploring the evolving role of the MSI, I’ve become keenly aware of the underlying tensions that shape our industry. It’s time to pull back the curtain on one of the most fundamental of these debates: the “Platform vs. Protocol” approach to smart building architecture. This isn’t just a technical skirmish; it’s a foundational choice that dictates everything from integration strategies to the future roles of key professionals.
This article aims to clarify these two distinct philosophical approaches, explore their implications for building owners and operators, and, crucially, connect them to the ongoing evolution of the MSI’s role. My goal here is not to advocate for one side over the other, but to provide a framework for understanding, diffusing some of the passionate advocacy, and, I hope, fostering a more nuanced and productive dialogue for us all.
Before diving in, you can also listen to a podcast discussion about this debate below if you would prefer to listen rather than read:
The Core Divide: Two Philosophical Architectures
At the heart of the smart building revolution lies a fundamental architectural decision that often goes unstated. It’s not about which piece of technology is “better,” but about how one fundamentally approaches the integration and management of a building’s diverse systems. We can broadly categorise these into two philosophies: Platform-centric and Protocol-centric.
The Platform-centric Approach: The Building Operating System (BOS)
Imagine your smartphone. It runs on a sophisticated operating system like iOS or Android. This OS isn’t just about making your phone’s hardware work; it provides a comprehensive ecosystem. It comes with its own suite of essential applications (email, calendar, browser) and, critically, it allows you to download and integrate thousands of specialised apps from different developers. It handles the complex communication between all these elements, presenting a unified, user-friendly experience.
This is the essence of the Platform-centric approach, exemplified by solutions like Trigrr who I visited last month and, from what I understand through industry chatter (though I haven’t been invited to Australia to see for myself!), PlaceOS. These systems position themselves as a Building Operating System (BOS). Their core philosophy is to provide a centralised, holistic platform that acts as the “single pane of glass” for an entire building or portfolio.
Key characteristics of a Platform-centric BOS include:
- Holistic Ecosystem: It provides a comprehensive suite of applications tailored for different user segments – Owners (asset performance, portfolio insights), Operators (facility management, maintenance, energy optimisation), and Occupiers (comfort control, room booking, tenant engagement).
- Integration Layer: The BOS is designed to speak the “native language” of a multitude of existing building technologies – from various Building Management Systems (BMS), HVAC, and lighting controls to access control, AV, lifts, EV chargers, and IoT sensors. It handles the complex task of normalising data, creating consistent naming conventions, and translating across disparate protocols (e.g., BACnet, Modbus, KNX, HTTP, etc.). This means it’s built to manage the complexity of both new and, crucially, legacy building environments.
- User-Centric Design: Beyond simply connecting devices, its primary aim is to deliver actionable insights and intuitive control to end-users, freeing them from technical complexities. It’s about operational outcomes and user experience, not just data flow.
- Centralised Control & Data Model: By providing a unified data model, it offers a single source of truth for building information, facilitating advanced analytics, automation, and reporting across an entire portfolio.
The strength of a Platform-centric BOS lies in its ability to manage the inherent complexity of the built environment, providing a ready-to-deploy, full-stack solution that often prioritises ease of use and immediate operational value.
The Protocol-centric Approach: Open Standards and Device-Level Interoperability
In stark contrast, the Protocol-centric approach focuses on solving the problem at its very root: the device level. Championed by integrators, engineers and the broader open-source community, this philosophy seeks to standardise how every single device in a building communicates, manages data, and reports its status.
A prime example here is UDMI (Universal Device Management Interface). UDMI is an open-source specification providing a standardised, machine-readable format for devices to exchange data with the cloud, receive commands, and perform over-the-air updates.
Key characteristics of a Protocol-centric solution include:
- Vendor-Neutral Standard: The core idea is to create an open, interoperable “language” that all devices can speak. This breaks down proprietary silos and eliminates the need for a separate integration layer to translate between different systems.
- Decentralised Logic: The intelligence is pushed to the edge, with devices having the ability to auto-discover and auto-commission. In new builds, if all devices are natively UDMI-based, the need for a traditional BMS or a central hub to manage them is significantly reduced. The potential consequence, as some point, is that is all the devices in the building are UDMI, then you won’t need a traditional BMS.
- A Focus on the “Plumbing”: This approach is heavily focused on solving the fundamental technical problems that plague our industry. It’s about eliminating the “Arghhh” of inconsistent naming conventions and messy data by standardising the format at the source. It ensures the data itself is clean, verifiable, and consistently structured.
The strength of a Protocol-centric approach is its promise of a more open, future-proof, and fundamentally less complex architecture, particularly in new builds. It’s a technical solution to a technical problem that aims to automate the integration process out of existence.
A Disconnect in Perspective and Expertise
This is not a debate about which approach is “better” in a vacuum. It’s a reflection of a fundamental disconnect in perspective. My analysis of this group’s conversations reveals two distinct viewpoints:
- The Integrator’s/Engineer’s View (Protocol-focused): Many advocates for a protocol-centric approach come from a controls and BMS background. Their frustration stems from the technical chaos of integrating disparate systems. Their solution is a technical one: standardise the protocol. They are rightly focused on what happens at the source, but can sometimes miss the bigger picture—the need for a user-centric application layer that provides dashboards, analytics, and functionality for multiple user segments, which an open protocol alone does not.
- The Holistic Platform’s View (Platform-focused): Conversely, platform providers and FM specialists are focused on the “customer experience” and the “operational front.” They build solutions that manage complexity and deliver immediate value to end-users. Their platforms provide a human-centric layer with applications that help specific user segments manage their jobs and achieve business outcomes. They have often had to build these solutions precisely because the protocols and standards have historically failed to provide a reliable foundation.
This philosophical divide is at the heart of the “Start with Smart” debate. It’s the central tension that shapes how we define value, measure success, and, most importantly, frame the future of our industry.
The Evolving MSI Role: A Symptom of a Deeper Choice
Discussions about the evolving role of the Master Systems Integrator (MSI) are, in my view, a conversation about the symptoms of this philosophical debate, not the root cause. Without understanding the Platform vs. Protocol choice, discussions about new job titles are like talking about fire prevention without mentioning water.
The shift from a fragmented, unstandardised environment to one with greater interoperability creates a fork in the road, and the choice a client makes will fundamentally define the MSI’s function.
- In a Platform-centric world, the MSI’s role shifts from a hands-on, low-level coder to a high-level Master Systems Coordinator or Software Systems Integrator. Their job becomes less about physically making disparate systems talk and more about managing the governance and configuration of a centralised platform. They ensure that all new technologies and data sets are correctly integrated into the existing BOS and that the platform’s applications are aligned with the client’s operational needs. This is a strategic, advisory, and governance-focused role.
- In a Protocol-centric world, the MSI’s role, as James Palmer suggests, could be automated out of existence in new builds. If all devices are natively UDMI and can “auto-discover,” the need for a human translator to bridge technical gaps is eliminated. Instead, the focus shifts to a new kind of role: a Digital Main Contractor who ensures that the correct protocols and data structures are specified and delivered from the ground up, rather than trying to retrofit a solution at the end of a project.
This is not a single path, but a set of diverging paths dictated by two competing philosophies.
Conclusion: Moving Forward Together
The purpose of this article and the “Start with Smart” group is not to declare a single winner in this debate. There is no one-size-fits-all solution; the choice between a Platform-centric and a Protocol-centric approach depends entirely on a client’s specific needs, budget, and risk tolerance.
However, a crucial lesson from this group is that by openly discussing these underlying philosophies, we can all make more informed decisions. We can move from a dialogue of silos and technical jargon to one of shared understanding and strategic alignment. My role as a facilitator is to make this explicit, showing participants that their personal experiences and solutions are part of a larger, systemic debate. By creating a framework that clarifies these choices, we can build the bridges necessary to finally plug the project-operations gap and ensure smarter buildings for all.
If you work in this space and are passionate about solving these problems, I’d love to have your perspective in the group. Just DM via LinkedIn.
