For twenty years, "building integration" in Australia meant the BMS vendor's head-end absorbing everything else — lighting, metering, sometimes security — as secondary points on their own proprietary system. The next generation of Australian smart buildings is being organised differently: around an independent, vendor-neutral data layer that treats BMS, security, metering and lift systems as peer sources, with a master systems integrator (MSI) responsible for the layer itself rather than any one underlying system.
Why the BMS-as-Master Model Is Breaking Down
A BMS-centric integration model works cleanly until a building needs to feed data to something the BMS vendor never anticipated — an AI analytics platform, a tenant workplace app, a portfolio-wide sustainability dashboard. Each of these becomes another point-to-point integration bolted onto the BMS head-end, and by the third or fourth such integration, the BMS vendor's software is doing double duty as both a control system and an ad-hoc data broker it was never architected to be. An MSI model inverts this: a dedicated, protocol-agnostic middleware platform sits above all building systems, and the BMS becomes one peer data source among several, not the hub everything else has to integrate through.
What the Integration Platform Actually Does
- Normalises data from BACnet/IP, Modbus TCP, OPC-UA and proprietary vendor APIs into a single consistent data model, typically exposed via MQTT or REST for downstream consumers.
- Hosts the semantic tagging layer (Haystack or Brick) discussed elsewhere in this series, so every consuming application — analytics, workplace app, digital twin — sees the same point meaning regardless of source system.
- Provides a single point of access control and audit logging for third-party integrations, rather than each vendor needing separate credentials into separate underlying systems.
- Sits physically as a server (on-site or virtualised) in the building's comms room, with a cloud-hosted counterpart handling portfolio dashboards and remote access — mirroring the edge/cloud split used in predictive control architectures.
Design takeaway: Specify the integration platform as its own line item on the ELV single-line diagram and procurement schedule, with an explicit vendor-neutrality requirement — a platform proposed by the BMS incumbent, built on their own proprietary protocol, is not an MSI layer regardless of what it's marketed as.
Procurement: Novated MSI vs Design-Bid-Build
Two procurement models dominate current Australian practice. In a novated MSI contract, the integration platform vendor is engaged directly by the owner from design stage and novated through construction, giving them authority to define data contracts with every other ELV subcontractor from day one — the cleaner model, but it requires the owner to commit to an integration-first mindset earlier than most projects are used to. The more common design-bid-build variant treats the integration platform as a late-stage addition once other systems are already specified, which works but shifts risk onto the MSI to retrofit data contracts against systems that weren't designed with integration in mind — usually at higher cost and with more compromise on data completeness.
Who Owns the Platform After Handover
This is the governance question that determines whether the investment holds its value. If the integration platform's configuration lives entirely inside the MSI's proprietary toolset with no documented handover, the owner is functionally locked into that contractor for the life of the building. The defensible position — increasingly written into Australian MSI contracts — is that the owner licenses the platform directly, with clear documentation of data contracts, tagging schema and API access delivered as a formal handover deliverable, whether or not the same contractor continues in an ongoing managed-service role.
Frequently Asked Questions
How is an MSI different from a traditional BMS contractor?
A BMS contractor integrates systems around their own vendor's controllers and protocol, with other systems bolted on as secondary. An MSI is protocol- and vendor-neutral by design, building a middleware layer that treats BMS, security, metering and lift systems as peer data sources feeding one integration platform, rather than the BMS being the master.
Where does the integration platform physically sit in an Australian building?
Typically as a server (physical or virtual) in the main comms room or a small on-site data hall, with a cloud-hosted counterpart for portfolio-level dashboards and remote access — the split usually mirrors the same edge/cloud split used for AI-driven building operations.
Who should own the integration platform after handover?
This needs resolving at procurement, not left ambiguous. Common Australian models are the building owner licensing the platform directly (with the MSI as implementation contractor only) or the MSI retaining an ongoing managed-service role — the owner should avoid a model where the platform's continued operation depends entirely on one contractor's proprietary configuration with no handover documentation.