We spent a surprising amount of time in a customer meeting recently discussing the role of the MSI. Who would the MSI be? When would they be appointed? What would they integrate? How would they commission Switch?

There was one small problem. There wasn't an MSI yet.

Increasingly, we find ourselves responding to smart-building RFPs where the Master Systems Integrator appears throughout the specification as a future, somewhat mystical third party that will eventually arrive and make all the systems work together.

That model made sense once. I'm not convinced it reflects how many smart-building projects actually work in 2026.

What did an MSI traditionally do?

In the traditional smart-building architecture, the MSI had an important job. Buildings contained systems from multiple manufacturers using different protocols, naming conventions and control architectures. Someone had to make them work together.

The MSI typically provided the integration layer, often using middleware such as Tridium Niagara, connected the building systems and commissioned the resulting integration.

For a large, complex building, that model made considerable sense.

The problem isn't the MSI. The problem is assuming every modern smart-building architecture still needs that same MSI model. The building has changed. So has integration.

Enterprise systems don't necessarily pass through a site-based MSI. SaaS sensing platforms frequently arrive already cloud-connected. Existing buildings already contain installed systems.

Integration is not the same in this new architecture. Integration is a capability distributed across the architecture.

The problem becomes even clearer at portfolio scale

Global portfolios need a deployment model that works in India, Chile, Singapore, London, Tokyo and a bunch of small branch locations. Not every geography has the same integration capability available, and few customers have the budget to deploy a single integration team globally.

You shouldn't design every building as though it's a flagship building with a large BMS and an MSI standing inside it.

One Portfolio Standard. Different Deployment Pathways

Some buildings may have limited controls and start with utility, meter, enterprise or cloud data. Others have a BMS but limited sensing. Flagships may contain BMS, lighting, power, IAQ, occupancy, elevators and workplace systems. Yet all can conform to the same portfolio standard.

So, what is the MSI's role now?

We increasingly define the MSI as the site integration specialist, rather than the owner of the entire integration architecture.

The local integrator connects the building. The platform standardizes and validates the data. The customer owns the standard.

This doesn't mean the MSI disappears

For a new flagship development containing many systems, an experienced MSI can be enormously valuable. There are also projects where the MSI has broader responsibilities and expertise.

Don't design the architecture around an MSI simply because that's how smart-building projects were structured fifteen years ago.

Start with the architecture, portfolio and systems that actually exist. Then determine what integration capability is required and who is best placed to provide it.

So, do you want an MSI with that?

Maybe. If you need someone on site to connect building systems, configure gateways, resolve field issues and prove the data flow, absolutely.

But if the MSI is being asked to somehow sit between every building system, cloud service, enterprise application and smart-building platform simply because “that's what the MSI does”, it may be time to revisit the architecture.

The question in 2026 isn't “Who's the MSI?”

It's “What needs integrating, where should that integration happen, and who is best placed to do it?”