A few years ago we were brought into a 1.5-million-square-foot office portfolio for a procurement diagnostic. The owner had received a quote, from the incumbent building-management-system integrator, for a portfolio-wide upgrade. The number was $40 million. The work was real — sixteen-year-old hardware that had reached end-of-support, control software that had stopped receiving security patches, and a documented case for replacement before the next major lease cycle.
The quote was not unreasonable for what it described. The quote was unreasonable for what the owner actually needed.
We decomposed the line items over six weeks. Hardware replacement at the controllers and field-device level: $11 million. Network and edge infrastructure: $6 million. Software-licensing, support, and training: $8 million. Integration and commissioning: $15 million. Of that $15 million in integration, roughly $9 million was attributable to interoperability work between subsystems the incumbent had specified deliberately to remain proprietary. The owner had been paying that integrator’s premium for sixteen years. The $40 million quote was, in effect, a renewal of that premium for the next twenty.
The owner’s alternative path, executed with open protocols and a different integrator selection, came in at $18 million. Same hardware quality. Higher software capability. Comparable training and support. No proprietary integration tax.
That $22 million swing is what walled-garden BMS architecture costs institutional CRE owners. Spread across the US institutional commercial inventory, the same dynamic plays out tens of thousands of times a year. The walled-garden bill, paid quietly across the industry, is in the tens of billions of dollars annually.
This is the integration-and-interoperability essay. It’s the most technical of the ten. It is also the one that most directly determines whether the previous nine work.
The 1980s mistake we’re still paying for.
The modern building-management-system industry took shape in the 1980s, when each major vendor — Johnson Controls, Honeywell, Siemens, Schneider, Carrier — built proprietary protocols for the controllers in their portfolio. There was no industry-wide standard. There was no interoperability requirement. The vendor with the densest installed base in a given building had structural pricing power over the next twenty years of capex against that building.
This was not malicious; it was the engineering norm of the period. Networking standards were immature. The cost of standardization conversations was high. Vendor-specific protocols were the rational engineering response to a fast-evolving control-systems landscape.
The rational engineering response also produced a market structure that became expensive for customers. Switching costs were high. Multi-vendor coordination was punitive. The integrator channel that developed around the vendor protocols had economic interests aligned with the incumbents, not with the asset owners.
Most of the institutional commercial inventory in the US still carries the 1980s protocol legacy at the controller layer. The asset owners who write the checks today are paying for engineering decisions made forty years ago.
The half-fix that was BACnet.
BACnet — Building Automation and Control Networks — became an ASHRAE standard in 1995 and an ISO standard in 2003. The protocol was designed to standardize communication between BMS components from different vendors. It worked, partly.
The standardization solved one problem and created another. Different vendors implemented BACnet differently — sometimes with vendor-specific extensions that needed translation, sometimes with implementation-level quirks that created subtle interoperability gaps. The integrator who could navigate the inter-vendor BACnet landscape became more valuable, not less.
The current state of BACnet adoption in US commercial real estate is roughly: most field-level devices speak BACnet, most controllers speak BACnet, most enterprise-level BMS supervisors speak BACnet — but the integration work between them remains substantial, and the integrator’s specific implementation knowledge remains a real moat.
The Niagara story.
The most consequential single piece of building-automation software of the past 25 years is the Niagara Framework from Tridium, now owned by Honeywell. Niagara emerged in the late 1990s as a vendor-neutral middleware layer that could translate between BACnet, Modbus, LON, and proprietary protocols and present a unified data and control surface to upper-level software.
Niagara was a real engineering accomplishment. It also became, over the past two decades, a near-monopoly in its category. A substantial share of the integrator workforce in US commercial real estate is Niagara-certified; a substantial share of the BMS supervisor installations run on Niagara; the integrators’ economic interests are aligned with continued Niagara dependency.
The result, paradoxically: a translation layer that was supposed to break vendor lock-in has become a vendor lock-in of its own kind. Owners now sometimes pay a Niagara-integration premium on top of the BACnet-implementation premium they were already paying. The translation has solved the technical problem and entrenched the economic one.
The 2020s opening, which we describe next, is partly a response to this dynamic.
The 2020s opening.
Four protocol developments in the past five years are reshaping the integration landscape meaningfully.
Matter (Connectivity Standards Alliance, originally Project CHIP), is the IoT-device interoperability standard developed by the Connectivity Standards Alliance. Matter is most associated with consumer smart-home product, but its application to commercial-grade IoT in buildings — lighting, sensors, access control, environmental — is real and gaining traction. The Matter ecosystem is open, multi-vendor, and explicitly designed against the walled-garden architecture of the consumer smart-home category.
BACnet/SC, mentioned above, modernizes the field-level building-automation protocol for the cloud-and-internet-routing era. Adoption is being driven by federal cybersecurity-compliance requirements alongside owner pressure for vendor-neutral options.
Model Context Protocol (MCP) (Anthropic, November 2024; donated to the Agentic AI Foundation — a directed fund under the Linux Foundation — in late 2025), is the most important integration development from outside the building-automation industry. MCP defines how AI agents interface with external tools, data sources, and execution environments. For commercial real estate, it means an AI agent can interact with the BMS, the EMS, the work-order system, the access-control system, and the tenant-engagement platform through a single standard interface, without bespoke integration per system.
The combined effect of MCP and the modern AI-agent frameworks is to flatten the integration-work-required curve at the agent-and-data-platform level. The asset owner’s $9 million proprietary-integration tax becomes harder for the incumbent integrator to defend on technical grounds.
Brick Schema and Project Haystack, the two leading open building-data-modeling efforts, have made meaningful progress on the semantic-interoperability problem in the past five years. Both projects publish open standards for tagging building data — what’s a chiller, what’s an AHU, what’s a tenant zone, what’s the relationship between them — so that AI agents and analytics can reason across systems without bespoke integration.
Brick Schema and Project Haystack.
The two projects deserve a deeper look because they together solve the semantic problem that BACnet-and-Niagara solved only partially.
BACnet standardizes how data flows between systems. Brick and Haystack standardize what the data means. A BACnet message that reads “AI 1234 = 72.4” is interoperable at the network level but illegible at the application level — what is AI 1234? a zone temperature? a supply-air temperature? a return-air temperature? in which space? referenced to which equipment? Without the semantic layer, every analytics or AI-agent application has to rebuild the meaning from scratch per building.
Brick Schema is a formal ontology, originally developed at UC Berkeley, that defines the relationships among building entities, equipment, and data points. Project Haystack is a more pragmatic tagging convention that has wide industry adoption among integrators and BMS vendors.
The two projects are partially overlapping and increasingly interoperable. The right disposition for an institutional owner specifying a new platform in 2026 is to require native support for both, with the data model published and the schema extensible. Vendors who can produce this are credible. Vendors who can’t are selling the previous generation.
The economic argument for owners.
Strip the architecture down to dollars. Open protocols, owner-controlled data, and vendor-neutral integration produce three economic effects across a twenty-year asset life-cycle.
Lower switching costs. The owner who chooses an open-protocol platform in 2026 can replace any single subsystem — the BMS, the EMS, the access-control, the work-order system, the tenant-engagement application — without rebuilding the integration. The negotiating power across each replacement cycle shifts toward the owner.
Lower integration costs in the first deployment. A platform that natively speaks BACnet/SC, Matter, Brick, Haystack, MCP, and a few standard APIs requires meaningfully less custom integration work than a platform that requires bespoke translation per subsystem. Our experience suggests 40 to 65 percent lower integration cost for an equivalent capability footprint.
Higher data-portability at exit. The owner who sells the asset can hand the buyer a complete operating record in standard schemas. The buyer can underwrite against verifiable data. The pricing reflects the reduction in information-asymmetry risk. This is the cap-rate-compression mechanism described earlier in the series, made operational.
Across a typical institutional twenty-year asset life-cycle, the open-protocol path produces ten to fifteen million dollars of net present-value savings on a 1-million-square-foot office or mixed-use asset, conservatively. Across a portfolio of ten such assets, it produces a number that registers at the fund-level economics.
The integrator economic problem.
There is one structural opponent to open-protocol adoption worth naming directly: the integrator channel. The integrators who installed the proprietary-and-Niagara-heavy infrastructure of the 2000s and 2010s have, in good faith, built businesses around the configurations they understand. Open-protocol architectures threaten parts of that business.
This is not a moral problem; it is a structural one. The integrators are responding to the economic incentives the prior generation of architecture created. The fastest way to align the incentives is to write the contract differently in the 2026 procurement cycle: pay for capability and outcomes, not for hours; reward the integrator for portable installations rather than for proprietary moats; specify the open protocols in the RFP rather than relying on the integrator’s preferences.
The integrators who recognize the shift will retool. Several of the larger ones already have. The integrators who don’t will lose share over the next ten years. The market is sorting itself out. Owners benefit from accelerating the sorting.
A protocol-by-protocol scorecard.
For owners specifying a platform in 2026, here is the maturity scorecard.
BACnet IP and MS/TP: mature, ubiquitous, the floor of any serious platform. Required.
BACnet/SC: emerging, well-specified, the right requirement for new installations. Required for greenfield.
Modbus TCP and RTU: mature, common in legacy and industrial-flavored deployments. Required for compatibility with installed base.
Matter: emerging in commercial, well-established in residential adjacent. Required for new IoT deployments.
OPC UA: mature, common in industrial integrations and increasingly in large-campus deployments. Required for industrial-adjacent assets.
MQTT: mature, foundational for IoT data flows. Required.
Brick Schema: emerging-to-mature, with growing native support. Required as the semantic layer.
Project Haystack: mature among integrators, well-supported. Acceptable alongside or instead of Brick.
Model Context Protocol: emerging, will be central within 36 months. Required for any platform claiming AI-agent capability.
A platform that natively supports the items marked “required” is a credible 2026 platform. A platform that requires custom translation for any of them is selling the previous generation.
The four questions for vendor selection.
From the owner side, four direct questions sort credible platforms from incremental ones.
One. Show me your data schema, published. Open source or open access. If the data lives on the vendor’s platform under a proprietary schema, you are renting the asset’s operating record.
Two. Show me the protocols you natively support, with documentation. “We integrate with all major systems” is a hand-wave. The credible answer is a published list.
Three. Show me your export capability. Specifically: how do I extract the last 24 months of asset telemetry, in a standard schema, on demand, in under an hour? If the answer requires a service ticket and a fee, the asset’s operating record is captive.
Four. Show me the cost of moving to a different platform in five years. The vendor who can give a credible answer is offering an honest deal. The vendor who can’t is offering a lock-in.
The vendor who answers all four well in the procurement cycle is the right counter-party. The vendor who hand-waves any of them is the wrong one.
Open protocols are capital-markets policy.
The argument we make to institutional owners is not, ultimately, a technical one. It is a capital-markets policy argument.
The asset whose operating record lives on open protocols, in owner-controlled infrastructure, supports a CRREM forecast, a GRESB Performance score, a CSRD disclosure package, and an SEC-rule-compliant climate-risk report. The asset whose operating record lives on a proprietary platform supports only what the vendor’s data-export feature lets it support, on the vendor’s terms.
The first asset is underwriteable by the institutional capital pool that is increasingly screening for documented sustainability data. The second is not, or is underwriteable only with a discount that prices the lock-in.
Open protocols are not idealism. They are the procurement choice that determines whether the asset is fundable by 2028’s marginal bidder. The institutional owners moving deliberately on this in 2026 will own the easier-to-finance portfolios in 2030.
Sources cited
- ASHRAE. ANSI/ASHRAE Standard 135 (BACnet); BACnet/SC, Standard 135-2020. ashrae.org.
- Modbus Organization. Modbus Application Protocol Specification, V1.1b3. modbus.org.
- OPC Foundation. OPC Unified Architecture (OPC UA) Specification. opcfoundation.org.
- OASIS. MQTT v5.0 Specification. oasis-open.org.
- Connectivity Standards Alliance. Matter v1.2+ Specification. csa-iot.org.
- Brick Schema Consortium. Brick Ontology v1.3 (Balaji, B., et al., UC Berkeley initial development). brickschema.org.
- Project Haystack. Tagging Conventions and Type System. project-haystack.org.
- Anthropic. (2024). Model Context Protocol Specification, released November 2024; donated to the Agentic AI Foundation (Linux Foundation) in late 2025. modelcontextprotocol.io.
- Tridium / Honeywell. Niagara Framework Architecture documentation.
- Verdantix. Smart Building Technologies Buyer’s Guide.
- Memoori Research. Smart Buildings Reports.
- U.S. General Services Administration. Federal-tenant Smart Buildings procurement guidance.
Chronis Pantelemidis (CPO) and Dr. Neil Smith (Research Advisor, UC San Diego) lead the platform-architecture work at Smart City Labs. To discuss protocol-and-integration strategy at your portfolio, talk to our team.