How do you design an ICT network for a smart building?

A smart building network should be designed from the services it must carry, not from a switch catalogue. Those services include building automation, security systems, metering, lighting, lifts, tenant and guest connectivity and remote support, and they differ sharply in what they need for availability, power, security and ownership. The design task is to group them sensibly, give each group the protection and resilience it needs, define exactly what may communicate across the boundaries, and make sure somebody is responsible for running the result after handover.

That brief cannot be written by the ICT designer alone. It needs the controls, security, electrical and facilities teams around the table, and it should treat connected building devices as operational technology. They are not ordinary office endpoints.

Everything that will connect, on one schedule

The foundation is a schedule of everything that will connect, organised by service:

The less visible items belong on it too: gateways, servers, supplier remote-access appliances and links to external services. Everything that follows is derived from this schedule, so it should be kept up to date through construction.

From schedule to cables, cabinets and switches

The schedule then drives the physical infrastructure. Pathways and containment need sizing with documented spare capacity, tied to a growth scenario that says what the space is for. Telecommunications rooms and cabinets need power, cooling, security and maintenance access appropriate to what they host. Cabling generally means horizontal copper for endpoints and PoE and fibre for backbones and long runs, tested and labelled to the agreed standard. Switching is sized by port count, PoE budget and uplink capacity per cabinet, and wireless coverage is surveyed or predicted for the actual materials and layout.

Getting the spare capacity right takes judgement. Oversizing everything without a growth scenario consumes budget without adding resilience, while undersized pathways are expensive to correct once ceilings and risers are closed.

Boundaries have to be decided while the design is open

Systems should be grouped into network zones according to risk and operating responsibility, with the permitted communication between zones defined. NIST's guide to operational technology (OT) security, SP 800-82, includes building automation systems within OT, where availability and safe physical operation are priorities alongside confidentiality, and it describes segmentation and controlled boundaries between zones as a core architectural measure.

For the network designer, the critical point is timing. The zones, the firewalls or access lists between them and the administrator of each must be settled while the switch, cabinet and cabling design is still open, because they determine port allocation, the number of physical or virtual networks per cabinet and where boundary devices sit. A rule set written after installation ends up documenting whatever the contractors happened to build, and segmentation that exists only on a drawing protects nothing.

When a switch loses power

For each critical service, the question is what happens when a component fails. A backed-up controller gains little if the switch it depends on loses power first. Mapping the chain from endpoint to switch to uplink to upstream power shows where uninterruptible power and redundant links are justified, and just as usefully where they are not: not every sensor network needs the resilience of the security system.

Recovery matters as much as redundancy. Configuration backups, spare parts, documentation and access to qualified support determine how long a failure actually lasts.

The same thinking extends to operation. Someone has to run the network, whether the landlord's IT team, a managed service provider or the systems integrator, and the arrangements for requesting and approving changes, updating firmware, granting and revoking supplier access and reporting incidents need agreeing before handover. A smart building network that nobody is contracted to run degrades quickly.

Commissioning the services, not just the cables

Pathways, labelling and cable performance all need testing, but so do the services the network carries. Commissioning should show that each device reaches only what it should, that PoE budgets hold with every device drawing power, that remote access is logged, and that the agreed services continue during a simulated loss of internet or of a core switch. The handover should include as-built drawings, an updated endpoint schedule, configuration backups and the rule set for each boundary.