The Chassis Problem

DATA CENTRES take three to four years to build and are expected to last thirty. However the AI hardware inside them now updates every twelve months, often faster. So what exactly do you design for ?

At CES, Jensen Huang unveiled Nvidia’s next-generation AI platform, Rubin. When he explaining how quickly things change, he offered a telling one-line summary:

“Basically everything is brand new except for the chassis.”

The outer shell stays. Everything inside it transforms. Nvidia claims Rubin delivers five times the inference performance of its predecessor, Blackwell. And Blackwell was a leap from Hopper, a GPU that is less than 4 years old. The sector now has an annual rhythm for AI infrastructure, each generation being dramatically more prowerful than the last. With this exponential change, how do you design today for a building that is unlikely to be operational until 2029 at best?

Forecasting is the wrong instinct

Five years ago, a data centre rack drawing 15 kilowatts was considered aggressive. Today, Nvidia’s latest systems point to 132 kilowatts per rack, nearly nine times as much, more than likely with liquid cooling rather than air. That’s not a trajectory anyone planned for. And there’s no reason to think the next five years will be any gentler.

The architect Stewart Brand once said that: “All buildings are predictions” But “All predictions are wrong.” The question for data centre developers is what to do with that insight.

The frontier of technology is fast evolving. In reality, with electricity costs high by European standards, most UK data centres won’t be frontier facilities. But the frontier still matters because it resets expectations about what a consented, energised site could host over its life. A facility with hard-coded assumptions about power density or cooling topology may find its market position eroding – not because it failed, but because the definition of “good” moved.

The government’s AI Infrastructure Compute Roadmap frames national AI infrastructure as needing to be “dynamic and adaptable”. It’s the same point but in government prose.

How do you optimise for a moving target?

The data centre industry has spent a decade learning to optimise: power distribution shaped around specific densities, cooling systems engineered for the thermal profiles of hardware that was current when the design was signed off. Optimisation makes sense when the target is stable. When it isn’t, optimisation becomes a constraint. Operators are retrofitting liquid cooling into spaces never designed for it, carving out space for coolant distribution units, discovering that structural loading assumptions don’t hold when racks weigh far more than anyone expected.

Platform thinking – turned inside out

Learning from other sectors, the Platform Rulebook references the need to consider how quickly uses and requirements move – to consider a “planning horizon.” This requires a distinction between “deep infrastructure” and “surface configuration.”

• Deep infrastructure is anything whose change triggers re-permitting, utility renegotiation, or revenue-impacting shutdown – high-coupling, long-lead, outage-bound decisions: grid connection and power architecture, structural capacity, spatial reserves, risers and distribution corridors, logistics and maintenance access.
• Surface configuration is everything designed to be reconfigurable within those bounds: hall layouts, rack topology, in-hall cooling distribution, monitoring and controls, the kit that generates and moves heat.

The mistake is treating surface as deep: locking in today’s cooling technology as “the answer” for decades. The opposite mistake is treating deep as surface, under-investing in power, space, and the structure on the assumption you can upgrade later, when “later” means outages, consent risk, and commercial pain..

The boundary between the two can move. Liquid cooling used to be optional – a specialist choice. It’s quickly becoming deep infrastructure, not because liquid is inevitable everywhere, but because the capability to switch between cooling strategies now shapes everything from utility connections to structural design. Facilities increasingly need to anticipate heavier equipment, different power architectures, and service corridors sized for rapid equipment swaps. These decisions ripple outward into electrical systems and transformer capacity.

Future-proofing may look less like betting on one horse and more like building the gate so you can switch horses mid-race.

The chassis is the asset

Huang’s line about the chassis isn’t just a quip. It’s a design principle.

Nvidia has decided that the chassis stays stable across generations. Everything inside transforms annually. Their entire product strategy depends on that separation: customers can swap in new hardware without rebuilding their facilities

Their latest Rubin design makes this explicit with modular, cable-free trays engineered for rapid replacement. They’re not just accepting hardware churn. They’re engineering for it. This is platform thinking applied at chip-to-building scale.

What this means for data centre developers

The architect Cedric Price argued that a building should be a tool, not a monument. For data centres, that means designing the building to serve whatever technology comes next. Design a power system for a specific rack density, and you’ve baked in an constraint. Design cooling that only works within a narrow range, and you’ve baked in a constraint. Design a structure that can’t take heavier equipment, and you’ve baked in a constraint.

Every constraint is a bet on the future. And bets have a habit of being called at the worst possible moment – often just as the market reprices what “good” looks like.

Real options, not overdesign

In the UK, the longest lead-time constraints are usually grid capacity and planning consent, not the capital plant. The scarce asset isn’t steel and switchgear. It’s permitted, energised capacity.

With that as the fixed point, flexibility can be introduced elsewhere:

• Oversizing risers and service corridors before you oversize chillers—chillers can be replaced, risers require structural intervention.
• Reserving plantroom white space before you buy plant—equipment churns, space doesn’t.
• Standardising interfacess before you choose equipment—the interface determines whether changes are routine upgrades or stranded assets.
• Building isolation boundaries before you build redundancy—the ability to upgrade one hall without affecting others is worth more than another layer of backup.
• Designing operations for continuous retrofit from day one.

The value of a data centre lies partly in what it could host, not just what it does host. Excess capacity looks like overdesign until the moment you need it.

So what are you designing?

In 1858, Joseph Bazalgette began building London’s sewers. His colleagues wanted to build for current requirements. Bazalgette calculated the need and doubled it. When challenged on cost, he reportedly said: “We’re only going to do this once.” The sewers are still in use – not because he predicted 2026 correctly, but because he designed for transformation rather than a single future state.

You can optimise for today, or you can design for transformation. For those tasked with the latter, the challenge is drawing the line between permanence and possibility.