What is the difference between a smart building and a building management system?

A building management system (BMS) is a product: the controllers, network and supervisory software that schedule, monitor and control services such as heating, ventilation, air conditioning and often lighting. A smart building is an operating outcome: systems, data and people working together so that the building responds to how it is actually used. The BMS is usually one of the most important ingredients of a smart building, but it is rarely the whole recipe.

The distinction has a price tag attached. Owners are regularly offered a new "smart" platform to fix problems that actually sit inside the BMS they already own, because it is under-configured, poorly maintained or barely used. Just as often the reverse is true, and the problem cannot be solved inside the BMS because it depends on information the BMS never sees. Telling the two situations apart is the first thing to do before spending anything.

What a BMS is built to do

The US Department of Energy describes building controls as the integrated management of HVAC, hot water, lighting, conveyance and other systems, and notes that modern control systems typically run building-specific protocols such as BACnet over ordinary IP networks. A well-specified BMS already handles time schedules, setpoints and control sequences for plant and terminal units. It raises alarms, keeps trend logs and event histories, and gives operators graphics and manual overrides. It records energy and runtime data for the equipment it controls, and DOE notes that such systems can also provide automated fault diagnostics.

What any particular building actually gets, though, depends on the installed version, the licences bought, how much of the plant was integrated and whether the sequences were commissioned as designed. A datasheet tells you what the product can do; only a site survey tells you what your building does.

Where a smart building brief goes further

A smart building brief starts from outcomes, and those outcomes often cross system boundaries. Linking a room-booking system to room conditioning is one example. Others include turning a persistent fault into a maintenance work order, comparing performance across a portfolio, or giving tenants controlled access to their own data. Each needs information from more than one system, and each step needs an agreed owner.

The table below shows where the line typically falls.

The right-hand column is where additional integration, an independent data layer or a separate application may be justified. The left-hand column is where a better-configured BMS is often the cheaper and more robust answer.

A simple test before you buy

The surest way to find out which problem you have is a short gap test, run while no platform has yet been bought.

Write the outcome as a task someone will perform, such as: "when a fan-coil unit raises the same alarm three times in a week, a work order is opened in the maintenance system against that unit, with the alarm history attached". Then ask the BMS supplier to demonstrate it on your own equipment and data, because a showroom site cannot show how the function will behave in your building, and note which parts work as configured, which need configuration or licences, and which the product cannot do at all.

Price the configuration route first: engineering time, additional licences, sensor repairs and recommissioning. Only then price the alternative, a separate application or data layer, including integration, subscriptions, a second set of user accounts and the support relationship it brings with it. Compare the two over the same period, and be clear about who will operate each one day to day.

If the BMS route closes most of the gap, a new platform needs a justification of its own. If the task depends on data from several systems, or on information staying usable after the BMS supplier changes, the case for an additional layer grows stronger.

Integration moves responsibility around

Connecting a BMS to other systems changes who is accountable for what. A temperature alarm may originate in the BMS, a maintenance system may assign the work, and an engineer closes it. Somebody has to own asset identity across those systems, the rules for prioritisation and the definition of "resolved", and none of that is automatically part of a controls contract.

The security picture changes too. NIST's guide to operational technology security (SP 800-82) treats building automation as operational technology, where availability and safe physical operation matter alongside data protection. Every new connection to the BMS should state what it reads, what (if anything) it may command, how access is authenticated and what happens when the connection fails.

Five questions for the supplier

A few direct questions will reveal most of what you need to know:

• Which of our stated outcomes can the existing BMS deliver now, and which require configuration, licences or hardware?
• Which functions run locally in controllers, and which depend on a server or cloud service?
• What data can we export, in what format, at what interval and at what cost?
• If you propose an additional platform, what does it do that the BMS cannot, and who maintains the connection between them?
• What remains operational if the additional platform is unavailable?

The real decision

The choice is never "BMS or smart building". It is which outcomes justify new scope, and where that scope should live. Once the missing outcome, the existing capability, the owner of each interface and the acceptance evidence are written down, bidders can be asked to show exactly how they would close that specific gap.