Why every BMS vendor ships a portal nobody wants
BACnet was designed to end vendor lock-in thirty years ago. The vendors still ship proprietary portals. The operators still log into them. Everyone knows this is bad.
The useful thing about the BMS portal economy is that everyone involved already agrees it's broken. Vendors know it. Integrators know it. Every facilities lead who has logged into four of them before coffee knows it. BACnet was ratified in 1995. Modbus is older. The whole point of open protocols was to make this problem go away, and thirty years on the problem is still here.
Which means the interesting question isn't "why don't these systems interoperate". They do, mostly, at the protocol layer. It's "why does every vendor still ship a portal on top anyway, and why do operators keep using them".
Walk through how a typical data centre accumulates this stack. You buy a Siemens Desigo install for the mechanical side. The installer ships a Desigo CC head-end. That's portal one. Honeywell wins the RFP for the next site. Niagara-based head-end, or a Honeywell-branded web client. Portal two. Schneider EcoStruxure shows up somewhere. Portal three. The BESS vendor has its own cloud dashboard. Portal four. Somewhere along the way a DCIM lands — Nlyte, Vertiv Trellis — which imports some of the points from the BMS but not all of them, usually with a six-month lag and a data model that doesn't quite match. Portal five. Everyone said they supported BACnet. Everyone does. That isn't where the lock-in lives.
The lock-in lives in the graphics package. It lives in the alarm configuration. It lives in the trending database that someone spent six weeks tuning, which will need re-tuning if you migrate to anything else. It lives in the hundreds of hours of integrator time already invested in one specific head-end, and the dozen custom objects built on top. Moving off the portal isn't a protocol migration. It's a tool migration, and those are always expensive.
Tridium's Niagara Framework was meant to be the answer to this. It's an open integration layer that speaks BACnet, Modbus, LonWorks, OPC, SNMP, MQTT, and roughly everything else via drivers. More than a million Niagara installations exist globally. It's the closest thing the industry has to a Linux, a neutral platform on top of which vendors compete.
Niagara itself was acquired by Honeywell. Which is fine as a corporate outcome and slightly awkward as a category framing. The "neutral" integration layer is owned by one of the vendors the neutrality was supposed to counterbalance. Nobody I've spoken to thinks Honeywell has done anything material to compromise the platform. The structural position just exists.
The more practical issue is that Niagara at the integration layer doesn't solve the dispatch problem sitting above it. Niagara is extraordinary at normalising BACnet points, running control logic, and surfacing alarms. It isn't trying to be a grid-market bidding engine, a BESS dispatch optimiser, or an imbalance-settlement scheduler. Those are different jobs that require different data models, different latencies, and different security postures. Which means operators who have done the Niagara consolidation still end up with a grid tab somewhere else, which is its own smaller version of the sixteen-tabs problem.
What this looks like operationally is an operator running a unified Niagara head-end for HVAC, power, and white space, and a completely separate stack for market participation. The two talk only via exports. Sometimes via CSV, copied by hand. In the year 2026.
A thing worth naming. Every BMS vendor I've spoken to in the last eighteen months has acknowledged, in private, that their customers want a thin API surface more than they want a thick portal. Most of them have roadmaps that include broader REST API exposure, webhook support, native time-series export. The roadmaps have mostly been there for three or four years. Adoption has been slow because the commercial incentive is aligned with keeping the head-end visible. Portal usage is the metric vendors use to argue for renewal. Thin API usage is harder to count and therefore harder to defend in account planning.
Which is also fine. The vendor business model is what it is. The problem it creates for operators is separable from the judgement of the vendors making the choice.
What tends to work, from the sites I've seen handling this well. Treat the BMS as the ground-truth layer for mechanical and electrical, accept that its portal will exist, and build a control surface above it rather than trying to replace it. The control surface talks to the BMS through whatever API the vendor actually supports — BACnet/IP as the fallback, REST where available, a Niagara integration where present. The control surface is the dispatch and market-engagement layer. The BMS stays as the physical-layer system of record. Two tools, distinct responsibilities, clean interface between them.
The hard part of that architecture isn't the technology. It's convincing facilities and operations they don't need to fight the BMS vendor to win. The BMS vendor isn't the enemy. The dispatch decisions are happening one layer above, and that's the layer that needs to be built well.
Is anyone shipping that control surface at production quality across a multi-vendor estate today? Fewer than you'd think. More than were shipping it a year ago.