Structural engineering and detailing for data centre programmes.

What makes a data centre different

Structurally, a data hall is not complicated. What makes a data centre programme hard is everything around the structure: the schedule, the repetition, and the fact that the design freezes last where the money is.

• The IT load moves after the frame is designed. Rack density, cooling strategy and equipment selection are still changing when the steel is being ordered, so the structure has to absorb late change without a redesign.
• Everything repeats. One hall becomes eight; one campus becomes four. A detail error is not an error, it is the same error a hundred times, which is exactly the arithmetic that automated checking is good at.
• The plant is heavy and it lives on the roof. Chillers, air handling units, dry coolers and their access steel drive the roof structure more than the roof does.
• The site sets the design basis. Seismic class, wind and snow region and flood level are fixed before the first hall is drawn: flood level sets finished floor and plinth heights, drift behind roof plant screens governs local roof loading, and seismic class drives the anchorage of everything sitting on the roof and every restraint below it.
• Programme dominates everything. A shell that slips does not slip alone; commissioning, fit-out and the client's own service launch slip with it.
• Security shapes information. Hyperscale and colocation clients often run security-minded information management, which changes who receives which model container and what appears in a drawing at all.

The kinds of data centre, and what each does to the structure

The term covers facilities whose structures have little in common beyond a raised floor. What differs between them is where the uncertainty sits.

• Hyperscale campuses — the same hall repeated across a site and then across sites. The structural risk is not the hall, it is whether the twentieth one is genuinely the same as the first after eighteen months of change.
• Colocation — halls handed over in phases to occupiers whose rack density is unknown when the frame is designed, so the structure is sized to a range and that range has to be written down somewhere a later fit-out engineer will find it.
• Enterprise facilities — often built inside or against an existing building, where the governing constraint is the spare capacity of the existing frame and slab rather than anything about the new steel.
• Cloud and managed-service halls — rolled out from a reference design, which only saves time if that reference set is maintained as a controlled document and every site variation is recorded as a delta against it.
• Edge and modular facilities — prefabricated or containerised units landed on a prepared base, where most of the structural scope is foundation, tie-down, craneage and the tolerance between a factory-built unit and a site-built plinth.

The packages a data centre programme needs

Most data centre work is a hybrid: a precast or concrete shell, a steel roof and plant support structure, and a heavily reinforced ground floor and equipment base. We deliver the packages that build it.

• Precast detailing for shell walls, hollowcore floors, columns and beams, detailed on the plant's own mould library so the elements cast and travel as planned.
• Steel detailing for hall roofs, plant decks, catwalks, containment support and generator and transformer structures, issued with the fabrication data the shop runs on.
• Rebar detailing for slabs, pile caps, equipment plinths and the heavily reinforced bases under generators and transformers.
• BIM modelling and coordination across structure, architecture and services, where the coordination load is genuinely the project.
• Drafting and CAD production for the controlled set, the register and the handover documentation the operator will keep for thirty years.

Standards that govern the work

Data centres sit under two families of standard at once: the structural code of the country of construction, and the facility standards the operator designs to.

Structurally, that is AISC 360 and AISC 303 in North America, EN 1993 and EN 1992 with the National Annex and EN 1090-2 execution across Europe, BS EN Eurocodes with the UK National Annex, or AS 4100 and AS 3600 in Australia. Facility-side, the recurring references are EN 50600 and its international equivalent ISO/IEC 22237 for data centre facilities and infrastructure, ANSI/BICSI 002 for design and implementation practice, ASHRAE thermal guidance for the environmental envelope the plant has to serve, and the Uptime Institute Tier classification the client has committed to.

Information management usually runs under ISO 19650, and on secure campuses under ISO 19650-5, which changes federation, distribution and what is modelled at all. Those requirements are agreed at intake and configured into the checks rather than handled by convention.

The resilience class the operator has committed to is a structural input, not only a mechanical and electrical one. Concurrent maintainability — Uptime Institute Tier III, or the equivalent availability class in EN 50600-1 — means any plant item can be taken out of service without stopping the hall, which produces more plant, more access steel and more roof to carry it. Fault tolerance at Tier IV adds physically separated distribution paths, which becomes separate plant rooms, separate risers and compartmentation the structure has to form and keep. Within the EN 50600 family, part 2-1 covers building construction, 2-2 power distribution and 2-3 environmental control, and the first of those is the one that reaches a structural drawing most directly, as separation, access and protection requirements. ASHRAE 90.4 and the TC 9.9 thermal guidance shape the plant the structure ends up carrying.

Where the programme breaks, and what we check

Data centre packages fail in predictable places, so those are the places the automated checks concentrate on.

• Module drift — hall four quietly differs from hall one because a change was applied to some instances and not others. Every repeated module is compared against its reference and the differences are reported, intended or not.
• Penetrations and openings — reconciled between the structural model, the architectural set and the services model, because a slab opening that exists in one of three places is the classic data centre defect.
• Equipment bases and embeds — plinth geometry, holding-down bolts and cast-in items checked against the current equipment supplier drawings, and flagged when the supplier issues a revision.
• Plant loads on the roof — support steel and its connections checked against the loads and positions the drawings actually state.
• Late change — every change issued as a delta against the register, so the shell package and the fit-out package never quietly diverge.

The check record is issued with the package, and a senior engineer reviews and signs it before it goes out.

Delivering at the pace a campus is built

A data centre programme does not fail because the drawings were wrong. It fails because the drawings were late, and then the correction was late as well. The delivery model exists for that: the repetitive production is AI-driven, so a second hall does not cost what the first one did, and a change that touches forty elements is executed and re-checked in the time it used to take to work out which forty they were.

What does not change is accountability. BuildTwin is the delivery partner for the whole scope — one delivery lead, one register, one programme, one company answerable for what is on the drawing, working inside your common data environment and to your standards. Programmes in the United States run the same way — teams there write it data center, the drawings and the checks are identical.