How do you scale a smart building solution across a property portfolio?

A first smart building project can succeed through sheer effort: a motivated team, a capable integrator and a great deal of manual mapping. Repeat that effort in every building and the programme becomes slow and expensive, leaving a portfolio of one-off solutions that cannot be compared or supported centrally. Scaling works differently. It means standardising what must be the same everywhere and allowing local variation in what depends on each building.

The standard covers the requirements, the data model and naming, the reference architecture, the security baseline, contracts, test scripts and reporting. What varies is the installed systems, the order of use cases and the delivery method for each building. Buildings are grouped into a small number of types and brought on in waves, starting with those that are both ready and valuable, and the effort and results of each wave are measured to improve the next. Above all, the portfolio standard needs funding and governance as a programme in its own right, because the cost of each additional building falls only when that standard exists and is enforced.

The second building is harder

Buildings differ in age, systems, contractors, tenants and operating teams. What made the first project work, often heroic individual effort, does not transfer. Scaling is the search for what can be repeated despite those differences.

A standard in eight parts

There is no need to invent a data model. Brick is an open-source effort to standardise semantic descriptions of the physical, logical and virtual assets in buildings and the relationships between them. Project Haystack standardises semantic data models and web services for working with equipment and IoT data, and Google's Digital Buildings ontology is published openly as well. The sensible course is to choose one as the basis, document any extensions, and require suppliers to deliver data in that form.

For asset information during operation, ISO 19650-3 specifies requirements for information management in the operational phase of assets; its 2020 edition is under revision. At portfolio level, ISO 55000, revised in 2024, describes asset management as aligning asset objectives with organisational objectives across the life cycle. Both are useful frames for deciding who owns the standard and how it is maintained.

Room for local variation

Few portfolios can replace everything with one product set, so the standard should define the interface and data required and leave the choice of manufacturer open, unless there has been a deliberate decision to standardise on one. The order of use cases can also differ: a building with poor metering might start there, while another starts with fault detection. And the delivery route will vary, with some buildings upgraded during refurbishments and others through standalone projects or tenant fit-outs.

Archetypes, not individual buildings

Sorting the portfolio into a small number of archetypes, based on use, size, systems and readiness, makes the programme manageable. A typical set might be large offices with modern building management systems, small offices with basic controls, and buildings with older or proprietary systems. Each archetype gets a standard design and an expected effort, which makes the programme possible to estimate and shows up outliers early.

Rolling out in waves

The rollout follows a learning cycle:

1. Assess readiness for the priority use cases across the portfolio, in enough detail to rank the buildings.
2. Choose a first wave from buildings that are both ready and valuable, and that represent the main archetypes.
3. Measure the effort for each building, in connection, mapping, testing and training hours, together with their causes.
4. Update the standard after each wave with what was learned.
5. Bring in the harder buildings once the method is stable, with enabling works planned where needed.

Centre and site

Some decisions belong at the centre and some locally. Typically the central team owns the standard, the platform, security, supplier frameworks and reporting, while local teams own building operation, local priorities and day-to-day supplier management. The standard itself needs a named owner, a change process and a route for local teams to request exceptions.

Procurement can help or hinder. A framework agreement with a small number of qualified integrators, all bound to the same standard, generally makes scaling easier than tendering each building separately, though it needs active management to keep quality consistent.

Measuring the programme, not just the buildings

The programme's own measures matter as much as each building's: coverage, meaning buildings and use cases live; effort and cost per building by archetype; data quality; adoption by local teams; and the outcomes the use cases were meant to deliver. Of these, falling effort per building is the clearest sign that the standard is working.