There are two complaints you commonly hear in the supply chain of spares in many industries, but rarely are both uttered in the same breath. The first is that there’s too much stock. Warehouses full of parts bought years ago to hedge against a forecast that never came true – and it’s probably now slowly depreciating, and some of it even ages out before it’s ever fitted. The second is that there’s never the right stock. In aviation, that commonly means that an aircraft sits grounded waiting for one part that isn’t available in any close proximity…and subsequently, burning tens of thousands of pounds an hour while it waits.

They’re actually the same problem wearing two coats. Both come from the same habit: forecasting slow, intermittent demand off long-run historical averages, then covering the uncertainty with a big static buffer and hoping it’s sitting in the right place. You end up holding too much of the wrong thing and too little of the right thing, but ironically paying for both at once. I recently wrote about the warehousing half of this in [Just in Case], where the redundancy cushion has quietly become one of the biggest tenants in the industrial property market. This is the other half.

I’ve long been a fan of stealing the successes of other industries to help solve issues in another, and this can be one of those examples; there’s an industry that solved the responsiveness problem so thoroughly it became notorious for it, and it’s one aerospace would never normally look at:

Fast fashion.

The likes of Zara and Shein are an environmental embarrassment; but strip the disposability away and what’s left is a genuinely brilliant machine for matching supply to demand you can’t predict; and that’s a model worth borrowing.

This article is about how their model actually works.; which bits of it survive contact with a certified aircraft part and which absolutely don’t, and a small piece of maths that puts a number on the prize.

What the rag trade worked out

Most people picture fast fashion as cheap clothes made fast. The interesting part is how the supply chain decides what to make.

Start with demand sensing. Instead of forecasting a whole season from last year’s sales and committing months ahead, Zara reads what’s selling right now, store by store, day by day, and feeds that straight back to production. Shein takes it further, watching search trends, social signals and in-app behaviour to spot a rising shape or colour before it’s really arrived. The principle is simple: forecast from signals of what’s about to happen, not averages of what already did.

Then there’s postponement, which is the practice of staying deliberately undecided. You build generic, half-finished stock and commit to its final form as late as you possibly can, once you know what’s actually wanted. Zara holds undyed fabric and colours it late, so there’s less guessing.

Add small in-season batches. Zara launches a style in runs sometimes under a thousand, watches the sell-through, then reorders only the winners, restocking stores twice a week. Shein tests with as few as a hundred units and scales only what moves. And they position stock close to where it’ll actually be bought. They pay a bit more per unit and accept it, because the saving comes from almost never being badly wrong about what’s needed, or where.

So in the broadest possible principles aircraft supply chain should aim to mimic:

• Sense fast

• Commit late

• Position close

From that 30,000 ft view, none of that logic is really specific to clothes.

Some of it doesn’t fly

I’m just a bloke thinking about stuff, and I’m not closely wedded to the intricacies of this industry – so I’m sure a maintenance planner would spot a lazy analogy instantly, and they’d be right to. The broad theory translates, but there’s reasons if works flawlessly in fashion context, but there may be a few creases to iron out before being adopted by aviation.

Fashion demand is high-volume and forgiving. A missed t-shirt sale costs a markdown. Miss a spare and you might ground an aircraft or, far worse, you’re into safety-critical territory where the cost isn’t a markdown at all. Spares demand is also a different statistical animal: low-volume and lumpy, long stretches of nothing punctuated by the odd spike. Realiostically, that can’t be smoothed with the methods a fashion retailer uses. Also, none of it escapes regulation, traceability and certification, which fashion simply doesn’t carry in the same way that parts for aircraft does; but, software, barcoding and inventory management could develop alongside this to make this more or a practical reality./.

[FIGURE 3 here: mapping table, “What packs, and what gets left at the gate”]

As I see it, the principles seem to split into three piles:

1. Demand sensing ports over relatively cleanly: swap store sell-through for part removals, condition data and how hard the fleet’s being flown.

2. Distributed positioning ports across quite well too, with solid maths behind pooling stock rather than scattering it. Paying more per part to dodge a grounded jet is a trade aerospace already understands.

3. Admittedly, the Postponement only half-travels across: you can hold a common module and finalise its configuration late, but only where the part and its certification allow it. Small test batches mostly don’t, because certification costs and supplier minimums fight you. And the disposability doesn’t travel at all, which is rather the point.

There’s an irony staring at us as far as I can see it - the maintenance world already adopts fast fashion’s worst feature. Industry estimates put the share of spares that expire unused at something like a fifth to a third of them. So it’s a waste bill that’s already being paid, although the responsiveness it’s supposed to buy isn’t being collected.

The buffer you can throw away

A number can be attributed to assist in this, and it’s built on textbook inventory maths, not anything I’ve invented. The safety stock you hold to hit a service target is roughly the service factor, multiplied by how variable demand is, multiplied by the square root of the lead time. In plain terms, your buffer grows with two things: how wrong your forecast tends to be, and how long you wait for resupply.

Responsiveness attacks both, separately. Sense demand better and you shrink the forecast error. Resupply faster and you shrink the lead time. Because the two multiply together, the gains compound.

If we take a basic aircraft part – something like a valve - say it turns over about two a month, lumpily, with a demand spread of three units. Lead time from the manufacturer is six months, and you want to cover ninety-five times out of a hundred. The textbook buffer for that works out at roughly twelve units, sitting on top of the dozen already in the pipeline. Two dozen units of a part that moves twice a month. That’s the dead-capital story in one part number. The below graph should help to illustrate that.

To improve responsiveness, we should consider feeding in condition-monitoring data so the forecast error roughly halves, and the buffer falls to about six. Separately, pre-position stock or stand-up regional repair (so resupply drops from six months to six weeks), and simultaneously the buffer falls to about six again, this time with far less in the pipeline too. Do both and you’re near three units, for the same ninety-five percent cover. Mathetmatically, this leads to suggest to about quarter of the buffer, with the same identical protection.

I will expressly state that this is a very linear model, and as such, can’t ever really be deemed as immediately and universally accurate in realistic context. With demand which is typically very lumpy for aircraft parts, the tidy bell-curve formula is only a rough guide; and a proper model would model the lumps directly. For genuinely intermittent parts you’d reach for something like Croston’s method, which forecasts the size of demand and the gap between demands separately, so all those zero months don’t drag the estimate to mush. The exact figures shift when you do it properly. The shape of the result doesn’t: compress forecast error and lead time, and the buffer collapses while the service level holds.

Sorting the wardrobe

The catch is that not every part can move along that curve, so you have to sort them first.

Two questions do the sorting:

• How lumpy is the demand; and

• Can the part be made responsive at all, meaning can you sense its demand early, resupply it quickly, and is it free of certification locks.

Cross those and you get four homes:

1. Steady demand you can sense gets responsive replenishment, the fast-fashion zone: thin buffer, sense and react.

2. Lumpy but responsive gets the same reflex with a slightly deeper cushion for the spikes.

3. Predictable but hard to move runs happily on a classic reorder point.

4. And the lumpy, hard-to-move, often safety-critical parts get a deep buffer or, better, a shared pool.

That last pile is where positioning earns its keep. Pool the same slow mover across several operators instead of everyone holding their own, and the arithmetic of pooling means the combined buffer shrinks roughly with the square root of how many holdings you’ve merged. Four separate stashes pooled into one need about half the total safety stock for the same cover. For the parts that can’t be made responsive, that’s the lever that’s left.

Keep it honest

Nearly sounds too good to be true, doesn’t it? So let me be clear about the line you can’t cross, and probably is the large part why this model hasn’t been fast-tracked into the supply chain before.

You cannot fast-fashion a safety-critical certified part (for regulatory reasons predominantly, but there’s practical merit to the approach aswell, of course). Postponement stops where certification of a configuration begins.

Traceability is non-negotiable, sole-source lead times are real and often immovable, and “sense and react” is never a licence to thin the buffer on the part whose failure is catastrophic.

So the lesson, or the thing to borrow is the responsiveness philosophy, applied carefully, on the parts that can take it - sensing earlier, committing later, and aiming to position smarter.

Position stock closer; sense demand sooner; commit later where the part lets you; and pool the rest in the open.

TH

Find me on Linkedin

Share

Factories and warehouses are filling up with robots very quickly; but the improvements to the systems meant to keep them out of each other’s way are not matching that growth rate. It usually ends up as a mixture of fixed-path vehicles that follow tape or floor markers, free-roaming robots that build their own maps and reroute as they go, or collaborative arms (often, ironically, working an arm’s length) amongst humans. They all share the same concrete; and even legacy models are regarded as good news for general safety and efficient. However, the traffic management around them mostly isn’t.

What passes for traffic control on most floors today is primitive:

• A robotic vehicle follows a fixed route.

• It reserves a zone and makes everyone else wait until it’s done with it, or;

• Tt stops dead the instant a sensor sees something in its path.

Each of those rules is sensible on its own, and each is safe. But ratchet up the fleet density, and you end up with robotic vehicles attempting to work on top of each other. The outcome of that are production floors that deadlock, that freeze on a single obstruction, and whose throughput falls once you add enough robots. Past a certain density you get less work out of more machines, which is the opposite thesis of why anyone bought them.

The awkward part is that this is already a solved problem, just not by manufacturing engineers and warehousing consultants.

Air traffic control has spent the best part of a century moving traffic that’s faster, higher-stakes, and in places denser than anything on a warehouse floor, and it almost never loses an aircraft. It does that with a layered approach most robot floors have never thought to borrow, including the ones that like to describe themselves in air-traffic terms.

First come, first freeze

To illustrate my point, we need to take the mechanism apart. The floor gets carved into a graph of zones, and before a robot enters a zone it reserves it (akin to booking a meeting room), so everyone else waits until it’s free. It’s safe, it’s easy to reason about, but it throttles throughput the moment density climbs.

To keep this concrete I’ll use one example throughout, the kind of pinch point every floor has: a crossing where a pick aisle, a charging bay and a packing line all feed into a single intersection. Call it ‘Junction 12’. When one robot stops there, say for a person stepping across, the robot behind it reaches its own stopping distance and halts, the one behind that is already holding the next zone, and the approach backs up. Two robots that each want a zone the other is holding deadlock outright, the warehouse version of a circular wait, and neither moves until something external breaks the tie.

The deeper issue is that throughput doesn’t rise smoothly with fleet size. It rises, peaks, and then falls off once it reaches a point of critical density. Add robots past that sweet spot and they spend more time waiting on each other than working.

In the worst case the floor tips into a congested state where almost nothing moves. It’s a property of dense agents sharing space under simple local rules, and it’s been measured repeatedly. A well-known result that a robot navigating a crowd will freeze in place once the crowd gets dense enough.It still freezes even with perfect sensing, because the fix was never better perception; the fix is modelling the fact that the other agents will cooperate. But stop-on-detection has no concept of cooperation. It just has one rule, and it applies it to everything.

I‘ll address the obvious counter-argument early, because there’s probably some engineers that have already started yelling it at their screen – I’m aware that plenty of the industry already calls the fleet manager an “air traffic controller”. Omron markets it in exactly those words. Ocado describes the brain coordinating its grid as an air-traffic control system talking to a thousand bots ten times a second. Amazon pitches its newest layer as an intelligent traffic system.

My argument is that the industry appears to have copied the wrong half of air traffic control; but to clarify which half, that is, we should probably quickly run through how the tower systems actually work.

What the tower actually does

Most people would consider air traffic control as collision avoidance, as we see in films - a controller watching blips on a screen, and telling two of them to turn before they touch. It’s true that’s part of it, but it’s nowhere near the most important part.

The overarching concept in air traffic control towers is that of separation minima; which is the formal term for the minimum gap that must sit between two aircraft. The thing worth stealing as a transferable concept, is that it’s never one number. Aircraft are kept apart vertically, usually a thousand feet between cruising levels. They’re kept apart along their track (roughly three nautical miles near a busy airport and five miles further out); critically, the size of the gap changes with how well the controller actually knows where everyone is. When a controller has live radar, the in-trail gaps can be kept quite tight. But when they don’t, working a stretch of ocean purely off position reports and timing estimates, and that gap blows out to ten minutes or tens of miles. It is the same aircraft, in the same sky, but with a a far bigger buffer - purely because the position is inferred rather than seen. That distinction between procedural separation (you’re estimating where the traffic is) and surveillance separation (you can see it) is the single most useful idea in this whole article, so remember it, as we’ll be building on it later.

On top of separation sits flow management. The tower doesn’t just resolve conflicts where they happen. It meters traffic upstream so the conflict never forms, holding aircraft on the ground or slowing them hundreds of miles out so they arrive at the busy sector already spaced. The doctrine is explicit that delay should be absorbed early and far away, not by stacking aircraft over the airport hoping it clears.

Finally, there’s conflict resolution, which is proactive by design. A controller’s hardest job is spotting a converging pair minutes before it’s a problem and changing one aircraft’s heading, height or speed while there’s still room to do it gently. Automated tools back this up, flagging a looming loss of separation a couple of minutes out and a possible one up to twenty minutes ahead. This whole posturing is intended to make the system preventative and not reactionary.

And underneath all of it sits the last line. Every airliner carries an onboard collision-avoidance system (usually called TCAS) that works independently of the ground entirely. If two aircraft get dangerously close, their boxes talk directly to each other, agree who climbs and who descends, and order the crews to do it. Pilots are required to obey that instruction even when it contradicts the controller.

There’s some sobering examples of why that system and such rules exist, and the importance of it. Over Überlingen in 2002, two aircraft received those automated instructions, but one crew followed the controller’s contrary order instead. 71 people tragically died. So now the rule now is absolute. The automated last resort wins, because it keeps working when the layer above it is wrong.

That stack of independent layers has a name: defence in depth, or the Swiss cheese model, from James Reason back in 1990. Picture each safety layer as a slice of cheese with holes in it. Any one layer can fail, but an accident only gets through when the holes in every slice happen to line up at once. The genius isn’t any single barrier. It’s that no single failure reaches all the way through.

The half they copied, and the half they didn’t

So why that’s important: When the robotics world borrowed from aviation, it only took the optimizer, but left the institution.

The optimiser is the clever bit: a central brain with a god’s-eye view, computing efficient, deconflicted routes for the whole fleet. That part has been copied brilliantly. Amazon’s and Ocado’s systems are genuinely impressive pieces of coordination.

The institution is everything else. It’s the layered separation that flexes with how well you know where things are; the upstream metering; the proactive conflict resolution; the independent last resort that survives the central brain being wrong. And it’s talso the defence-in-depth philosophy tying them together.

This is the half which seems to have been omitted, and the gap is apparent in the standards. The dominant interface standard that lets different robot brands talk to one fleet manager, VDA 5050, explicitly puts traffic management, routing, congestion and deadlock resolution out of scope and leaves them to each vendor. There’s a standard pipe for commanding the robots and no standard at all for the hard part. Aviation would never accept that, as safety is the priority over efficiency - the hard part is the whole point, and should take precedence over everything else.

A floor that borrows the right half

So what does a floor look like if it borrows the institution instead of just the brain? We can revert back to Junction 12 examp[le to illustrate the point.

We can start by killing the single rule, and exchange one fixed number for a term which represents the space a robot needs, defined by cumulative sum of it’s component attributes which contribute to how it defines that space requirement.

That’s the sensing and localisation error, plus the distance covered while the robot decides what to do, plus its braking distance, plus how unsure it is about where the other party is, plus a designed safety margin.

The safety standards for mobile robots already compute something like this; but the piece that does the real work is , and it’s exactly the procedural-versus-surveillance idea from aviation. Two robots that both broadcast their position and intent can run a tight, “surveillance-grade” gap. A robot facing something that doesn’t communicate has to fall back to a wide, “procedural-grade” gap, because it’s guessing. One floor, two traffic classes, two separation regimes, and not one rule applied to everyone.

The part which shows why the single rule is so expensive and, neatly, where this whole analogy breaks is apparent though: On a floor, the space a robot sterilises around itself is an area, and area grows with the square of the radius. Pack robots that each need a clear radius S into a floor and the handling capacity scales roughly as:

Run one rule and you’re forced to set S to the worst case everywhere, the wide human-grade gap, even for two robots that could safely run close. Layer it, and robot-to-robot encounters drop to the tight gap. The ratio between the two regimes is the thing to remember:

In this theory, the penalty is squared. If the human-grade gap is three times the cooperative one, a single rule isn’t costing you a third of your throughput. It’s costing you roughly nine times the robot density at equal safety. (I’d probably treat that as a first-order packing argument rather than a control-theory proof, but the shape of it appears to hold true.)

The rest of the logic follows the tower systems:

• Meter robots upstream of Junction 12 so the crossing never saturates, the way aircraft are held before a busy sector, instead of letting four arrive at once and fight.

• Resolve conflicts by prediction, rerouting one robot down a parallel aisle before the crossing locks, rather than first-come-first-freeze.

• Build it in independent layers, so when the central brain hiccups or a robot drops off the network, planned separation still holds and the onboard stop still fires. The lesson of Überlingen, ported to a warehouse, is that the local safety stop has to keep working when the fleet manager is wrong. One dropped connection should never be able to reach through every layer at once.

Where the sky stops helping

I should caveat by stating that this can’t simplistically be lifted wholesale (I’d be lying if I pretended otherwise).

A factory floor is not airspace, and the differences are not just cosmetic. Aircraft are sparse in three dimensions and separate vertically; but your robots are more likely packed into two and can’t. That’s not a footnote, it’s the squared penalty above, the reason a margin that costs aviation a little costs most manufacturing operations a lot. Aircraft are cooperative, equipped, tracked and predictable. Controllers almost never deal with uncooperative traffic. Your floor likely has humans walking through it on their own schedule, equipped with nothing, and that’s where the deepest break is in this theory. The tower has room to breathe, the go-around, the holding stack, and the option to delay a problem in spare airspace. A packed aisle in a manufacturing facility usually has none of that slack. In essence, there’s nowhere to send the problem.

The parts of aviation that transfer are the parts that don’t depend on cooperation: layered separation, and defence in depth. The part that doesn’t transfer is the comfortable assumption that everyone in the system is equipped and behaving. So you need to design the human in as the worst case, not the exception. They’ll always get the widest envelope, permanently. They’re never assumed to communicate, signal or move predictably, because they won’t. And the densest, fastest, tightest-separation robot traffic gets physically kept out of the spaces where people roam, because the one thing a century of air traffic control can’t teach you is how to separate from something that doesn’t know the rules exist and never agreed to follow them.

So we can borrow the philosophy, the layering, the metering, the independent last resort, and the refusal to let one failure cascade.

But we can’t just borrow the numbers, as the most dangerous thing on your floor is the one agent the tower almost never has to deal with: a human, on foot, who has no idea they just froze Junction 12.

TH

Share

Find me on Linkedin

You may find these of interest:

We’ve all been in a presentation where someone ludicrously intelligent manages to lose the room’s attention in under a minute. It’s very common amongst academics and professional thinkers.

We all see it as soon as the slide pops up onto the screen – and usually, it’s a chart or a diagram with far too much information on it. Usually, by any technical metrics, it’s probably perfect; every component is there; every interface; every link; every redundant path; every label, all depicted with the same care and attention.

But the room stays silent - not because anyone was impressed, but because noone could find the thing they were referencing or talking about. If we’re lucky, someone else in the room may eventually pluck up the courage to question it and seek a bit more clarity from the presenter; four minutes later, a single piece of data is extracted out of the explosion of information on the slide, and everyone carries on. It’s a perfect example how something can be ‘complete’ or ‘finished’, yet also useless in achieving it’s purpose.

The remarkable thing about this common scenario – often seen in management meetings where the technical staff are attempting to explain findings to C-suite - the failure is rarely a lack of skill. It was actually the opposite - too much of the wrong kind of skill.

We’ve actually had a solution on this type of communication, and it was figured out a long time ago – not by engineers, but by mapmakers.

The man who deleted geography

In 1931, a 29-year-old engineering draughtsman called Harry Beck sat down in his spare time and redrew the London Underground map. London Transport had a perfectly accurate map at the time. It showed the lines where they actually ran, over a real street geography, true to distance and position. It was also a tangled mess, especially in the centre where the stations bunch up, and passengers found it confusing.

Beck threw the geography away. He straightened every line into verticals, horizontals and 45-degree diagonals. He blew up the cramped central zone so you could read it, and he squashed the sprawling suburbs so they’d fit. He kept exactly one piece of real-world geography as an anchor, the River Thames, and threw out the rest. His own explanation was blunt: “If you’re going underground, why do you need to bother about geography? Connections are the thing.”

London Transport initially rejected it for being too radical, but then reluctantly trialled 500 copies in 1933. They printed 850,000 in the first two months. It’s now one of the most recognised pieces of information design on the planet, and it works precisely because of everything Beck refused to draw.

Every map is picking a fight

There’s something which engineers and other technical folk innately tend to resist: a map is never reality. It’s just an argument about what matters, but disguised as a neutral picture.

There’s a useful pair of words for this:

• A topographic map is true to the ground: real positions, real distances, real scale.

• A topological map is true to the connections: what joins to what, in what order, regardless of where things physically sit.

Beck’s diagram is topologically honest and topographically a lie, and that’s the whole point. He sacrificed where things are to make crystal clear how they connect, because connection is the only thing a passenger underground actually needs.

Strangely enough, nearly every map does a version of this deal – even the ones we think of being very ‘accurate’. The Mercator projection you you’ll have seen since school, takes a round Earth and flattens it so that compass bearings come out as straight lines, which is exactly what a 16th-century sailor needed to plot a course. But the price it pays is area; in some iterations, Greenland can end up looking the size of Africa, when about fourteen Greenlands would fit inside it. But it’s the bargain the map struck to do its one job. Mark Monmonier wrote a whole book called How to Lie with Maps, and the lie isn’t the scandal - the lie is actually the craft.

Engineers usually do the opposite of this on instinct. We treat distortion as failure and completeness as virtue, so we cram everything in and call it accuracy. What we actually produce is the tangled 1931 map. All technically there and complete, but still totally unreadable.

The grown-up word for lying

Cartographers (the professional description for people who draw maps) have a formal name for drawing things wrong on purpose. They call it generalisation, and it’s a real discipline with named techniques, not a vague instinct to tidy up. Five of them map almost directly onto what you do at a whiteboard.

None of this is new to the people who think about charts. Jacques Bertin laid out the visual variables you’ve got to play with back in 1967, position, size, shape, colour, value, orientation, texture; Edward Tufte gave us the data-ink ratio. What the mapmakers added was a proper vocabulary for deliberate deformation. Tufte’s technique mostly wants you to remove clutter. Cartographers will happily bend the truth of where something is, and they’ve got techniques and standards for doing it honestly.

Same system, two maps

So by way of an example: here’s the same plant control architecture drawn twice. Sensors, edge gateways, network, controllers, analytics, operators.

This first version is the one that I talk about in the introduction - the one that appears on the slideshow and loses the room’s attention. You can see every sensor drawn individually, every redundant link, protocol tags, IP addresses, switch model numbers, all lines equal, sprawling across the page in a layout that vaguely follows where the kit physically sits. Complete. Dead.

The second version applies the five moves. The sensors are classified into typified blocks. The flow runs cleanly left to right similar to Beck’s straight lines. The critical path and the one real bottleneck are exaggerated so your eye lands on them first. The IP addresses and switch models are selected straight off the page. The only way to improve this would be a note the corner saying what this drawing is for and what it deliberately leaves out.

In both examples, it’s the same system - but you can only really think clearly with one of them.

Declare your projection

That note that I should have put in the corner is not insignificant, and it’s actually the difference between a useful lie and a dangerous one.

Every serious map states its scale, its projection and its date. That declaration is what makes the distortion honest, because it tells you the rules for reading it and, by implication, what not to use it for. Nobody walks into the River Thames because the Tube map drew the embankment wrong, because nobody thinks the Tube map is to scale. But where the Tube map does mislead people is the bit it doesn’t declare; for instance, Leicester Square to Covent Garden looks like a journey. In reality, it’s one stop on the Piccadilly line, and about 250 metres on foot. People ride it every day because the map’s silence about distance lets them. The distortion that makes the network legible but obfuscates from the fact that the walk is arguably faster than going through the barriers, down the escalators, waiting for the train, and then back up following your less-than-a-minute journey.

That’s the crux of this - a good, simplified diagram tells you it’s simplified, but a bad one pretends to be complete. The solution is almost insultingly simple: write on the drawing what kind of map it is and what you took out. Modern iterations of Tube maps now put a little note next to Leicester Square informing that it’s just a 10 minute walk to Covent Graden.

Where the distortion kills

There’s a bit of nuance that need to apply to this argument though. Distortion is a skill when the job is to help someone understand, and what you cut isn’t needed for the decision they’ll make. It becomes negligence when the job is to help someone act, build it, operate it, certify it, respond to a fault, and you cut something they needed to act safely. A nautical chart and a road atlas of the same coast are both heavily distorted, and neither is more accurate in the abstract. Attemptiong to navigate the rocks with the road atlas and you’ll find you’re on them.

So the two worlds need to be kept apart:

• The released fabrication drawing, the P&ID of record, the FMEA, the certified schematic, those are your survey maps. They live under ASME, ISA and IEC standards, under revision control and sign-off, exactly because people build and certify from them and a dropped tolerance there can kill. You do not generalise those.

• Everything in this article belongs to the other layer, the diagrams you draw to explain: the review slide, the architecture overview, the onboarding sketch, the briefing for the stakeholder who needs the shape of the system and not the means to fabricate it.

Get that distinction wrong in one specific way and there is a scenario where it could be lethal, but I do think that’s quite a rare occurrence, and most humans are aware of the distinction. The sin isn’t simplifying; it’s letting a drawing made to explain get mistaken for the record people act on, with no note on it to say which one it is. A good map always tells you what kind of map it is, and thhe bad ones let you assume they’re the whole truth.

Harry Beck knew his map was a lie, and that’s why it’s one of the most useful drawings ever made. His skill worth borrowing isn’t necessarily drawing less accurately; it’s knowing exactly which map you’re making, and adjusting it for your purpose – but just ensure you never let anyone confuse it for the other type.

TH

Share

Find Me on Linkedin

You may find these of interest:

By those standards, SpaceX’s/Elon’s offering under xAI looks like a minnow swimming with whales. Microsoft, Amazon, Google and Meta are currently each pouring tens of billions into capacity. xAI is the newcomer with the edgy chatbot that appears on X for a bit of context testing (or Twitter, for millennials and older – we all still call it Twitter, don’t worry). Grok is seen as a novelty - a side project which is easy to file under “small AI lab” and move on.

I think that’s a huge mistake though. I completely understand why it appears like this at the moment, but if anything about SpaceX’s record IPO has taught us, there’s as much belief into Elon’s capability as there ever has been.

The reason xAI gets underestimated is that it isn’t really chasing the same prize as everyone else. It’s not optimising Grok for mass-market consumer release the way OpenAI is with ChatGPT. Similarly, they’re not positioning for enterprise like Anthropic are doing with Claude. Their market destination is ‘embodied’ AI, such as the the brain for Tesla’s Optimus robot – and frankly, it’s a market that simply isn’t here yet (or not at any significant scale yet).

The attention stays elsewhere, on the companies shipping products you can poke at today. Meanwhile the infrastructure underneath xAI is being built by a man who treats “impossible on that timeline” as a personal challenge. Forget the newly advertised ‘trillionaire’ net worth for a second too, because ironically the valuation is a distraction. Roughly as much money has been collectively or cumulatively shovelled into data centre construction by his rivals anyway – so his advantage isn’t monetary.

What Elon has that the others don’t is a set of ludicrously unfair advantages no other operator has any real experience wielding.

Power to the people who build their own

Start with the one constraint that decides everything in this industry: electricity. I’ve written before that the grid is the actual bottleneck, not the tech, not the money,, nor the planning. It’s that all of the other operators are stuck in the same queue. Connection waits stretch for years, and when developers need turbines they’re lining up behind each other for GE Vernova or Kawasaki, usually hiring the same handful of consultants to tell them what they already know.

Elon doesn’t queue. When the grid couldn’t feed his Memphis Colossus site fast enough, xAI wheeled in a fleet of methane gas turbines, somewhere around thirty-five of them, and simply ran the thing anyway while the permits caught up. He’s run factories off generators before. He’s built the Raptor engine. Rocket science is the family business, so the idea that building a steam turbine to make his own electricity would faze him is laughable. Where everyone else sees a power problem that needs outside help, he sees an engineering task he’s already solved in a harder domain.

This is the bit that should genuinely worry the incumbents. To be fair, Amazon has comparable muscle here, on paper at least. It has the capital, the logistics and some similar engineering knowledge through Blue Origin. What it doesn’t have is quite the same level of risk appetite, or the speed at refining manufacturing efficiencies. The same tools, but completely different temperament.

Bigger, and half-empty on purpose

The second unfair advantage is Elon’s affinity for scale. Look at the Tesla Gigafactory as an example; hyperscale isn’t a stretch goal for Elon, it actually seems to be his default setting. Doing it bigger than anyone else isn’t a challenge he has to rise to, it’s probably the way he always intended to do it in the first place when he ideated it. Colossus has already grown from a standing start to hundreds of thousands of GPUs, with a million openly being talked about as the target – it wouldn’t surprise me if Elon asks that timeline to be moved up to urgently either.

It’s going to take a bit more insider knowledge, but patternising Elon’s behaviour would suggest there’s likely another avenue which will double his capacity over his competitors for the same cost per square foot.

If you’ve not read ‘The Book of Elon’ by Eric Jorgenson, I’d recommend it (he’s also being doing podcast as part of the promotion for it too, so I’d recommend checking some of those out aswsell). A key finding in that is how Elon is willing to push efficiency and design to it’s limits, and he hates too much redundancy built into things – he sees it wasteful, inefficient and unnecessary if something if well designed and durable in the first place.

Most operators of data centers build everything and run it at half capacity – keeping the other half as a redundancy backup.

But I’d bet good money that xAI’s data centres will likely eventually (or may even currently) run with barely any redundancy. Everyone else builds in duplicate, two of everything, because their reputation lives or dies on uptime guarantees to enterprise customers. xAI mostly answers to itself. If a node drops mid-training, it’s just an annoyance, not a breached SLA. Strip out the spare capacity everyone else is contractually forced to carry, and for every square metre of building you’ve effectively got double the usable compute. I can’t prove the redundancy figures from the outside, so treat that as my inference rather than reported fact, but it’s exactly the kind of efficiency he chases everywhere else - cutting the part that isn’t earning its keep.

The warm-up act

All of that is impressive, and if he hyperscales with a power generation solution with minimum redundancy, he’ll already by running at factorial levels of efficiency that other operators could achieve. But potentially, it’s just the warm-up act.

The headline act is space. SpaceX has now merged with xAI and filed with the regulator for permission to launch a constellation that could eventually run to a million compute satellites, with the first AI satellite design already shown off publicly. The pitch is simple enough: in orbit the sun never sets, so the power is free and constant, and you’re not fighting any community over land, water or grid capacity. The engineering is brutal, cooling in a vacuum is a genuine nightmare, and plenty of serious people think parity with ground-based sites is a decade away rather than two or three years. I’m not claiming the timeline is right – Elon’s timelines have been awry more than once – sometimes for better, but more often not.

SpaceX already runs the world’s busiest rocket launch cadence; bolting a bit of data center deployment into that (in a modularized, proven and repeatable format), and the best thing all of the other data center operators could do is sell up and buy SpaceX shares. Once Elon cracks orbital deployment, every operator still pouring concrete on the ground is competing in a different and slower league. Attempting to fix data centers relationships with the grid if the slow route. Elon will potentially leave the grid behind entirely, and nothing on earth will be able to compete.

This isn’t actually theoretical at all, as he’s already done it with Starlink. The glacial pace that hard cabling telecommunications infrastructure upgrades can’t even begin to compete with the speed that Starlink can be rolled out.

The only one who could answer

If anyone is positioned to meet this, it’s Amazon, but at this stage it would seem that it’s not even close. AWS is also the operator with the most to lose, because its whole empire is terrestrial cloud. So Blue Origin filing its own orbital data centre plan, Project Sunrise, should be a no-brainer, and it is happening, but their trouble is the scale and the timing. Blue Origin filed weeks after SpaceX, for fewer than 52,000 satellites against a potential million. That’s a reaction, not a leading strategy.

Amazon has done this before. It speed-ran cloud computing while everyone else dithered and owned the category for fifteen years off the back of moving first. I think it needs to find that same nerve again (and bloody fast), because the window doesn’t stay open once xAI nails infrastructure deployment in orbit. SpaceX’s advantage would compound in the same way that all of Elon’s engineering does – standardized, repeated and iterated. The same playbook that took SpaceX from blowing up rockets to landing them on barges, and Tesla from niche curiosity to the one of the most valuable carmaker on the planet – all from complete blank slates also.

That’s why this is a one-shot. Whoever’s still building data centres the traditional way when that flywheel spins up doesn’t get a second chance to catch the front-runner. They just get lapped.

I’ll caveat all of this the way I caveat every piece oon AI infrastructure rollout - none of this is a problem if the market stays competitive and honest. A ferociously capable operator dragging the whole industry forward is a good thing, right up until it’s the only operator left and gets to set the price of every junction on the network. The healthiest outcome is xAI, Amazon and a handful of others genuinely racing each other into orbit. The worst is everyone waking up to the predator only after it’s already eaten.

In his defence, Elon has always been welcoming of competition, and genuinely seems to push his agenda in pursuit of creating a better humanity. He’s fine being one of a few operators in any space. But this is no longer at just the direction of Elon; there’s now a lot of shareholders to answer to – and they are not going to be as welcoming of anything which appears to compromise their investment.

So by all means keep watching Microsoft, Google, Meta, Oracle and Amazon. But don’t forget to watch xAI – or there’s a chance you may end up watching the wrong predator.

TH

Share

Find me on Linkedin

You may find these of interest:

Then 2020 happened, and the gospel flipped. A blocked canal, a chip drought, half-empty supermarket shelves, and suddenly the company holding three months of stock looked clever rather than careless. “Just-in-case” became the new orthodoxy almost overnight.

Most of the commentary on that shift has generally framed the cost only really as a financial one. Working capital tied up in inventory. Carrying costs that the Institute for Supply Management puts at somewhere between 20% and 30% of inventory value every single year.

In theory, that’s all true, and all worth worrying about. But the premise skips the more interesting bill, that nobody’s really itemising. Every extra week of just-in-case has to physically exist somewhere; it needs a roof, a floor, dock doors and a postcode.

The redundancy cushion has quietly become one of the largest new tenants in the industrial property market; but unlike the money tied up in stock, the space it occupies doesn’t politely unwind once the crisis passes.

Lean has become a lot less lean

The numbers behind this shift are not subtle. By 2023, days inventory outstanding across S&P 1500 companies had climbed to roughly 71.6 days, a five-year high. Manufacturers, in particular, have held those swollen inventory-to-sales ratios fairly steady ever since rather than letting them drift back down towards the old lean baseline. Then tariff uncertainty through 2025 had firms pulling orders forward to get ahead of the next price rise, piling yet more onto the heap.

None of this reads like a temporary blip waiting to correct itself; and it appears more like companies institutionalising the buffer as a modern management practice. They’ve deliberately decided that carrying more is the price of not getting caught out again; but once a business makes that decision, the stock has to go somewhere other than a spreadsheet.

The interesting part: the ratchet only turns one way

There’s a bit I think gets overlooked in a lot of the commentary. The Just-in-time system has a correction built into it. Every quarter, somebody’s job is pushing inventory down to free up cash, and prove they’d trimmed the fat. The whole philosophy pulled in one direction, towards less.

But the Just-in-case system has no such floor. The incentives run entirely the other way, and they’re asymmetric. Nobody in a boardroom gets sacked for a warehouse that’s a bit too full, but plenty would get sacked if a shelf was empty during the one week demand spiked. When a disruption hits, buffers go up fast; and when the disruption fades, they quietly stay up because no one wants to be the person who stripped out the safety net right before the next shock. The redundancy capacity cushion ratchets. It perpetually seems to climb in every crisis, and barely retreats between them.

That changes what kind of demand this is; resilience-driven warehousing isn’t a cycle that booms and busts with the economy. It’s a step change that keeps stepping - a structural re-rating of how much space the physical economy needs just to feel safe. I accept the lean evangelists will push back hard on that, and in normal times they’d have a point. But we don’t appear to be in normal times.

Redundancy doesn’t add…it multiplies

The space problem is worse than “everyone’s holding a bit more,” because real resilience isn’t one bigger pile in one bigger shed. Genuine resilience is duplication - it’s dual-sourcing the same component from two suppliers on two continents. It’s decoupling buffers between each stage of production so a stoppage at one doesn’t starve the next. It’s spreading stock across more regional nodes so a single closed port or flooded motorway doesn’t strand your entire inventory in the wrong place.

Every one of those moves multiplies the number of locations stock has to sit in. Decouple a chain at five points and you’re no longer holding one buffer, you’re holding five, each needing its own building, its own racking, its own dock doors and its own staff to run it. Total floor space grows faster than total inventory value, because resilience by design scatters the same goods across more sites rather than consolidating them. You’re not simply holding more stuff. You’re holding it in more places, and places are the expensive part.

Fast space and slow space

Not all of this inventory behaves the same way though, and that’s reshaping what kind of buildings get built and where. Throughput stock (the stuff turning over constantly to feed e-commerce and next-day delivery) wants to be close to the customer. Companies pay a fortune for last-mile real estate near cities because speed is the whole point.

Safety stock is the opposite animal; it mostly sits still, waiting for a bad day that may never arrive. Parking that dead weight in premium urban logistics space would be foolish. Therefore, it heads for cheap, tall, heavily automated buildings out where land costs a fraction of the price, somewhere the rent on doing nothing is bearable. The global industrial real estate market seems to be splitting into fast space and slow space; two genuinely different property products with different economics, different locations and different tenants.

This is a big part of why nearshoring corridors are booming. Mexico pulled in over $20bn of foreign direct investment in a single quarter recently, with the largest slice heading straight into manufacturing, and inventory markets like Monterrey have swelled to north of 200 million square feet of industrial space. Shorter, more resilient supply lines need somewhere to hold their buffers, and it’s better to put that expense where the concrete and the ground underneath it is a cheaper liability.

The cost with no line item

So why isn’t anyone properly pricing all this?

Simply put: there’s no row in the accounts called “resilience.”

The inventory itself shows up neatly on the balance sheet, a number a finance director can quote to two decimal places, but the space holding it does not. It’s operating expense is split - smeared across the cost of goods, buried inside a third-party logistics invoice, or hidden in a lease that looks like healthy growth on paper - but is really just insurance against the next disruption. A company can tell you precisely what its stock is worth and have almost no idea what its cushion costs in rent, because that cost isn’t ever gathered into one place to be costed properly.

The cost of a cushion is more than financial precisely because the financial bit is the only part anyone bothered to measure. The square footage, the energy to light and heat it, the people to run it, the opportunity cost of capital sunk into a building full of stuff that’s deliberately not moving, all of it lands as a vague, distributed drag that never gets named – and you can’t manage what you refuse to add up.

Building less, charging more

The supply side is what turns this from an interesting observation into a genuine squeeze. Warehouse construction peaked in 2022, with something like 2,784 facilities entering the building stock, and completions topping 330 million square feet at the height of the cycle in 2023. Then it fell off a cliff. New supply slumped to around 48 million square feet in the first half of 2025, and speculative developers seem to have largely abandoned distribution centres in favour of building data centres instead.

A structural step-up in resilience demand is therefore arriving just as the pipeline of new space thins out. Vacancy has stabilised somewhere around the high-six to mid-seven percent mark depending on whose methodology you trust, big-box leasing more than tripled year-on-year in early 2026, and pricing power is creeping quietly back towards landlords.

The winners are obvious enough: owners of modern, high-cube, automated space in cheap secondary markets, and the nearshoring hubs soaking up manufacturing that’s moving closer to home. The losers are less obvious and a lot more deserving of sympathy. They’re the lean disciples who proudly handed back their buffer space in 2023 to look efficient on a quarterly call, and now have to re-lease it into a tighter, dearer market at the worst possible moment. There’s a grim little irony in the efficiency crowd now being forced into paying an efficiency penalty.

The cushion you can measure

The cushion isn’t going anywhere this decade. Tariffs, geopolitics and the lingering memory of bare shelves seem to have cemented that for the foreseeable future. But leasing ever more space is the lazy response, and it’s the one that quietly bleeds a business while hiding in the cost of goods.

The same research showing buffers ballooning also shows firms running AI-driven demand sensing cutting their safety stock by somewhere between 30% and 50% for the same level of resilience. That’s the real opportunity, and it’s the one the next ten years will reward.

The companies that come out ahead won’t be the ones sitting on the most stock in the most buildings. They’ll be the ones who know, almost to the pallet, how little they can hold and still sleep at night. Resilience you can actually measure is resilience you can deliberately shrink. Everyone else is just paying rent on their own anxiety, and calling it strategy.

TH

Share

Find me on Linkedin

You may find these of interest:

There’s a second grid that almost nobody talks about in those terms. It’s made of concrete, cranes and seawater, and it carries the physical economy the way the electricity grid carries the digital one. We call its junctions “ports”. And like the power grid, it’s over-concentrated, under-invested, and quietly setting the price of nearly everything you own.

Here’s the part that should bother you more than it does. That grid sits at the water’s edge, which is precisely where the weather is getting worse.

An invisible grid where you can’t see the pylons

Over 80% of world trade by volume moves by sea. In 2024 that was around 12.1 billion tonnes of stuff loaded onto ships [UNCTAD Review of Maritime Transport 2024]. IN realistic terms, that is not a slim majority, it’s pretty much all of it. Everything in your kitchen, your car, the components inside the phone or computer you’re reading this on, all of it spent part of its life on a boat.

But they didn’t pass through a thousand evenly-spread harbours; it funnelled through a relatively small number of mega-ports and a handful of canals and straits that the whole system leans on. You’ve experienced some of the repercussions of this setup already in recent times - remember when the Suez canal got blocked in 2021? Or when prices shot up due to the Russia/Ukraine conflict? And we’re all only just seeing the tide turn on fuel prices now the Strait of Hormuz has reopened following the peace deal between Iran and the USA.

This is the elephant on the quay - we’ve built a global economy that depends on a few dozen enormous, fixed, coastal ports and passages, and then we’ve assumed they’ll always be open, and always be accessible.

This is the same mistake we make with nearly everything. I’ve written about it at length in the context of hyperscale data centers, and I’ve argued at length why distributed beats giants in manufacturing. The premise of concentrating the load into a few big sites and you end up building spectacular efficiency on top of spectacular fragility. One bad day at one critical node and the delay ripples through everything plugged in behind it.

The difference is that a substation or a data center is affected largely by controllable factors – most things can be planned, scheduled or accommodated in advance. Security can be tightened, redundancies built into systems, fast re-routing of traffic or demand. They aren’t really affected by many uncontrollable factors, such as the the weather – they’re largely unaffected by a storm surge.

But a shipping port does.

High and dry, and underwater too

When people picture weather risk to ports, they picture the obvious version. A hurricane, a flooded terminal, containers floating off into the harbour. That happens, and it’s expensive. But the more interesting risk is the one that works in the opposite direction - drought.

Look at what happened to the Panama Canal. An extreme drought through late 2023 dropped the level of Gatun Lake, the freshwater source the locks depend on, so far that the canal had to ration itself. Daily transits fell from roughly 36 to 38 vessels down to around 18 by February 2024. Ships either waited, paid enormous sums to jump the queue, or sailed thousands of extra miles around the bottom of two continents. It took until late 2024 for capacity to recover. No storm. No flood. Just not enough rain in the wrong place, throttling a chokepoint the entire western hemisphere relies on.

The Rhine told the same story in 2022. A hot, dry summer dropped water levels so low that barges could only sail about a quarter full, capacity on Germany’s main commercial artery roughly halved, and operators slapped low-water surcharges on everything moving through. Chemicals, coal, grain, fuel. An entire industrial economy partly seized up because a river got shallow.

The climate now disrupts trade by giving us too much and too little water, sometimes in the same year, and the infrastructure that was built for a band of conditions we’re sliding out of at both ends.

Hit at both ends of the chain

Now layer the two together, because the weather doesn’t politely attack one link at a time.

In 2011, Thailand flooded. Thailand also happened to make a huge share of the world’s hard drives, somewhere between a quarter and 45% of global output depending on whose figure you take. Factories went underwater, and the world hard-drive output fell by as much as 30% in the final quarter of the year, and average drive prices jumped around 150% in the space of about six weeks. It took roughly a year for supply to recover. A flood on one floodplain in South-East Asia, and people in London and Los Angeles paid more for storage for a year.

This is the part that the shelf price never shows you. Weather can hit the factory at the source and the quay in transit and the port at the destination, and each hit compounds the last. The cost lands as a vague “supply chain issue”, gets folded into a freight rate nobody itemises, and arrives at the till as a number that’s just slightly higher than it used to be, with no label explaining why.

The premium on the premiums

This is where the hidden cost stops being a one-off shock and becomes structural, because there’s an industry whose entire job is to price exactly this risk - Insurance.

If you want to know where physical climate risk is going, don’t read the forecasts, read the insurers. They’ve already shown their hand on land. Insured losses in the US hit $112.7 billion in 2024, up about 36% on the year before. Carriers have simply walked away from the worst-exposed homes in Florida and California, with multiple insurers exiting or freezing new policies across 2022 and 2023. When the maths stops working, they don’t raise the price, they just leave.

Coastal port infrastructure sits on exactly the same risk curve. Sea-level rise, storm surge, heavier rainfall; all concentrated on assets that by definition can’t move inland. Marine cargo and the business-interruption cover behind it are repricing accordingly. And here’s the death spiral worth naming clearly: a port that becomes uninsurable is, for all commercial purposes, a port that’s closed. Nobody routes serious volume through a node they can’t insure. The premium becomes the price of trade, until one day the cover just isn’t offered, and the route quietly goes dark.

That cost doesn’t vanish. It gets spread across the freight rates of every route that’s still open, and from there onto you. You’re already paying a weather premium on your weekly shop. It’s just buried three layers deep in someone else’s insurance schedule.

Reshore, or made nearer?

So we should really accept that we have an equilibrium? If it comes to a point where importing simply costs more than making it at home, then importing is no longer viable?

In theory, yes. There’s a tipping point where the landed cost of an import, freight plus insurance plus delay plus reroute, climbs above the cost of producing the same thing domestically. The trouble is what’s waiting on the other side of that line. For a country like the UK, the honest answer is: not much. The factories aren’t there; and the once skilled workforce has thinned out or retired. And building national-scale capacity from a standing start is exactly the kind of single, enormous project we are reliably terrible at delivering on time.

Which means “produce it at home” is the right instinct pointed at the wrong solution. The answer isn’t one giant reshoring megaproject any more than the answer to compute was one giant data center. It’s the same move I keep coming back to: distribute it, and redesign the smaller thing. Many small local production sites rather than one national factory. Inland dry ports and multi-modal hubs that take the load off the coastal chokepoints. Modular and relocatable handling that doesn’t depend on armouring a single fixed quay against a sea that’s coming up to meet it.

And realistically, the equilibrium for most goods won’t be “home”. It’ll be “nearer”. Shorter sea legs, fewer chokepoints, supply that doesn’t have to gamble on a single drought-prone canal staying open. Made nearer, not made here. It’s less satisfying than full self-sufficiency, but it’s much more achievable.

There’s a genuine win-win in here, if we keep it honest. Build a meshed, distributed, weather-resilient logistics network and you get cheaper, steadier prices and a supply chain that bends instead of snapping.

The elephant on the quay isn’t going anywhere. The least we can do is stop pretending we can’t see it.

TH

Share

Find me on Linkedin

You may find these of interest:

There’s a video which first surfaced in 2008 featuring an employee from Sun Microsystems. For some reason, 18 years on, my Youtube algorithm threw this at me, and I was a little curious from the title alone ‘Shouting in the Datacenter’. In essence, someone stands in front of a full server rack rack full of spinning hard drives and shouts. He doesn’t touch it, or shake it - he literally just shouts. The latency spikes, throughput drops and the drives slow down because of the acoustic energy from a human voice.

You can also hear in that video that the sheer volume inside a data center. I’d wager that technology in the cooling systems have improved this to a large degree, but mechanical fan extraction still forms a huge part of the typical data center cooling methodology. And all of that is much more acoustic disturbance than a single human voice.

It’s a slow self-destruction of efficiency – noise affects server performance. So to overcome that, we need more server capacity to overcome the inefficiency of it.

I’ve been sitting with this idea for a few days. It started as a question about vibration isolation, turned into a question about acoustic physics, and ended up somewhere genuinely speculative; but I’m not bothered about being wrong. And largely, it’s not scientifically incoherent – so there may just be something in it.

A server rack is basically a vibration antenna

A server rack is, in essence, a precision-cut steel frame designed to hold equipment perfectly rigid, which it does brilliantly. What it also does, less brilliantly, is transmit vibration between every component mounted to it.

Each spinning hard drive generates its own vibration signature from the read head hovering nanometres above a platter, chasing sectors around at thousands of RPM. That vibration travels through the mount, into the frame, into the adjacent mount, and into the neighbouring drive’s head. Which then has to compensate, retrace, and wait for the right sector to come back around. Every I/O operation pays a performance tax on every move.

When the drives spin, it generates it’s own vibration; that vibration travels through the mount, into the frame, into the adjacent mount, and into the neighbouring drive’s head. Which then has to compensate, retrace, and wait for the right sector to come back around. Every I/O operation pays a performance tax on every move.

By how much though?

A 2009 study conducted in a world-class, raised-floor production data centre found ambient vibration caused performance degradation of up to 246% for random reads and 88% for random writes in an enterprise storage system. [Q Associates / Turner et al., “Effects of Data Center Vibration on Compute System Performance”, USENIX SustainIT 2009] Disk throughput dropped from 40 MB/s to 15 MB/s as vibration levels increased. One of the world’s largest producers of hard drives at the time, Western Digital, eventually patented ‘IsoVibe’ - a foam-and-baseboard suspension system that isolates drives from each other within an enclosure, just to manage the intra-rack noise floor.

Before you ask: yes, SSDs largely don’t care. Their solid-state architecture shrugs off vibration in ways spinning drives can’t. But as drive density increases and AI workloads push hardware closer to its thermal and mechanical limits, the vibration floor is still real; and the rack is still conducting it between every component. There’s a huge memory shortage at the moment too – so it may be a case of trying to get what we’ve got to work, until the supply and cost of the SSDs enable their use to become more prevalent.

For context, HDDs still massively outnumber SSDs because the drives are much larger in physical size but cheaper per terabyte. About 62% of enterprise storage by capacity reportedly still runs on spinning disk. So HDDs won’t disappear anytime soon; they’re the cheap, high-density option for bulk/cold storage and AI training data, giving the cheapest cost per terabyte. The data centers running the biggest HDD arrays (hyperscalers storing video, training sets, backups) are exactly the facilities where the 246% degradation figure bites hardest.

I think the deeper issue is actually more likely architectural. There’s been a good fifteen years spent building increasingly sophisticated isolation mounts, vibration-damped chassis, and acoustic baffles. All of them treat vibration as a management problem, but all of that engineering is downstream of the root cause.

The rack itself is the conductor – so I’d argue that should be where efforts are focused.

Standing still, standing waves

Acoustic standing waves are what happen when two sound waves of the same frequency travel in opposite directions and interfere with each other. The interference pattern creates nodes points in space where destructive interference means there is, effectively, no displacement. So for vibration, that means zero. Not reduced; totally absent.

This is the same principle used in acoustic levitation. Apply a standing wave field in the right geometry, and light objects are pushed toward those nodes by radiation pressure and held there, with no contact required.

Scale has always been the problem. In December 2025, physicists at the Institute of Science and Technology Austria published a paper overcoming what had been called “acoustic collapse” - the tendency for multiple levitated objects to clump together under acoustic attraction forces - by combining electrostatic charge with the acoustic field to keep objects stably separated. The demonstrated objects reached 98mm diameter and 0.608g mass. [ISTA / PNAS, December 2025, “Charging Particles to Overcome the Fundamental Limits of Acoustic Levitation”]. In simple terms, the research is tailored to other applications, with much lighter weights.

But server hardware weighs kilograms. Server-scale acoustic levitation is nowhere near currently demonstrated capability, and so I’m not going to pretend otherwise. But there’s a meaningful difference between “beyond current capability” and “physically incoherent.” The direction is right – so Id argue it as an engineering scale challenge, not a violation of known physics.

There are other cross-domain patterns; which appears in medical research. Acoustic tweezers (devices that use ultrasonic standing waves to trap and manipulate biological samples without contact) are standard kit in precision medicine labs. From nano-scale manipulation to millimetre-scale structures, all using the same underlying acoustic physics. The cross-domain question is what changes when you apply that precision to hardware sitting in a rack. It’s the same argument – the physics is perfectly sound, but it’s a question of engineering it to accommodate the weight burden.

No brackets required; it’s all about the nodes

If you design a rack’s mounting geometry around the nodal positions of a standing wave field; positioning each drive bay at a point of zero acoustic displacement - you get vibration isolation without foam, suspension springs, or IsoVibe. The acoustic architecture does the work; drives sit in silence because the wave geometry says that’s where silence lives.

This is the phononic crystal principle, already used in precision engineering to create structured acoustic “band gaps” - frequency ranges and spatial zones where vibration cannot propagate.

This is also, incidentally, the same design logic I’ve argued for from different angles in my articles on modelling nodal lattice structures to base alternative server architecture on; and my wafer server concept design. The conclusions always seem to circles back to the same place: the physical mounting architecture of hardware in a rack is an unsolved problem dressed up as a solved one.

Full acoustic levitation is the direction this points in; servers floating in an acoustic field, 360-degree airflow across every surface, no bracket restricting a cooling face, no rack frame conducting vibration from one chassis to the next. As I said at the start- speculative, but coherent.

Coherent, but still needs a caveat

The layer I flag as speculative is the same ultrasonic standing wave field that provides acoustic mounting could, in principle, carry data between servers at rack-level distances. Near-ultrasonic acoustic data transmission already exists - frequencies around 17–20 kHz are used for ad-hoc device communication with no network setup or pairing required, software-defined, deployable on existing hardware.

Current demonstrated speeds are modest (around 180 kb/s) at ultrasonic frequencies, which is nowhere near what inter-server communication demands. So the practical application of this as a primary data channel probably isn’t a near-term story. But it points at something worth thinking about; a rack where the same medium provides structural support, vibration isolation, and data transmission.

Data centers already spend considerable engineering budget fighting their own acoustic environment. The question is whether that same energy, designed in rather than fought out, does the opposite.

The acoustic principles are (literally and metaphorically) sound

Near-term, this is a redesign of rack mounting architecture around principles the acoustics community already uses. Phononic isolation geometry, acoustic cancellation arrays, nodal mounting positions. None of it requires levitation. It requires taking acoustic engineering seriously in a context that has historically treated sound as a problem to absorb.

I accept the engineering objections, and there’s quite a few aswell. Power consumption to sustain standing wave fields at server scale is unknown and probably significant. Structural stability under variable thermal loads is an open question. Of course, there’s the data transmission issue too. But these are the problems to solve, not reasons the concept fails.

TH

Share

Find me on Linkedin

You may find these of interest:

Data centers are basically heat engines running in reverse — and they’re wasting most of what they produce.

Data centers are basically heat engines running in reverse. You put electricity in, and almost all of it comes out the other side as thermal energy: from processors, from power conversion losses, and from cooling systems working overtime to push that heat somewhere it won’t cause problems. In 2025, hyperscale data centers converted somewhere in the region of 180–220 TWh of electricity into waste heat, and most of that heat went straight into the atmosphere.

Not because there’s no use for it, but simply because nobody built the infrastructure to do anything else with it.

That’s the starting point for a conversation the industry keeps almost having, but always manages to never get around to. Waste heat recovery in data centers is real. There are pilots, academic papers, and German regulations now mandating reuse targets.

The conversation usually ends at district heating; pump the warm water somewhere nearby, heat some buildings, and call it a sustainability win. That’s not necessarily wrong, but I’ve always thought it’s just a bit performative. And it’s a strange place to stop when you’re sitting on a hugely abundant potential power source, whilst simultaneously facing a structural energy shortage.

The Temperature Delta Problem

I’ll do my best to summarise the engineering case. A gas turbine running a combined heat and power (CHP) system produces exhaust gases at somewhere between 343–537°C. That’s more than enough to generate steam and run a secondary power cycle.

In comparison, standard data center air exhaust, usually comes out at 30–45°C in an air-cooled facility, rising to 50–60°C with liquid cooling. That’s too cool for conventional steam turbines, which is where this conversation usually fizzles out. To make that hotter, it’d have to be heated, which would use even more energy.

But organic Rankine cycle (ORC) systems use working fluids with lower boiling points than water, and they operate effectively from around 65°C upward, with reduced-efficiency operation possible from as low as 32°C.

NVIDIA announced in early 2026 that its next-generation AI systems can operate with 45°C inlet water, which makes waste heat recovery economics considerably more attractive than they were even twelve months ago. So this is quite exciting – and the delta between current exhaust temperatures and useful power generation is no longer fixed by physics; it’s now just a design problem.

But to be honest, it can get even more interesting than that, if we continue to steal the homework from energy suppliers.

This isn’t a completely revolutionary concept, and there are actually many hyperscale facilities are already running gas turbines as part of CHP configurations for on-site generation. In most cases, the thermal energy in gas turbine exhaust typically represents 60–70% of the original fuel input; and right now, most of that is being recovered in fairly basic ways.

The pressure question is worth asking though. Can you do more with that exhaust if you treat it as a pressurized working fluid rather than just a heat source? Combined-cycle configurations already do this at utility scale — a gas turbine drivs a generator, the exhaust feeds a heat recovery steam generator, and a steam turbine extracts a second round of power from what would otherwise be waste. Adapting that architecture to the modular, distributed footprint of a data center campus is admittedly a non-trivial challenge, but again – it’s an engineering problem, and not a physics one.

The supply chain secret

This is where the article stops being about engineering and starts being about strategy.

Gas turbine manufacturing is in a bit of a crisis. Global orders at the end of 2025 sat at 110 GW. Global manufacturing capacity sits somewhere between 60 and 70 GW. Lead times have stretched to five years. Prices are up 195% since 2019, heading toward $600/kW by end-2027 on the last published figures I could find.

In 2025 alone, 846 gas turbines were ordered globally, totalling over 100 GW — more than double 2024’s figures. GE Vernova, Siemens Energy, and Mitsubishi are all throwing capital at the problem, but you can’t double turbine manufacturing capacity overnight. Specialized labor shortages, hot-section component bottlenecks, and trade-related cost pressures mean this gap isn’t closing quickly.

Now consider who’s on the demand side of this equation. Hyperscalers spent roughly $364 billion on data center construction in 2025 (Microsoft alone had contracted 34.7 GW of clean power capacity as of late 2025).

These are organizations that think in decades, operate at enormous scale, and have the capital to make long-horizon bets. They’re also currently queueing up for turbines like everyone else; and paying the same inflated prices, waiting the same five years.

To me, this seems like a strange position for companies that have gotten comfortable owning their own undersea cables, designing their own chips, and building their own satellite networks.

It’s probably more of a venture than a vertical integration

Whilst Amazon, Meta, Oracle, Microsoft or Google could becomes a turbine manufacturer, that’s probably not the answer. MY argument is for less of a traditional vertical integration, and more of a venture-style co-investment.

For instance: a hyperscaler puts capital into a new manufacturing facility, or buys a stake in an existing production line expansion, in exchange for preferential capacity and locked-in pricing. The turbine manufacturer gets the capital it needs to grow faster than its balance sheet would allow. And in return, the hyperscaler gets supply chain security in a market where supply chain insecurity is materially affecting its ability to build and operate infrastructure.

It’s worth being specific about what “preferential capacity” actually means in a five-year-lead-time market. If you can jump the queue by two years because you helped fund the line that built your turbines, that’s a real competitive structural advantage.

The aerospace angle matters here too, because the machines best suited to data center applications aren’t conventional utility-scale turbines. Aero-derivative gas turbines, which adapt jet engine technology for ground-based power generation, have been doing this work for over 30 years. They’re lighter, quicker to ramp, and engineered to the kind of precision tolerances that data center operators already understand. Recent advances in blade materials, thermal barrier coatings, and ironically - AI-driven adaptive control systems - have pushed their efficiency and operational flexibility further still.

A co-investment thesis targeting manufacturers working on aero-derivative designs, rather than large-frame utility machines, would be well aligned with the specific operational profile of a data center campus - modular, sclable, and with tighter footprint constraints than a traditional power station.

The Decision That Hasn’t Been Made

The counterargument would be that hyperscalers should “stay in their lane”. Manufacturing is capital-intensive, cyclical, and far from their core competency, which I suppose is a fair point.

But I’d argue the ship has already sailed, and they’re already out of their their lane. They’re signing agreements with fusion startups, restarting nuclear plants, and buying hydroelectric capacity. Turbine manufacturing sits comfortably within the range of strategic bets they’re already placing, but to me the difference is this one has a direct operational payoff. It’s cheaper, and has faster access to the equipment that converts their own waste heat into power. And at a moment when power is the single biggest constraint on their growth.

There’s a real energy loop waiting to be closed. Data centers take in power, generate heat, and pay again for more power. The technology to interrupt that cycle exists; the capital to fund the infrastructure exists; and the supply bottleneck that makes vertical integration strategically attractive exists. What’s missing, so far, is the decision.

TH

Share

Find me on Linkedin

There are two numbers that, on their own, sound like good news for British tech:

• The first is the sheer weight of capital ready to build AI compute, and the UK makes good sense for european demand.

• The second is the government’s enthusiasm to wave it all in.

Put them next to a third number, though, and the optimism curdles: around 50GW of prospective data centre demand is queuing for grid access against a peak national load of about 45GW. We are, in other words, being asked to roughly double the entire country’s peak electricity demand - and funnel most of it into London and the South East - on a grid that was largely designed six to eight decades ago, and was barely coping before the AI wave hit our shores.

The proposals so far really fall down at a conceptual stage, and is a key indicator of how applying US construction models to infrastructure just doesn’t translate with the same efficiencies in the UK.

The hyperscale model is the motorway approach to infrastructure: build one enormous, high-capacity artery, pour everything onto it, and accept years of disruption and astronomical cost to lay it down. That’s seductive on a planning map; but Britain’s roads didn’t get good because we built a handful of motorways - the country runs on a dense, redundant web of B-roads that get you almost anywhere, reroute around a crash, and were mostly already there. I want to make the harder argument that for the vast majority of UK compute, the B-road network is the better piece of engineering, and not the consolation prize.

The motorway dream meets the British reality

What hyperscale needs just isn’t what we can provide. A single hyperscale AI campus wants somewhere between 100 and 300MW of firm power; 100MW alone being enough to power roughly 100,000 homes. It wants that power continuously, in one place, at the cheapest possible rate. In my road metaphor, that’s like a six-lane motorway demanding its own dedicated junction.

The UK fails to provide that energy on all three counts, and it’s worth being specific about why:

1. The power isn’t there, and won’t be for years. The demand connection queue didn’t creep up, it totally detonated. Contracted demand-side offers jumped from 41GW to 125GW between late 2024 and mid-2025, and interconnection queues in London have stretched to 7-10 years. Even after NESO took a machete to the speculative pipeline, only around 13GW of firm demand can connect before 2030, with the bulk (86GW) slated for the 2030 to 2035 window.

2. The power is the most expensive in the developed world. This is the part that gets glossed over in the AI gold-rush coverage in UK contexts. UK industrial electricity prices in 2024 were the highest of all IEA members for which data exists, both including and excluding taxes. At around 25.85p/kWh, that’s roughly four times US industrial prices and 46% above the IEA median. A data center is, functionally, a machine for converting electricity into compute. Choosing to site the most power-hungry machine humanity has ever built in the country with the highest cost electricity is a decision that needs a very good reason. Sadly, “the government is keen” is not one.

3. More than three-quarters of developers are already taking the next exit. This isn’t hypothetical. More than three-quarters of UK data centre developers are now actively looking at sites abroad rather than wait, and in 2025 and 2026 both AWS and Meta publicly paused construction on billion-dollar facilities to reassess whether promised grid connections would materialise at all.

A quick word on Britain’s track record with big things

Aside from the grid restrictions, it’s worth thinking about our history with megaprojects. Simply put, we’re total shit at them.

Take Hinkley Point C. First planned at £18bn with operations expected around 2025, the cost has now surged past £48bn, and won’t start generating until 2030 at the earliest. That’s a near-triple on budget and a five-year-plus slip, on a project whose entire job is to produce the cheap, firm power these data centers need.

Or HS2; the purest example we have of the motorway mindset. Originally estimated at £35-45bn in 2019, now revised to a range topping out at £102.7bn, with the full route not operational until somewhere between 2040 and 2043 - and they’ve quietly slowed the trains down to claw back money. A complete cancellation was dismissed because the remediation cost for work already done came in at £58bn. Let that sink in: the bill to stop exceeded the original budget to build. One grand line between two cities, decades late, and the rest of the network it was meant to relieve gets nothing in the meantime.

The pattern is consistent and it’s structural. Britain is poor at delivering single, monolithic, mega-scale infrastructure on time and on budget. So why would we architect our compute future as a string of these things, each one a bespoke decade-long fight with the grid, the planners and the local community?

The hyperscale campus concept is the HS2 of computing - enormous, singular, fragile, and perpetually three years from a press release apologising for the delay. Meanwhile, the unglamorous B-road network quietly does most of the actual work - and so that’s where we need to build our data centre capacity.

The case for the mesh

For the vast majority of UK workloads, the answer is a distributed, meshed network of small-to-medium sites. I’ve made adjacent versions of this argument for manufacturing and for modular container-based deployment, but the grid reality makes it sharper for compute than anywhere else.

1. It spreads the load instead of concentrating it. A 200MW campus needs that 200MW connection in one spot - which, in the UK, doesn’t exist without years of reinforcement. Twenty 10MW sites can each tap into existing local capacity, distribution substations, and the headroom already sitting in the network across dozens of towns. You’re not demanding one impossible new motorway junction; you’re using forty B-road turnings that are already tarmacked. This is the data-centre equivalent of avoiding the factorial scaling problems I covered in previous articles; scale comes from the volume of facilities, not the output of a single site.

2. It’s dramatically faster. The entire delay in UK data centre commissioning is the connection queue. Smaller sites that fit inside existing connections sidestep the queue almost entirely, especially when paired with on-site generation and storage. In the US, roughly one third of planned new data centre capacity by early 2026 was designed to operate wholly or partly independently of the public grid - up from effectively zero a year earlier. A mesh of energised, already-connected buildings - exactly the distressed-retail conversion play I’ve suggested in other articles, can be switched on now, not in 2035.

3. It improves latency, which is increasingly the whole game. AI inference (the bit users actually touch) wants to be close to them. A local data centre network puts compute in the centre of the towns and cities that consume it, which is the right architecture regardless of the grid argument. The grid constraint just happens to push you toward the thing you should be doing anyway.

4. It’s resilient by design. A single hyperscale campus is a single point of failure - for power, for cooling, for connectivity, and for planning objection. Close a motorway and everything stops; close a B-road and the traffic reroutes through the next village along. Same principle here - if one node drops, traffic redistributes. It’s the same logic as my Elastic Failover Exchange and Carbon Flow Failover pieces; distributed capacity isn’t just cheaper, it’s structurally more reliable, and it opens the door to trading and greening that idle redundancy rather than letting it sit there as dead weight.

We do still need the motorways, but just build them where they belong

None of this means hyperscale has no place. It means that the hyperscale DC campuses should be rationed to the few locations that genuinely justify them, rather than treated as the default. There’s a strong argument for a small number of large, power-hungry sites sited deliberately next to the grid’s actual strong points - close to existing substations, transmission nodes, decommissioned power-station connections, and emerging AI Growth Zones co-located with new generation. The government is already trying to shift data centre demand to unconstrained locations, and that’s the right instinct: put the heavy haulage where the carriageway can take it, and mesh everything else onto the B-roads.

That’s the real strategic prize for the tech firms, too. The operator that stops fighting for the handful of impossible 200MW connections and instead assembles a distributed estate of modest, fast, already-energised nodes will be deploying live capacity while its competitors are still in pre-application meetings. In a market where hardware risks becoming outdated before power is ever delivered, speed of deployment isn’t a nice-to-have, it’s actually the entire competitive moat.

A genuine win-win, if we keep it honest

Laying it all out, it’s a relatively obvious solution - the grid gets a load it can actually absorb, spread across the country instead of piled onto one overloaded junction in the South East. The tech firms get capacity now, lower latency, and resilience baked in. Towns well off the motorway map get investment and infrastructure they’d never see from a single rural mega-campus. And the nation sidesteps yet another HS2-shaped hole in the ground that’s perpetually over budget and behind schedule.

But I’ll end where I usually do. A meshed, distributed model is healthier precisely because it’s plural; many sites, many operators, many landlords, spread across many communities. The danger is that the same handful of hyperscalers with the deepest pockets simply buy up all the good B-road frontage the way they’d have built the campuses, and we end up with a toll road wearing a B-road’s clothes. The network should be distributed all the way down - not just the racks, but the ownership. Build the web of roads. As always, we just need to make sure no single company gets to own every junction on it.

TH

Share

Find me on Linkedin

You may find these of interest:

There are two stories in British infrastructure right now that nobody seems to be telling together.

The first is that the high street is on its knees. The second is that the country physically cannot plug in the data centers it wants to build. On the face of it these are unrelated problems — one is a retail story, the other an energy one. But put them side by side and something interesting happens: each one looks suspiciously like the answer to the other.

And there’s exactly one company whose two halves slot neatly into the two halves of the problem. Amazon runs one of the largest cloud platforms on earth and one of the largest e-commerce and logistics operations in the country. Most operators eyeing this opportunity would have to pick a use for the building. Amazon doesn’t.

A sector in managed decline

By now, we’re all familiar with the state of British retail. According to the Centre for Retail Research, 2025 saw 17,349 store closures and just under 202,000 redundancies - and that came hot on the heels of a 2024 that saw roughly 13,600 stores shutter, getting on for 400,000 retail jobs gone in the space of two years. The British Retail Consortium has pointed out that there are now fewer people employed in UK retail than at almost any point on record.

The vacancy figures tell the same story from a different angle. National retail vacancy is hovering around the 12-14% mark, but that headline masks a brutal north-south split. London and Cambridge sit comfortably below 9%, while towns like Newport, Bradford and Blackpool are pushing close to one in five units standing empty. Online shopping now accounts for somewhere north of a quarter of all retail sales; a shift Amazon did more than anyone to drive. Meanwhile, footfall across high streets, shopping centres and retail parks remains stubbornly 15-20% below where it was pre-pandemic.

The point og this isn’t to wallow in the decline; we’ve all grown accustomed to the convenience of online shopping, and we’re very unlikely to return to traditional retail shopping in the same way we once did.

The point is that this has produced a very specific kind of asset: large, structurally-sound, well-located buildings that nobody particularly wants to use as shops anymore, available at a discount, in the middle of towns where people actually live and work.

Sound familiar?

It should - because it’s very nearly a shopping list for a modern data center site. It’s also, almost incidentally, a shopping list for a last-mile logistics node.

They need to be repurposed - so that the existing retail can remain, whilst the real monetisation comes from diversifying their uses.

The buildings fit the brief

Strip away the retail signage and look at what these buildings actually are, structurally and electrically, and the appeal becomes obvious.

1. They sit where the demand is. Department stores and large high-street units occupy prime, central positions inside developed urban areas. For latency-sensitive workloads - and increasingly that means AI inference served close to the end user, rather than bulk storage shoved out in a field - being in the city rather than 200 miles from it is the entire game. That same centrality is exactly what last-mile delivery economics are built on.

2. They already pull serious power. A former department store, supermarket or shopping centre was built to run escalators, full-building HVAC, commercial kitchens, refrigeration and lighting across tens of thousands of square feet. That means a substantial existing electrical supply with meaningful amperage already connected to the grid - an asset that, as I’ll come to, is now worth more than the building itself.

3. They’re multi-storey and built to last. These are semi-modern, structurally robust buildings with plenty of economic life left in the fabric. Multiple floors give you something a flat industrial shed doesn’t: vertical separation between functions, and a roof and basement that can be put to clever use.

4. They’re cheap. A distressed retail asset in a secondary location is changing hands at a fraction of its replacement cost. Compare that to the going rate for “powered land” - Savills has clocked sites with existing grid connections trading at £8-15m per acre, against £4.5-6m for ordinary London industrial land. The premium is entirely about the power, not the ground.

The elephant in the substation

Here’s the problem that makes all of this urgent rather than merely interesting.

You cannot get a grid connection in this country. The demand connection queue ballooned from around 41GW of contracted offers in late 2024 to 125GW by mid-2025 - for context, peak national electricity demand in February 2026 was about 45GW. Developers have reported waiting anywhere from five to ten years for a connection, with some quoted figures stretching far beyond that. More than three-quarters of UK data center developers are now actively looking at sites abroad rather than wait.

The grid needs a generational upgrade, and the uncomfortable truth is that there isn’t the public money to do it at anything like the speed required - a bottleneck I’ve written about before as the real anchor on data center progress, not the ability to stack servers in a building. NESO’s recent cull of the connection queue, slicing it from over 700GW down to a couple of hundred, tells you how much of the demand was speculative - but it also tells you how ferociously everyone is scrambling for the connections that do exist.

Which is exactly why an existing, energised building is such a quietly valuable thing. You’re not buying the shop. You’re buying the connection, and getting the building thrown in.

For Amazon specifically, this is the route around a queue that is otherwise throttling AWS’s ability to land new compute on UK soil - the very compute it needs for the AI and inference demand growing faster than anyone can build for. A distributed estate of modest, already-energised urban sites is a way to add capacity now, close to users, without betting everything on a single hyperscale campus that can’t switch on until the 2030s.

Engineering above and below the bottleneck

An existing supply gets you in the door, but an AI workload will want more than the building’s retail-era allocation. Rather than join the back of the decade-long connection queue, the smarter play is to generate and conserve as much as possible on-site - and a multi-storey building is unusually well set up for it.

• Put the roof to work. A large, flat retail roof is prime real estate for solar PV; a private-wire array feeding the building directly, in the manner operators are already deploying to dodge grid delays.

• Look down as well as up. The basement footprint sits right against the ground, making these buildings natural candidates for ground-source/geothermal exchange to shoulder the cooling load - which is where most of a data center’s parasitic energy goes in the first place.

• Generate, store, and shave the peaks. On-site generation paired with battery storage turns the building from a passive load into something that can manage its own demand profile and lean on the grid connection only when it has to.

None of this gets you off the grid entirely, but it stretches a modest existing connection a great deal further. Crucially, it does so now, rather than in 2035.

The Amazon-shaped opportunity: compute upstairs, commerce downstairs

Here’s where this stops being a generic data center stategy, and becomes something only Amazon is really positioned to pull off. Simply gutting a high-street landmark and filling it with humming racks behind a blank façade would be a miserable outcome for everyone. The multi-storey layout lets you do something far more interesting - and Amazon happens to own both businesses that want the two halves of the building.

Upstairs: AWS, compute and AI. The upper floors become a compute node - energised, urban, low-latency. This is capacity for AWS’s cloud and the surging AI inference demand that increasingly needs to sit close to the people it serves rather than out in a remote campus. Each converted building becomes a small piece of a distributed edge network, plugged into AWS’s existing platform and operated by the team that already runs it. No competitor can integrate the racks into a live, global cloud with anything like the same low friction.

Downstairs: e-commerce and last-mile. The ground floor stays street-facing and working — but for Amazon, “retail space” means something specific. A central, well-connected unit is an almost perfect micro-fulfilment and last-mile delivery point: order online, dispatched from the heart of the town rather than a distribution park on the ring road; same-day collection lockers; returns drop-off; even a physical Amazon retail or Fresh footprint where it makes sense. The building feeds Amazon’s e-commerce machine from exactly the central location that makes last-mile economics work.

The elegance is that the two halves reinforce each other. The same building, the same energised connection, the same security and facilities team, the same logistics network that already moves Amazon’s goods can also move its hardware and spares. One acquisition, one operating model, two of Amazon’s core businesses fed at once. The compute makes the property pay; the fulfilment makes it pay twice.

And where a given site doesn’t suit either use, the ground floor still has civic value Amazon can bank as goodwill — reskilling and training centers for the post-AI labour market, in the very buildings that AI-era infrastructure now occupies, in the very towns that lost the retail jobs. For a company whose UK labour reputation is often heqavily scrutinized in the media, putting something genuinely useful back into those high streets is worth more than the floor space.

Even if Amazon doesn’t run it’s own retail space for it’s own enterprises, the operating model is the bit Amazon already understands: it runs and maintains the whole building, and where there are third-party ground-floor tenants, bills them through a service charge — the same arrangement any multi-let landlord uses, only here the landlord is running an AWS region upstairs and a fulfilment node downstairs.

A genuine win-win — if we keep it honest

Lay it all out and the alignment is almost too neat. Amazon gets prime, central, energised real estate at distressed-retail prices; sidesteps the worst of the connection queue; lands AWS and AI capacity close to users; and gives its e-commerce arm a last-mile footprint in the dead centre of town - all from a single class of cheap, overlooked building. The high street gets sustained private investment, a reason for footfall, and an anchor tenant with very deep pockets and no intention of leaving. And the town gets a community or skills asset funded by a commercial operator that’s still making a perfectly healthy return.

That’s the optimistic version, and I think it’s achievable. But I’ll end where I usually do on these ideas: this only works if it’s done in the open and within a competitive market. The very thing that makes Amazon perfect for this - that it already owns the cloud, the logistics and the retail brand - is also what should give us pause. There’s a version of this where one company quietly buys up the energised bones of the British high street and ends up owning both the compute and the commerce and the civic space of the places we live. National and community assets developed under a private umbrella are a fine thing right up until that umbrella becomes the only one in town.

Done well, the empty shop becomes the most useful building on the street again. We should just make sure it belongs to more than one landlord though; and so there’s as much opportunity for Oracle, Meta and Microsoft to deploy similar models also, although their benefits are not quite as clearly demarcated.

TH

Share

Find me on Linkedin

You may also find these of interest:

• Site location - and necessary local valuation of industrial sites.

• Proximity - to services and infrastructure (and available capacity)

• The purchaser - whether it's an owned and operated site by big tech, or venture capital funded and leased.

• The required investment to make it suitable for purpose.

Each of those are broad titles, but there's much more nuance in the detail of each; one company may be seeking a hyperscale site, which would require a huge amount of infrastructure upgrades; another may be looking at a site for a more simplistic conventional compute expansion. The same site will be worth hugely different sums to each party.

For valuers, this is a bit of a nightmare. Presently, most values are assessed through comparative methodology - finding out what other sites sold for the locality, and adjusting the value based on that. But this still introduces too much room for error and variance in valuation - a similar sized site in the same zip code area, but with ten times the available power capacity is worth a hugely different sum.

I believe there's a better way of valuing data center sites - and we can do it mathematically, formulaically, and algorithmically. If we distill it down, a site's suitability is basically the combination of:

• Site location

• Power capacity and proximity

• Connection speed and latency factors

• Proximity to water bodies and mains water pressure

The suitability of a site depends on whether each of the above fits in alignment with the purchaser's requirements for their hardware operation. And the more aligned it is, the more valuable it is to a purchaser.

The strange thing about the existing methodology is that it applies a qualitative valuation approach to factors which all have quantitative metrics attached to them. For instance, the available existing power capacity to a site will be a specific, certain amount of MW (or GW) - and yet it's only ever used as a loose indicator to inform value, without ever being tied to it.

We've got other valuation methodologies that use quantitative data to inform the capital value - income capitalization, cost approach, residual and profits methods; so we can use those as a basis to coming to a solution to a more rigid approach to determine value.

Tying all of the main site metrics together can give a scoring of a site's suitability; and then that score can be tied to the value of other local generic industrial real estate to give a specific value.

The approach: constructing a Data Center Valuation Suitability Index (DCVSI)

To come to a suitable figure for assessing the suitability and value, we need to factor in the following attributes to enable a fair assessment between sites:

Hereafter, it's quite a simple process:

1. We gather the specific values for those key attributes (power, power proximity, fiber connectivity, proximity and water pressure, site size)

2. Assign relative weights to them based on importance

3. Normalize the values so they can be compared and combined

4. Produce a Valuation Suitability Index (VSI) that can be multiplied by a market price baseline to give a value.

Scoring and Weighting the Attributes

My method is creating a straightforward normalized score for each attribute - scored on on a 0–10 scale; then we can assign weights based on importance.

Suggested example weightings (these are adjustable based on your client preferences; but ultimately most are held in a relatively similar weight):

• Power capacity: 35%

• Fiber connectivity: 25%

• Cooling water proximity: 15%

• Mains water pressure: 10%

• Site size: 10%

• Proximity to power source: 5% (admittedly, this is already somewhat captured in power capacity, but still relevant)

VSI Components and Attribute Formulas

The VSI is a formula that brings these factors together into a single, comparable score from 0 to 10. To construct it, we'll firstly gather the algebraic components of each attribute:

1. Power Capacity (P) — Weight: 35%

The single biggest constraint for a hyperscale deployment. We score this on available MW against a hyperscale target, capped at 10.

2. Fiber Connectivity (F) — Weight: 25%

Speed and redundancy drive uptime and latency. Scored on available Gbps plus a redundancy bonus.

3. Cooling Water Proximity (CW) — Weight: 15%

If you’re near a large body of water, cooling becomes easier and cheaper.

4. Mains Water Pressure (WP) — Weight: 10%

Good mechanical mains water pressure means less pumping cost for mechanical cooling, and improved flow and circulation.

5. Site Size (S) — Weight: 10%

Bigger sites will inevitably provides more options for growth and expansion.

6. Proximity to Power Source (PP) — Weight: 5%

If a site is closer to a substation, it will translate into faster deployment and less setup and fit out cost.

The VSI Formula

We bring the above together into a full VSI formula to give our score out of 10.

VSI to Value

Once we've scored a site, it's just a case of multiplying the site size by the average local market price per acre for industrial properties, and then by the weighted VSI function. This will look like:

Putting it all together: a worked example

We'll use the suggested earlier weightings for our example:

• Power capacity, Ps: 35%

• Fiber connectivity, Fs: 25%

• Cooling water proximity, CWs: 15%

• Mains water pressure, WPs: 10%

• Site size, Ss: 10%

• Proximity to power source, PPs: 5%

Firstly, we'll define what our (or our client's) requirements are for their site:

Next, we'll gather the metrics for the site we're assessing:

Now, we'll score each attribute using our above formulas, utilizing the data from the above tables:

And now, we can use those values in our main VSI formula, to give our weighted VSI calculation:

And finally, we can use our weighted VSI figure to inform our value:

Let's say our site is a 40 acre site, with a value of $500,000 per acre.

So our final figures:

• VSI: 8.3/10

• Adjusted Site Value: $36.6M (vs $20M base land value)

And that's the Data Center VSI Methodology

It's a much more refined model than comparable methods, and has benefits extending far beyond the valuation of sites for conveyancing and acquisition; this approach lets developers, investors, and municipalities speak a common language:

• Developers can prioritize high-impact sites.

• Investors and purchasers can compare apples to apples across regions.

• Cities and local governments can identify infrastructure upgrades that directly boost land value.

TH

Share

See other real estate posts

Find me on Linkedin

You may also find these of interest:

The cooling system is one of critical importance; and a significant contributor in the capital and operational expense in data center construction and management. One of the issues which the cooling system must contend with is that of thermal spikes during periods of peak computation. Suddenly, a system is required to spool up to run at maximum, or even supraoptimal, capacity. Such a draw on the electrical distribution can additionally increase risks of circuit overload, throttling and even cause the power to trip.

In order to stabilize the ambient temperature - and subsequently the demand on the HVAC or cooling systems - the easiest method is to provide a heatsink to absorb excess enery in periods of spiked compute.

A novel approach could be the introduction and integration of phase-change foundations: a concept where the building’s concrete foundations are embedded with phase-change materials (PCMs) that act effectively as a giant thermal battery, absorbing excess heat during peak computation, and releasing it during cooler periods or when energy is more scarce.

Phase-Change Materials: A solid base for foundational integration

Phase-change materials (PCMs) absorb and release large quantities of latent heat when they undergo a phase transition — typically between solid and liquid phase. During this transition, they store heat at nearly constant temperatures.

In data center applications, this, in theory, will translate into:

• Peak loads cause PCMs to melt, absorbing thermal spikes passively.

• Cooler, off-peak periods allow PCMs to solidify, releasing heat slowly and evenly.

• This thermal cycle flattens demand on mechanical cooling systems and acts as a thermal buffer integrated directly into the building.

  

Eutectic Metal Alloys could be a particularly promising phase-change solution

While many PCMs operate in the 20-40°C range, eutectic metal alloys present an exciting class of materials for higher-temperature thermal buffering. These alloys are mixtures of metals that melt and solidify at a single, sharp eutectic point, making them highly stable for repeated phase transitions.

There are a handful of relatively well-researched and documented EMAs that could be suitable:

It's quite likely that a hybridized approach may be adopted; EMAs could attract a relatively high cost component, and therefore their placement should bve specific to the direct environment.

Other suitable phase-change materials

• Paraffin Waxes [Melting Point: 20-60°C] -Stable and cheap; but low conductivity and flammable.

• Salt Hydrates [Melting Point: 28-35°C] - High heat storage; but a high risk of phase separation in exposure to higher temperatures.

• Bio-based Fatty Acids [Melting point varies on fatty-acids used] - A renewable and more sustainable solution; but limited thermal range, variable purity and more prone to degradation over time.

This is to suggest that parts of the structure which has less exposure to heat could easily substitute EMAs for more economic phase-change materials with lower melting points, such as paraffin waxes (this would likely have to be encapsulated within the concrete structure). EMAs with appropriate melting points (Bismuth-Tin, Bi-SN; or Indium-Tin, In-Sn) could be embedded on zones of the building with a higher exposure to heat generation, such as the main server storage or generator rooms.

Note: Lead-based alloys may face restrictions in certain regions due to RoHS compliance. Alternatives like Bi–Sn or In–Sn are preferred for environmental safety.

Construction integration and deployment

Eutectic alloys are not typically mixed into concrete directly, mainly due to corrosion and chemical incompatibility; but are suggested to be integrated in a variety of ways:

• Encapsulated in high-conductivity shells (e.g., stainless steel, aluminum, or graphite composites)

• Arranged as modular thermal cartridges or embedded tubes within the foundation or under raised floors

These encapsulated PCM modules are integrated into the slab (on-grade), or potentially into wall cores or cavities. Active airflow or fluid loops can assist in heat exchange with the surrounding structure.

Impacts on ambient temperature control in practice

• High Thermal Density - With latent heat capacities an order of magnitude higher than concrete alone, eutectic metal alloys store more energy in less space than alternative PCMs.

• Thermal Lag - By absorbing high-temperature spikes (~120-150°C) from equipment exhausts, they reduce the thermal gradient reaching HVAC systems.

• Temperature Stability - Creates a buffer zone for ambient air, reducing fluctuations by up to 5-8°C, easing strain on cooling units.

• Redundancy Value: In the event of HVAC failure, alloy-PCM foundations can delay critical overheating by approximately 15–30 minutes, enabling safer shutdowns and failovers.

Indicative figures, efficiency and examples

Latent heat storage:

• Paraffin wax PCM: ~200 kJ/kg

• Salt hydrates: 250-300 kJ/kg

• Eutectic metals: 40-100 kJ/kg, but with 3-5x higher density

Storage energy density:

• Bismuth-Tin (Bi–Sn) EMA ~475 MJ/m³ (vs. paraffin wax ~140 MJ/m³)

Thermal conductivity:

• Bi–Sn: ~16-25 W/m·K (vs. paraffin wax: ~0.2 W/m·K)

• In practice, this means that a Bismuth-Tin (Bi-Sn) EMA would allow a faster response to rapid load changes.

Benefits and Drawbacks

The novel foun dational integration of phase-change materials addresses:

• Flattening out peak thermal loads - Eutectic metals excel over other PCMs at heat absorption - ideally suited to buffering high-temperature exhaust outputs from dense compute clusters

• Reduction in cooling costs: The thermal 'lag' created by the absoprtion and slow release of energy reduces peak HVAC draw

• Structural synergy: Makes building mass dual-purpose - support and energy storage

• Potential for energy recycling: Released heat could be redirected or used to drive thermoelectric generators.

This is likely not a silver bullet, but forming part of a wider HVAC and mechanical cooling solution. Drawbacks are generally minimal and generally surmountable, but should be considered:

• Material compatibility - Direct embedding in concrete is not viable for metal (and many other) PCMs - typically requiring encapsulation to be successfully deployed with no adverse chemical or corrosive effects.

• Cost - Bi-Sn or In-Sn alloys are expensive; economic return on investment will depend predominantly on life cycle energy savings.

• Design complexity - Adds modeling and maintenance requirements

• Weight - High density adds structural load; must be factored into foundation design

Embedding thermal memory into the fabric of data center structures could transform how we design and operate at scale. Data centers that stabilize their own climate, intelligently and passively, could usher in a new generation of thermally aware architecture - where energy isn’t just consumed, but stored and recycled.

TH

Share

See more Engineering posts

Find me on Linkedin

You may also find these of interest:

Whilst there could be an argument to simply wait for these developments, there's as much an argument to attempt to innovate around them. I've explored the idea of a novel wafer server design to overcome the inherent inefficiencies of architecturing servers into a conventional rack, but there's another provocative approach we could attempt.

This article introduces a provocative new approach: restructuring data center server layouts into three-dimensional lattice frameworks, inspired by atomic geometries found in crystalline solids.

This concept isn’t just aesthetic; it suggests a reshape of thermal dynamics within the data center; refines network topologies and space optimization; and can be mathematically derived and optimized.

The outcome of the initial workings shows incredible promise - indicating 30% in energy savings and power requirements, with less latency and hardware; whilst maintaining the same compute capacity.

A diamond in the rough: the crystalline data center design

Rather than arranging servers in flat rows or vertical stacks, conceptualize them suspended in a 3D geometric lattice - such as a face-centered cubic (FCC) or diamond cubic structure. Each node (server) occupies a mathematically optimized “atom-like” position.

Key characteristics:

• Uniform distribution - Servers are evenly spaced in all directions, preventing hotspots.

• Atomic-level precision - Server placement based on lattice constants, akin to atomic spacing in solid-state physics. Algorithmic control of each server’s position to balance thermal load, compute density, and cabling length.

• Tunneling airflow paths - Air circulates omnidirectionally—natural convection is enhanced due to the geometric openness.

• Optimized cabling - Shorter, modular interconnections via lattice-aligned optical pathways.

• Further Refinements and Technologies could be integrated for Non-invasive Diagnostics - such as Acoustic Resonance Monitoring. This will be briefly explored later as a mechanism.

• 

For this use case, it must be considered that there shoudl be some consideration towards a more suitable material; I've already outlined that much of the material selection in current server hardware is not hugely optimized for it's use case; and much of the ancillary power consumption and cooling is simply overcoming the design flaws as a result of using low-quality materials.

To support this design physically and thermally, the first choice would be a Carbon Fiber-Infused Aluminum Alloy;

1. Strength-to-weight ratio allows vertical expansion. Important for designs that will have to support loads of other adjoining racks.

2. Thermal conductivity ensures heat dispersion across struts.

3. EM shielding properties reduce cross-talk in dense configurations.

Alternatives could include a titanium honeycomb mesh (lightweight, high thermal resistance); an Aerogel-supported steel scaffolding (Excellent insulation but likely a high cost) or 3D-printed polymer-metal hybrids (Customizable with greater degree of design geometry, but still ultimately limited by load-bearing capability).

Down to the Maths: A Proposed Optimization Formula for Network & Thermal Efficiency

Let:

Suggested Optimization Function:

Where:

• The first term encourages high airflow and low temperature.

• The second penalizes long cable runs.

• λ is a tunable constant to balance between thermal and network priorities.

Worked Example

Benefits

1. Thermal Efficiency

Natural convection paths reduce fan load; distributed heat zones eliminate hotspots.

2. Reduced Network Bottlenecks

Peer-to-peer mesh topology reduced network bottlenecks through hardware such as switches; also results in shorter average cable lengths, minimizing latency.

3. Space Utilization

Vertical stacking within spherical or hexagonal enclosures, utilizes more available eaves height; could reduce footprint of overall architecture by up to 40%.

4. Modular Scalability

Easy expansion by adding nodes in lattice-compatible vectors.

5. Advanced Monitoring

Acoustic diagnostics catch issues early with minimal disruption.

6. Architectural Freedom

Could remove the need for traditional top-of-rack switches in favor of direct optical interlinks.

Drawbacks & Challenges

1. Maintenance Complexity

Replacing a faulty node inside a dense lattice is labor-intensive. Potentially achievable with robotic assistance to extract servers. Failsafe modular access system may be required; but overall design ensures that issues are not as critical, as traffic is easily routed around any fault.

2. Cooling Design Overhaul

Traditional Computer Room Air Conditioning systems aren’t optimized for spherical or cubic layouts; and therefore would require custom airflow engineering or possibly immersion cooling integration.

3. Power Delivery

Complex internal routing needed for power cabling. There's a chance that high-density arrangements may induce parasitic losses (defined as any energy consumed or lost by components of the system that do not directly contribute to the net output or desired function) - unless carefully managed.

4. Higher Initial Cost

Custom materials and design engineering increase upfront costs; but modularity ultimately will quickly reduce manufacturing costs, owing to repeatability of design with universal applicability.

Putting it all together: The bottom line on cooling performance & power demand

Cooling Load Example:

• Traditional 1MW data center = 350kW cooling load

• Lattice model (same compute) = ~250kW

Assuming these figures, this results in a potential 28.6% reduction in cooling energy requirements over a traditional layout for the equivalent compute capacity, and over 60% less cabling per node.

Could this replace traditional architecture?

Probably not yet; the design concepts are strong enough, but they'll need to be tested and refined. There's plenty of angles for solutions, but this will be dependent on equivalent development in the cooling methodology and power distribution. Not all existing infrastrcture could be converted to this architecture readily, but new developments could incorporate it much more easily.

The lattice model would likely not negate network switches entirely, but may reduce switch hops and minimize intra-cluster switching load—especially with integrated optical mesh backbones. Ultimately the mesh configuration assists in a more dynamic and efficient routing of traffic around the system, and there's less chances of hardware such as network switches to act as bottlenecks.

Additional innovations: Acoustic resonance monitoring for non-invasive diagnostics.

In crystalline materials, phonons - the quantized vibrations of atoms - carry both heat and sound through the structure. By drawing inspiration from this principle, acoustic resonance monitoring in a lattice-structured data center could unlock continuous, non-contact diagnostics of physical and thermal states.

How It Works

Each server node in the lattice acts as both a vibration source and a resonance receptor. By embedding small, low-power ultrasonic transducers and microelectromechanical system (MEMS) microphones into the structural struts or adjacent to the server housings, a distributed acoustic field could be created across the lattice.

Servers or embedded emitters periodically emit controlled sound pulses in the 15–40 kHz range. These propagate through the air and frame, reflecting and resonating in predictable patterns. The resulting signals are captured by strategically placed receivers.

Sensor & Software Integration

• Sensors: Piezoelectric Ultrasonic Transducers, MEMS Microphones; or Laser Doppler Vibrometers for advanced surface vibration detection

• Monitoring Software: Real-time DSP Engine for Fast Fourier Transform (FFT) analysis, resonance fingerprinting and anomaly detection via AI pattern matching

• On-Premises Orchestration Software: Historical acoustic signature logging, heatmap generation (correlation with thermal, power, or vibration metrics), with an API integration with data center infrastructure management platforms.

Example Use Case: Fan Degradation Detection

1. Under normal operation, fan A emits a characteristic acoustic fingerprint (stable frequency peaks like somewhere between around 16.7 kHz and 19.4 kHz from research).

2. Over time, bearing wear subtly shifts the frequency profile.

3. MEMS sensors detect this deviation before physical failure, long before a temperature spike is observed.

4. System flags early maintenance opportunity in data center infrastructure management dashboard.

Other Applications:

• Detecting cable tension anomalies (indicative of movement or thermal expansion)

• Structural resonance shifts caused by overheating nodes

• Cross-link correlation to detect air blockage or changes in airflow pathways

Benefits of Acoustic Monitoring in Lattice Architecture

• Non-intrusive - No physical contact or internal node access required

• Continuous - Always-on background diagnostics with negligible power draw

• Predictive - Enables proactive maintenance scheduling and thermal rebalancing

• Complementary - Works alongside thermal sensors and telemetry to cross-validate anomalies

• Cost-effective - Uses inexpensive, scalable components

Utilizing such data for management efficiency

• Dynamic load shifting - If resonance shifts correlate with mechanical strain or cooling inefficiency, workloads can be shifted automatically to cooler or more stable zones.

• Cooling strategy adaptation - Resonance data highlights air flow stagnation or vibration-induced inefficiencies, triggering fan ramp-ups or duct reconfiguration.

• Infrastructure aging models - Long-term signal degradation is used to predict structural fatigue or material wear, prompting modular replacements before failures.

This lattice approach draws from physics, material science, and systems engineering to break away from the legacy flat-pack model. While challenges evidently remain, the potential for radical energy and space efficiency gains, coupled with improved fault detection and modularity, make it a compelling principle that should be considered further.

TH

Share

See more Engineering Posts

Find me on Linkedin

You may also find these of interest:

We're all familiar by this point with the challenge of heat within data centers - how to manage it, dissipate it, use it, and even extinguish it. Most solutions are active, and usually require extensive HVAC or liquid cooling systems, requiring ludicrous amounts of energy.

There's a passive approach though, and conceptually it exists in cacti, camels and pine cones. It's the concept of dynamic heat regulation - and how these organisms use their cellular structures to open and close pores to control transpiration based on their temperature exposure.

Is there a way that we could turn the skin of the data center - the walls of the building themselves - to become a passive cooling system.

This novel concept explores the application of porous, ceramic foam walls with embedded smart phase-change materials (PCMs), hybridized with aerogel insulation and clad in adaptive facades - manufactured into prefabricated wall panels.

Together, this layered system could enable self-regulating, passive cooling for data centers—minimizing reliance on active HVAC systems, cutting energy costs, and redefining what's possible in data center design.

Reflecting on the Convection: Core Design Concept

1. Variable-Porosity Ceramic Foam

Engineered ceramic foams (such as silicon carbide or alumina) provide a structural and breathable base layer. These foams can be manufactured with graded porosity to promote natural convection airflow when internal temperatures rise, and restrict it when cooling is not needed.

By designing these foams with temperature-responsive porosity, it's possible to create structures that modulate airflow based on thermal gradients.

• In cool conditions: Pores remain partially closed to conserve internal temperature.

• In hot conditions: Pores open to allow convection and facilitate natural ventilation.

This mimics how certain desert plants or animal skins regulate heat exchange passively.

Some suggested materials options:

• Alumina (Al₂O₃) - high thermal resistance, stable up to 1500°C - good for general use.

• Silicon Carbide (SiC) - superior thermal conductivity, strong structural stability - best for high performance walls.

• Zirconia (ZrO₂) - low thermal conductivity, high strength - useful in low-temperature environments

Recommendation: Silicon Carbide foam, due to its durability, heat conduction, and compatibility with phase-change material embedding. However, it will have to be combined with a hybridized construction technique and adaptive facades to respond to humidity within the outdoor environments.

2. Embedded Smart Phase-Change Materials (PCMs)

Phase-change materials embedded into the foam matrix absorb and release heat at specific thresholds, smoothing temperature spikes:

• Daytime heat: PCM melts, absorbing excess heat without raising internal temperatures.

• Nighttime cooling: PCM solidifies, releasing stored heat gently, extending the thermal stability window.

Standard PCMs buffer heat by melting and solidifying near target operating temperatures (e.g., 24–28°C). In this system, microencapsulated paraffin or salt hydrates are infused within the foam matrix.

The innovation lies in smart PCM integration:

• Tiny temperature and state-of-phase sensors are embedded within the PCM capsules.

• These provide real-time thermal profiling, enabling building automation systems to adapt in response.

• Combined with IoT and AI systems, the walls become part of an intelligent feedback loop—predictively managing cooling loads.

Some suggested materials options:

• Paraffin Wax; transitioning phase at around 25–30°C, with a latent heat of 200kJ/kg. Low cost, stable and easy integration; but not the most sustainable solution.

• Salt Hydrates (e.g., CaCl₂·6H₂O); transitioning phase at around 29°C, with a latent heat of 190-220kJ/kg. Higher heat transfer but can be corrosive. I'd have concerns absout ambient gaseous salt ions reacting with metallic server hardware, which could increase corrosion rates.

• Bio-based fatty acids; transitioning phase at around 20–28°C, with a latent heat of 180kJ/kg. This is the most sustainable solution, and is also biodegrable - but as a result, also relatively unstable.

Recommendation: Paraffin wax, for its safety, tunable temperature window, and ease of microencapsulation.

3. Aerogel Hybridization

Ceramic foam is structurally advantageous, but lacks the ultra-low thermal conductivity needed for complete insulation. To address this:

• Silica-based aerogel blankets are proposed to be laminated behind the ceramic foam layer.

• These aerogels have thermal conductivities as low as 0.015 W/m·K—lower than any other solid material.

• They serve as a thermal break, keeping exterior heat from penetrating while allowing the foam-PCM layer to handle transient heat spikes.

4. Adaptive Facade Integration

The outer layer of the wall system can further enhance performance through adaptive facade technology. Options include:

• Thermochromic coatings working via a color/pigment change with temperature to reflect more heat - enables passive solar control.

• Phase-change shutters with louvers that open/close based on expansion of PCM wax - creating a mechanical-free control of airflow/light

• Electrochromic glass qwith electrically controlled tinting glass; could easily integrate into other building automation.

• Bio-mimetic skins (e.g., ETFE cushions with embedded actuators) with a dynamic envelope that expands/contracts with conditions - would enable an architectural flexibility and climate responsiveness.

Recommendation: Use thermochromic ceramic coatings on the exterior skin to modulate solar heat gain without moving parts, supplemented by mechanical-free PCM-based louvers for passive ventilation when required.

The Good, the Bad and the Ugly

• ✅ Passive, self-regulating cooling

• ✅ Low maintenance, with few to no moving parts

• ✅ IoT-enabled thermal intelligence, capable of real-time monitoring and dynamic adjustmebt

• ✅ Fire-resistant, chemically stable materials

• ✅ Reduces reliance on high-coefficient of performance HVAC systems

• ✅ Modular for retrofits and edge deployments

• ⚠️ Higher initial capital expenditure due to advanced materials; but arguably a quick return from savings in energy bills

• ⚠️ Moisture sensitivity of PCM and aerogels (requires robust sealing). If parrafin is not used as the PCM, some others would require encapsulation prior to embedding.

• ⚠️ Structural fragility of ceramic foam (requires composite frame reinforcement, but this could be fabricated from recyclable materials from conventional constructions.). Panels could not be utilized for load bearing

• ⚠️ Sensor calibration & long-term stability must be validated

• ⛔️ Parrafin PCMs arguably not the most sustainable material choice, but still the best for this application. Further PCMs could be developed for this application.

Manufacturing and Cost Profiling

Fabrication Process

1. Foam Casting: Silicon carbide foam panels formed via direct foaming or polymer sponge replication.

2. PCM Microencapsulation & Infusion: PCMs embedded through vacuum impregnation or mixed into slurry pre-firing.

3. Aerogel Layer Integration: Laminate aerogel insulation sheets to the back of foam panel.

4. Smart PCM Sensors: Add microthermal sensors at encapsulation or during post-processing.

5. Facade Layer Assembly: Add thermochromic ceramic coating or prefabricated dynamic cladding.

6. Final Encapsulation & Framing: Seal with breathable, waterproof membranes and mount into modular frames.

Indicative Bill of Materials [assuming a 1 m² Panel]:

• Silicon Carbide Foam (10 cm) - $100

• Microencapsulated PCM (2 kg) - $40

• Smart Thermal Sensors (2–4 units) - $25

• Aerogel Blanket (1 cm) - $50

• Thermochromic Facade Coating - $20

• Lightweight Frame (Al/Composite) - $20

• Assembly + QA - $30

Total Bill of Materials assumes an approximate cost of around $285/m²

Advanced Design Techniques and Further Refinements

A slower manufacturing technique, but the benefits of an additive process - 3D-Printed Graded Porosity; to create customized porosity layers per panel section for directional airflow. Possible suitable for some sections of some walls where intake or exhaust flow is of more critical importance.

Utilising Finite Element Analysis, Digital Twins + Thermal Modeling to simulate and validate passive performance before deployment.

Turning Passive Walls into Active Participants

This concept is proposed to be a systematic-level rethink of the data center envelope. It's accepted that ceramic foam walls embedded with smart PCMs is not going to solely solve the cooling requirements for data centers, but could assist in being part of the solution for lower humidity environments.

As we approach the limits of active cooling and carbon budgets, concept materials like these offer a quiet revolution. Individually a small contributor, but collectively improving the performance and sustainability of our new essential infrastructure.

TH

Share

See more Engineering Posts

Find me on Linkedin

You may also find these of interest:

Most modern data centers provision twice the capacity they need to ensure business continuity. One set of servers sits idle or “warm,” consuming power for the rare moment it’s needed. The expense and energy comsumption is the collateral damage for uptime; but in the era of climate consciousness, perhaps we should be aiming to move towards a design which can account for both resilience and responsibility.

The Concept: Carbon Flow Failover

What if your disaster recovery site wasn’t just the nearest, but the greenest?

Carbon Flow Failover is an concept that uses real-time carbon intensity data to influence where workloads fail over during an outage or surge.

Instead of defaulting to a fixed disaster recovery site, the system dynamically chooses the location with the lowest environmental impact at that moment.

This is a great time to implement such a protocol, as developments in the infrastructure management are starting to align with the corporate and social responsibilities for data centers.

• Energy grids are no longer static. Renewable penetration varies hourly and regionally.

• Infrastructure is programmable. With cloud-native tooling, dynamic provisioning is the new norm.

• Sustainability is business critical. Carbon flow failover supports corporate environmental, social and governance goals; and can reduce scope 2 emissions (indirect electricity use).

How It Works

1. Carbon Signal Ingestion - continuously ingest real-time carbon intensity data for each region/data center:

• Sources: WattTime, ElectricityMap, or local grid operators.

• Metrics include: gCO₂eq/kWh, marginal emissions, and renewable % of grid mix.

2. Site Readiness Registry - Maintain a dynamic inventory of standby or disaster recovery-capable sites with:

• Live health status (infrastructure, connectivity, network latency)

• Available failover capacity

• Local carbon intensity score

3. Failover Decision Engine - A policy-based decision engine evaluates:

• Calculates a composite sustainability-weighted score for each failover site.

• Selects the site with lowest net impact within SLA bounds.

4. Workload Migration / Activation - Data Redundancy workloads are spun up or scaled in the selected green region [Tools: Kubernetes federation, HashiCorp Nomad, OpenShift, etc]. DNS/load balancer redirects traffic accordingly.

5. Reporting & Audit - System logs the failover action, location, carbon delta, and time; and subsequently generates reports for ESG compliance or carbon accounting.

A suggested implementation stack

There's plenty of integrations that could work; and will more likely depend on the individual systems, firmware and softweare being utilized within the infrastructure itself; but some suggestions could be:

• Carbon Data Feeds - WattTime API, ElectricityMap API, NREL open datasets

• Monitoring/Health Checks - Prometheus, Grafana, Datadog

• Decision Engine - Custom Python/Go service, Terraform policies, Open Policy Agent

• Workload Orchestration - Kubernetes multi-cluster, Nomad, ArgoCD

• Failover Routing - Cloudflare, NS1, AWS Global Accelerator, Akamai

• Audit/Compliance - ESG tools (Watershed, Persefoni), carbon APIs, ledger logging

Superior Sustainability Scoring - Benefits at a Glance

Traditional Failover

• Always-on, static location

• Ignores carbon impact

• May waste energy 24/7

• Single failover path

• Focus: uptime only

Carbon Flow Failover

• Adaptive location based on real-time data

• Optimized for green energy availability

• Cold/warm Data Redundancy can be spun up dynamically

• Multiple flexible Data Redundancy destinations

• Focus: uptime + sustainability

What’s been done, and the enhancement opportunity

While carbon-aware scheduling has gained momentum in cloud computing (see Google’s work on Carbon-Aware Compute, or Microsoft’s work on carbon-intelligent load shifting), applying this explicitly to failover and redundancy systems is still nascent and largely untapped.

This is a space ripe for innovation and policy shaping, although many of the solutions would be transferable from existing systems and architecture through integrating API protocols.

The above methodology addresses some of the fundamental gaps in the current models operating by Google and Microsoft:

• Google’s Carbon-Aware Compute shifts jobs to cleaner regions during low-priority batch processing.

Carbon Flow Failover activates on-demand in response to outages — it includes emergency resilience, not just scheduled workloads.

• Microsoft’s Carbon-Intelligent Load Shifting focuses on batch jobs in flexible time windows.

I'm proposing multi-region active-passive failover optimized for latency, sustainability and Service Level Agreements, useful for production systems.

• Google and Microsoft are both focusing on internal cloud provider operations.

This proposed model is infrastructure agnostic: applicable to any enterprise or hybrid cloud with multi-site Data Redundancy.

• Current methods use basic regional CO₂ averages.

This model proposes the use of marginal emissions, time-of-day signals, and forecasted grid carbon intensity. [API Integration to WattTime API, ElectricityMap API, NREL open datasets]

• In the Google/Microsoft systems, sustainability is only considered post-deployment.

This model suggests making it part of the failover decision tree itself — sustainability-aware resilience, not just compute.

Conceptual Growth and Development Potential of Carbon Flow Failover

• Forecast-Based Carbon Pre-Warming - Use machine learning to pre-warm standby sites before a predicted high-carbon period, shifting workloads proactively.

• Carbon Budget-Aware Disaster Recovery Policies - Allow organizations to set annual/monthly carbon budgets for failover; failover happens only if the action stays within the carbon envelope.

• Smart Disaster Recovery Escalation Protocols - In cases of multi-site failure, the system can choose partial failover to multiple greener sites rather than one dirty but close site.

• Carbon-Aware Service Level Agreement Tiers - Offer users the ability to select Data Redundancy policies based on lowest latency, lowest cost, or lowest carbon.

Carbon Flow failover is perhaps the next frontier in sustainable cloud infrastructure. It's the convergence of DevOps, sustainability, and intelligent systems - effectively turning disaster recovery from a reactive necessity into a strategic lever for environmental stewardship.

TH

Share

See more Engineering Posts

Find me on Linkedin

You may also find these of interest:

In traditional infrastructure design, redundancy means duplication. One server fails, another takes over; or one data center goes offline, another picks up the load.

It's reliable, but it's also inefficient; with most data centers typically running with between 40–60% of their capacity unused, as a large proportion of the infrastructure and architecture is just dedicated to backup scenarios.

If we think about redundancy strategies as an insurance policy - the current state is madness:

Redundancy is just a digital insurance policy that currently costs far too much; and realistically pays out far too little to justify that expense.

I have no clue on the exact figures for this, but it's safe to say that if 50% of the hardware infrastructure cost of nearly all data centers is purely for redundancy protocols, then it must be billions of dollars invested in idle hardware; megawatts of unused energy; and square kilometers of underutilized rack space.

The smart loading systems do aim to use some of this capacity during periods of intense operations; but it's still not optimal - such capacity is only monetized to a partial degree - and likely never enough to justify the cost of the capital outlay. Existing infrastructure nearly has to work for double the rate of return to cover the costs of it.

We need to come up with a method of monetizing the redundancy architecture better - it needs to be elastic, flexible, and pre-determined. Short term and affordable for a customer; but generating an additional revenue stream for the operator.

Today's concept is what I'm dubbing as an Elastic Failover Exchange. This could also be thought as 'Redundancy as a Marketplace' - and is effectively commoditizing redundancy capacity to be bought for short term periods.

Redundancy as A Liquid Resource

So what's the use case for this? Consider the example:

• Company A has spare compute capacity in Singapore.

• Company B, in the same region, wants to run disaster recovery drills or prepare for the typhoon season, where they could be a potential outage.

• Instead of over-provisioning their own infrastructure, Company B rents failover capacity from Company A — just for a week, or a day.

This is the basis for the Elastic Failover Exchange:

A system where failover capacity is bought, sold, rented, or shared — not statically owned.

This is a concept which is already relatively well tried and tested in other domains - and infact, can create a staple income stream once the market is matured and solidified.

• Electricity markets: Providers buy/sell surplus power, especially in grids with renewables.

• Spot cloud pricing: Cloud providers monetize unused capacity dynamically.

• Bandwidth peering: Network capacity is traded between ISPs to ensure balance and efficiency.

In theory, there's no reason why we can't compute redundancy.

The Mechanisms and Monetization

1. A Redundancy Exchange Platform, selling Smart Contracts or SLAs.

• A digital marketplace (for instance, easily integrated into AWS Marketplace or Meta could be positioned to operate a similar service from their experience in marketplace also);data center operators and providers list available "redundancy slots".

• Tenants purchase redundancy as a time-bound service with defined SLA. Redundancy commitments are governed by enforceable contracts.

• This would be very similar to spot instances, but for failover infrastructure with guarantees.

2. Mechanised and Orchestrated by APIs

• Failover orchestration systems (like Kubernetes, Nomad, or OpenShift) connect to the marketplace to claim and activate backup infrastructure dynamically.

3. Real-Time Monitoring + Monetization

• Usage-based billing triggers only when a failover event happens.

• Idle time can be billed at a discount — or zero, depending on the model.

The Win-Win Window of Opportunity

M<onetization windows of time assists both startup businesses and data center operators - slots are only sold when capacity exists. In terms of implementation, a team far more intelligent than me with software could probably get this implemented and rolled out fairly rapidly, for little to no cost to operators with significant software skills in the workforce.

• Cloud-native architectures: Stateless, containerized apps can be spun up anywhere.

• Observability tooling: We can measure failover success and SLA compliance in real time.

• Sustainability goals: This model reduces carbon and energy waste by maximizing active utilization.

• Economic pressure: Enterprises want resilience without doubling their cost base.

Providers and Operators (sellers) - Monetize idle infrastructure instead of wasting it.

Buyers (businesses/tenants) - Get access to data redundancy capacity without having to undergo any capital expenditure.

Cloud & Colocation Operators - Have an opportunity to add a new service tier, positioning failover as a revenue stream.

Sustainability teams - Reduce footprint by minimizing unused hardware.

Addressing the Challenges - Not Perfect, but Pretty Close

There are a handful of challenges that would need to be realistically considered, but nothing which would be hugely difficult to overcome - and there's likely already existing systems which could be replicated to address them:

1. Trust & SLA Guarantees - What if failover capacity isn’t available when needed?

Likely overcome by the use of verified contracts, auditing, and automated checks (blockchain, escro systems, etc.).

2. Latency / Data Locality - Some failover needs ultra-low latency or regional compliance.

This is where the beauty of the marketplace can come in. Buyers and sellers within jurisdictional or regulatory boundaries can be matched algorithmically. Local redundancy markets could form within metros or countries.

3. Security & Tenant Isolation

The platform must enforce strict multi-tenancy and container/network isolation, like any public cloud. This should be a basic service component which nearly all operators or providers will be doing already as part of their other services.

Some Potential Use Cases, and What It Enables

Use cases could include:

• Startup clusters buying DR capacity from hyperscale-friendly regions.

• Colocation facilities sharing excess with partner sites.

• Edge infrastructure providers offering redundancy to local governments or health systems.

• Multi-cloud failover without vendor lock-in.

and in turn, a successful implementation would result in:

• A circular economy for compute.

• More democratic access to disaster recovery — especially for small and medium enterprises.

• Reduced global energy waste.

• Better ROI on infrastructure investment.

Redundancy doesn’t have to be static, nor wasteful. It can be a shared, traded, and intelligent layer of infrastructure — where resilience is a product, not just a cost.

The cloud taught us that compute should be elastic, and so there's no reason why we can't make resilience and redundancy elastic too.

TH

Share

View more Business articles

Find me on Linkedin

You may also find these of interest:

It's a great film about overcoming business challenges and spotting market gaps.

McDonalds really won over their competition for two reasons; the first is standardization of their products - everyone who ordered knew it would always look, taste and cost the same as it did last time. Whether you order your food in Alaska or Arkansas, this is still the case - you always know exactly what you're going to get.

But their biggest innovation was the creation of true 'fast' food. The McDonald brothers were the first to apply first-order manufacturing and production line principles into a commercial kitchen to create a level of efficiency that simply no other restaurant could begin to compete with.

There's a great scene in 'The Founder', where they show how the McDonald brothers conceptualized the redesign of the kitchens for maximum efficiency. They chalked out the kitchen footprint on a tennis court, and gathered the employees to enact their roles in the kitchen.

They iteratively refined the layout until they came up with the perfect system - with minimal time in moving from process to process; eliminating double handling or backtracking; and ensuring that there were no employee crossovers or bottlenecks.

Their first attempt was rather incredible in comparison to the status quo at the time; but the concept has been further iterated and latest technology leveraged to continue their reign as pioneers of efficiency. Automation, pre-prepared and packaged ingredients, custom engineered catering equipment and top ergonomic and anthropologic commissioned research has continued to develop their process efficiency even more.

Although some of their solutions are indeed specific to the catering industry; there are certain principles which their kitchens are based off:

• Standardization: McDonald's process is highly standardized, with each task and workflow carefully mapped out to ensure the most efficient use of time and resources.

• Training and Process Protocols: Every employee is trained to perform tasks with maximum consistency.

• Lean Operations: The elimination of waste and constant drive to streamline processes, with a robust supply-chain and pre-packaged products where appropriate. No movement is unnecessary, and no time is wasted.

• Technology Integration: The use of technology to track, manage, and optimize performance (e.g., timers, sensors to assist in monitoring for quality control).

• Speed Balanced with Quality Control: The balance between delivering a fast product without sacrificing quality.

These principles are largely transferrable to many applications; but for this example, I'm proposing a novel take on how to apply them in the context of operating theater design and fit-out.

The direct correlation: the McSurgical approach

Aiming to draw parallels as far as practicable with the above principles leads to create an initial brief for redesign concepts:

• Standardized Surgical Processes: Just as McDonald’s has precise workflows for each menu item, hospitals can develop highly standardized procedures for operating theaters. It's accepted that some operations will have a degree of variability - as ultimately, every patient is different - but there are certainly many procedures that are similar enough to standardize for a large part. Surgical kits could be implemented that include only essential tools, pre-organized, sterilized and packaged for specific surgeries, reducing time spent searching and procuring equipment. Once spent, they can be repackaged into disposable containers for processing, incineration or sterilization by other staff.

• Training and Protocols for Surgical Teams: Streamlining surgeon, nurse, and support staff training using clear protocols, much like McDonald's staff training on consistency and efficiency. Modular training programs have been utilized in many industries as a way of developing training for staff, and would equally work as well in this scenario - although it's noted that this is not a core component of this brief, so won't be focused on much further.

• Lean Principles for Operating Theaters: Reducing unnecessary movement or steps by designing operating theaters with efficient layouts and tools that are always in the right place. The idea is to eliminate “waste,” such as unnecessary tool sterilization cycles, or inefficient use of resources.

• Technology to Improve Workflow: Just as McDonald's uses point-of-sale systems to track orders, operating rooms can integrate software to track surgeries in real-time—monitoring instruments, team members, and progress. Robotics and automated solutions could serve to benefit this eventually, but there will be greater leverage from maximizing lean principles to start with - technology could deliver better efficiency, but it's implementation will come at a larger cost.

Theater Adaptations - some novel design attributes

Centered and Modular - The Overhead Gantry Concept

Although ceiling-mounted fixtures are commonplace in operating theatres, there is a more universal solution capable of integrating increased modularity, ease of handling, and assistance for surgeons, staff, and patients to develop greater ergonomics and efficiency measures.

This will be similar to the solutions used in industrial manufacturing facilities for the use of overhead gantry structures which will feature rails capable of moving bearing-mounted fixtures.

Fixtures which are permanent and commonplace throughout all operations, such as:

• Lighting

• Diagnostics & Vital Signs Monitoring

• Waste management (such as suction machines)

These can be mounted on the gantry system combined with articulating and actuating arms. These accessories can be rearranged in an infinite amount of configurations to suit the individual surgeon, the procedure, and patient welfare.

Additionally, certain fixtures could also be installed on the gantry system combined with motorised units to create an automated sweep function 360 degrees around the room; this will come in particularly useful for sterilization processes, which will be detailed in sections below.

Waste Disposal and Management

One efficiency measure that appears to be regularly overlooked within hospital environments, (admittedly, sometimes owing to the existing infrastructure and build design), is the waste disposal and management seen within operating theaters.

Which still can regularly rely on conventional lined bins where waste is segregated in the theatre itself before being bagged and taken elsewhere for processing.

Staff skilled in operational techniques are not best suited to carrying out basic sanitisation and waste segregation.

Therefore, similar to many other manufacturing processes, the waste disposal and management should be dealt with by a system that simply extracts all waste from the first instance where it can be separated and managed via automation screening or other manual separation by specialist hygiene professionals.

How this translates in reality is a centralised waste chute in the centre of the operating theatre. The all-waste can be quickly transferred into an underground conveyor system or chute system that will transfer the waste to a centralised processing location where instruments, metals, and other incinerable waste are collected via magnetization or detection. Other forms of hazardous waste and other medical waste can be dealt with by alternative means.

Fundamentally, this is ensuring that all time within the operating theatre is dedicated to practises pertaining to operating itself and no other ancillary operations such as cleaning or waste disposal. Are absorbing the time of the skilled members of staff.

This approach also ensures that there is minimum time and exposure to shared atmosphere between contaminated instruments or tissues and the operating theatre environment, ensuring that all potential contaminants are continuously being evacuated from the sterile environment. This practice will also assist in reducing sterilization cycle time between operations, potentially enabling operations to be carried out nearly back-to-back if required.

Sterilization and Infection Control - in-procedure and between procedures

It is recognised that no single fumigation or sterilization method is 100% effective. Therefore, a number of different approaches using the most common technologies would assist in serving the most efficient type of sterilization.

Certain fixtures could be installed on the Gantry system combined with motorised units to create an automated sweep function 360 degrees around the room, fixtures could even be multi-purpose - such as using the rear concave side of the surgical light to contain UV-C or Blue Light Panels. The concave outer will assist in serving to provide a greater spread and exposure to the light.

Floor and eaves vents are to integrate a full HVAC system, combined with a full fumigation system. This will enable the most effective longer cycle sterilization when time permits, but also features shorter cycle solutions between operations.

In practice, the most effective sterilization system will be an automated approach, using lighting panels and the HVAC/fumigation system in tandem:

• Continuous sterilization where possible through the use of blue lighting panels overhead of surfaces, mounted as full ceiling tiles. There will also be Hydroxyl generators to run continuously throughout the room, in loop with continuous extraction and air treatment. Both processes are deemed to be safe amongst humans and equipment.

• Between surgery - a 360 degree UV-C light sweep from a gantry mounted panel or fixture, which could be carried out in short cycles between surgeries. To improve efficiency even more, modular pre-sterilized carts with all equipment required are prepared in advance, and wheeled in as and when required.

• Overnight and periods of dormancy - Hydrogen Peroxide Vapor and/or Formaldehyde Fumigation - typically longer cycles, creating a more sterile environment, and unlike the lighting based sterilizers - is not limited to line of sight exposure.

Finally, consideration could be given to a one-way system for all staff and patients to take:

• An entrance where all equipment and staff that enter through it must be of a sterile nature prior to entering the theatre, to ensure that the sterilisation status is maintained and contamination only occurs at minimal levels and when absolutely necessary.

• An exit for the patient following surgery back onto the ward.

• Additionally, an ancillary exit for all of the staff, trolleys, storage equipment, operating tables etc to exit through to go elsewhere for sterilization.

In order to maintain the efficiencies of the operating theatre, new sterile equipment is simply wheeled in as modular units through the first door.

Ergonomics and Anthropological Considerations

The most recent data on ergonomics and effects of colour on neuroscience indicate that hues of blues and greens assist in maintaining an environment of calm and peace. This is typically seen amongst many of the existing medical equipment, but the blue panel ceiling will assist in developing this further. As a result, walls can be kept white in colour, gaining illumination hues from the blue light panel ceiling.

A direct crossover from the McDonald's model would suggest a redesign of the operating theatre with clear zoning and workflow paths to ensure that equipment, instruments, and staff are positioned to minimise any unnecessary movement.

Specifically, this will encompass a circular or U-shaped layout where the surgeon's main area, the scrub nurse station, and surgical assistance tools are within arm's reach for all parties, minimising the need for staff to move around the room during procedures. Finally, 360-degree screens mounted at eye level throughout the entire room will also assist in giving clear visual representation of vital signs throughout the entirety of the surgery to all parties.

In reality, this will transpire as effectively as smart operating theatre design, very much akin to smart home where lighting, temperature, and air circulation are controlled with a single interface.

There are plenty of other optimisations that could inevitably assist in refining any of these ideas further. The implementation of AI and other technological advancements will assist in improving efficiency to an even larger degree. However, in the interests of maintaining some brevity for this discussion, those concepts can be explored later in other publications.

It does serve an interesting concept however - often seeking inspiration internally to a problem simply results in an echo chamber; whereas looking to other industries as to how they overcame their challenges can often serve as a better starting point.

TH

Share

See more medical posts

Find me on Linkedin

You may also find these of interest:

Could it be argued that cloud evangelism is starting to show its cracks? It seems that everyday there's a fresh report of a data breach. And increasingly, there are plenty of businesses that are migrating away from the cloud and back to local, on-site server hardware.

Cloud computing does have a number of huge benefits; and really points to the underlying reason for its popularity over recent years. A robust set of architecture that has been relatively cost effective with lower management obligations; global access; disaster recovery; but predominantly for ease of scaling.

But it's never been the perfect solution for all businesses though, and particularly in the case of financial institutions. They absolutely have a requirement for scalable storage, but it's always been a balance of providing that in conjunction with mitigating the main drawbacks:

• Latency matters — in trading, milliseconds can mean millions (or even billions).

• Cybersecurity is local — risks compound when you're sharing infrastructure with a thousand strangers. Colocation in data centers has mitigated some of this risk; but it's never going to be eliminated.

• Regulation is growing teeth — and it's biting down hard on sovereignty, auditability, and compliance.

We’re entering an era of data nationalism and zero-trust by design, where the idea of running sensitive workloads in some abstract, amorphous “region” doesn’t sit right with boards or regulators. Equally, ditching the cloud entirely isn’t viable either - there are too many dependencies.

But there's a solution: what if data center operators stopped trying to pull banks into the cloud - and instead brought the cloud to the bank?

Data (city) centers - prime real estate for free

Site acquisition within inner-city areas remains a continuous challenge for modern data center operators. With most primary real estate in major cities such as New York, Seattle, San Francisco, Miami, and others often exchanging for extremely significant premiums that can only be genuinely justified and afforded by businesses making substantial, continuous, and stable profits.

As a result, many directly central inner-city areas - although possessing a large demand for data center infrastructure - often rely on sites up to thousands of miles away, owing to the uneconomic rental (and operational) overheads from running an inner-city facility.

There is significant mileage to be gained from rolling out more urban data center infrastructure though:

1. Deeper enterprise foothold. Some suggest that cloud growth is starting to plateau, and the next frontier is more likely to be industry-specific infrastructure.

2. Localized infrastructure has near-zero latency. Inner city clients such as institutions carrying out high frequency trading would pay a premium to have a lower latency than their competitors.

3. Future-proofing the cloud narrative. By embedding inside regulated institutions, data center operators avoid any potential regulatory whiplash coming for public cloud platforms. It becomes part of the critical infrastructure fabric, not an external dependency.

The billion dollar idea: cloud infrastructure baked into bank vaults

This idea is a win-win if it can be pulled off: data center operators - Google, AWS, Equinix, Iron Mountain or Meta - launch specialist divisions to build embedded cloud infrastructure directly inside financial institutions. Private, secure, fully-managed micro-regions installed within the walls of a trading firm, investment bank, or clearing house.

As more office workers have shifted to more remote or hybrid working patterns, there's likely an abundance of square footage of space available to be repurposed - and still likely enough room for the plant, cooling and operational infrastructure required to run it.

I imagine this more as a a bespoke infrastructure cell, run by hyperscalers but physically and logically isolated to serve a single tenant. The data center operators would have a specialist team or division with the security clearance to operate and manage these systems exclusively.

Effectively cloud-grade tooling at zero latency for the financial institutions. Increased interconnectivity and infrastructure for data center operators. A win-win situation, which also provides a natural way out of the binary cloud/on-premises debate too.

This could be a complete new category of cloud computing

A specialized team builds modular, scalable infrastructure nodes that live inside the walls (and under the policies) of the institutions they serve. Cloud-native tooling, AI-powered observability, API-driven provisioning - but with the physical security and audit trails you only get from an on-site infrastructure model. Infrastructure that’s sovereign, secure, and smart, without being centralized.

This is arguably less about building the cloud where it should be, and more about building it where it needs to be.

TH

Share

Find me on Linkedin

See other Engineering Posts

You may also find these of interest:

For those unfamiliar, Bloomberg operates a subscription model for each trader within a financial institution, which gives access to industry news, market prices, data insights, as well as a trading platform operated by their own proprietary hardware, infamously named the Bloomberg terminal. It's an iconic industry standard, and one that has never changed.

The Bloomberg Terminal's continued use throughout modern day financial institutions is one of general compatibility - as it is utilised by all of the financial institutions, it remains an important staple part of all operations. Nothing performs as well as the hardware, and no other hardware integrates as well with the software.

It's the same playbook that Apple have created with their hardware and software pairings; and Blackmagic Design with their daVinci products also with their video editing software and controller.

A Chilling Truth: Cold Chain Logistics is Currently Crap

One of the fastest developing sectors in pharmaceuticals is the the rise in the prevalence of biogens and personalized medications. This is arguably fast approaching the peak of medical and pharmacological technology, but it's being let down by the simplest factor - logistics.

The issue with these medications, is that they often require to be kept at a very stable temperature - which can be down to as a cold as -150 degrees celsius for cryogenic chilling; but as a bare minimum, many require a stable temperature of around 2 to 8 degrees celsius.

There's a few reasons for the piss-poor performance, but it can all be distilled down to a simple fact - noone owns the process. And as such, there's no accountability for when it doesn't go to plan.

(which, conversely, seems to be most of the time).

1. Firstly, there can be a complex chain of custody. Sometimes this involves many different logistics partners. Many use completely different systems. Some good, some bad. Some are fine, but badly operated; some are bad, but operators just have to do their best.

2. This means that as soon as there's a gap in the tracking, there's a chance of mishandling - for products to exceed their safe temperature range, damage to product or packaging etc.

3. As with much of logistics, the real weak point is the last mile delivery. Everything from bicycle courier through to HGVs can be utilized. The product can travel thousands of miles in perfect condition, and then is ruined at the last stage. Infrastructure is often lacking when delivering to more remote areas - making transit times and methods very unpredictable.

4. Very few logistics partners have dedicated solutions for these purposes. Temperature regulated storage can exist, but it's a little rudimentary - the reality is that medicinal products only form one tiny part of their total packages they will handle; and their vehicles will be built to suit the widest specification of packages, and not tailor made to the transportation of medical goods. About the best solution that's currently mustered is an insulated coolbox, usually ABS shelled with expanded polystyrene cores.

There's other more macro problems with this practice also:

• Complexity from Personalized Medicine: The rise of biologics, gene therapies, and patient-specific treatments requires smaller, more frequent, and highly specialized shipments. These products often have unique storage needs (including ultra-cold or cryogenic temperatures) and short shelf lives, complicating logistics and increasing the need for precision and speed.

• Regulatory Compliance: Stricter global regulations demand robust tracking, serialization, and data integrity throughout the supply chain. Meeting these requirements is resource-intensive, particularly as regulations evolve and differ across markets.

• Visibility and Data Fragmentation: Ensuring real-time visibility of temperature, location, and chain of custody is challenging, especially when using multiple logistics partners and crossing borders. Data silos and fragmented systems make it difficult to monitor and respond to issues promptly.

• Sustainability and Rising Costs: Environmental regulations and the push for sustainability are driving up costs. There is pressure to adopt eco-friendly packaging and reduce energy use, but these solutions can be expensive and technologically demanding.

• Packaging Optimization: Advanced packaging is needed to maintain temperature stability during long or unpredictable transit times. This includes insulated containers, gel packs, and smart packaging with temperature sensors. However, optimizing these solutions for cost, weight, and sustainability is a complex balancing act.

• Expansion into Emerging Markets: As pharma companies reach into new regions, they face challenges transporting temperature-sensitive products over long distances, often through areas with poor infrastructure and unpredictable customs processes.

A cold-chain gold rush; and why medical device companies have the perfect shovels

There's an opportunity to simply specialize in cold-chain medical logistics, and the bar is currently set very low to do it well - with a little effort, and a deliberate attempt to get this implemented, the market can be totally sewn up before competitors even have a chance to begin assessing it's addressability.

So why medical device manufacturers?

• There's a Cashflow Gap - Pharmaceutical developments in arteas such as diabetes means that some divisions of medical device companies have been quietly shut down. Something needs to fill the hole left from that lost revenue.

• This requires a hardware solution, and they're already pros at it - It's a simple product development, and noone is better set up to handle the challenges, select the best materials and practices to get this designed and operational. It can be manufactured in their existing facilities, using their existing equipment - and so can be scaled as linearly as required as the business and network develops.

• As the hardware is proprietary, it's software system can be integrated into the MedDev company's existing system. It's a simple GPS tracker and in-case sensors with cellular connectivity, implemented into the logstics system with a simple API.

• The only gap is the logistics side, but this could be completed with a simple acquisition of the right company. A perfect acquisition could be a division of Brinks or Axiom - these companies regularly carry out the ultra-secure logistics for transferring cash and valuables between banks. They're used to uninterrupted chain of custody solutions; transport utilizing secure specialist vehicles that are fully tracked and monitored from end-to-end; and delivering with a precision with effectively zero margin for error. All of the existing skills and systems could nearly be entirely replicated and it would carry a perfect success.

• Medical Device companies already have the existing contact and customer base within the medical industry - everyone from hospitals and clinics through to pharmacies and individual practitioners. It should be an easy sell - they're already a trusted partner, and offering a specialized service that has been lacking for a serious amount of time.

• And finally - operating just one specialist logistics domain enables a potential monopolization of the market for this. Existing logistics partners are too overleveraged in their other operations to implement this with any form of agility. The MedDev company will own and operate the specialist transport containers, which will protect them from competition - other companies can implement the transit, but none are as well positioned to design, develop and manufacture the storage containers.

Pull this off, and you've just created the Bloomberg of cold-chain logistics. Hardware, software and distribution cornered; and then it's just a case of maintaining and expanding however far you wish to go.

Holes in the hardware

Insulated containers are being used currently, but they're a little basic - alot of them passively cooled with an ice block nestled in a expanded polystyrene container with an outer plastic shell; the most complex is usually a mini-battery powered fridge.

The good news is that there's an opportunity to develop it leaps and bounds, and much of the technology already exists - little development is needed, it's more just a case of packaging existing solutions correctly.

• I'd suggest a modular solution - three compartments, individually sealed - a battery and component base, (with all of the technology and main systems installed); cryogenic container in the middle, cooled via a closed loop of liquid nitrogen. And finally, a refrigerated container on the top, to enable a lesser temperature to be maintained in a separate sealed

• The majority of the weight will be at the bottom with the batteries and refrigeration components, so the case will naturally always store this way - and reduced chance of the case ever tipping over or becoming disturbed in transit.

• Although this is mainly cooled via active systems, the whole exterior is finned so the entire case continuously acts as a passive heatsink. A metal outer finned shell will assist in this through material properties.

• A visual indication screen will assist in monitoring for the courier - with audible and visible alerts and warning lights showing any signs for concern or attention. The case will have an integrated GPS system, and cellular or satellite connection. As the whole outer is to be metal fins, these can be wired in to act as a whole antenna for these systems, resulting in absolute minimum chance of it losing signal etc.

  

Specifics for the software, please

1. Trusted Real-Time Chain-of-Custody Platform (Digital Custody Transfer)

There's no universal, immutable, and simple digital platform for logging chain-of-custody handovers in real time, especially one usable by low-tech field workers. This addresses:

• Lack of trust or traceability during transport (handoffs between logistics providers, drivers, hubs).

• Manual paper logs still common in many markets.

• Gaps in audit trails during temperature excursions or delivery delays.

Solutions could include:

• A blockchain-based or tamper-proof digital logbook for handoffs, using mobile/NFC/Bluetooth validation.

• Each participant (driver, warehouse, pharmacist) confirms custody and condition with a tap or scan.

• Simplifies GDP (Good Distribution Practice) compliance.

2. Predictive Thermal Degradation Analytics (Beyond Temp Monitoring)

Existing trackers tell you if a product exceeded temperature thresholds, but don’t predict or quantify the impact on drug stability or efficacy. This could address:

• Uncertainty about whether to discard a product after an excursion.

• Need to minimize wastage and insurance claims while ensuring safety.

Solutions could include:

• AI/ML models that consider time, temperature curves, and medication type to estimate remaining potency or shelf life.

• Mobile app or API integrated with existing temperature data loggers.

• Could guide pharmacists on accept/reject decisions and improve incident response.

3. Micro Cold Chain for Last-Mile Transport in Rural/Underserved Areas

Many developing or rural areas lack reliable last-mile cold chain infrastructure. Vaccines or biologics can commonly spoil in the last few miles (bike courier, rural clinic, etc.), and temperature control is often out of the sender's hands during final delivery. A proprietary hardware would address most of these issues; but additional solutions could include:

• Peer-to-peer or local courier optimization software, integrated with a compliance and monitoring app.

• Backup solar-powered or phase-change-material-based containers for low-resource settings and markets.

4. Simplified Cold Chain Data Standardization and Interoperability Layer

There’s no easy way to standardize and share cold chain data across stakeholders using different hardware and platforms. Manufacturers, third party logistics providers, warehouses, hospitals often use different systems. As a result, data silos and there's a lack of a universal data schema for cold chain status. The easiest solution for this would be:

• Lightweight middleware or API layer that normalizes data from disparate IoT sources (data loggers, GPS, ERP); creates a real-time dashboard for all stakeholders, but should enable a “plug-and-play” integration with minimal effort.

5. Environmental Condition Forecasting & Routing AI

Few products combine weather, route, and vehicle conditions to preemptively adjust logistics in real time. Most logistics providers operate static routing, which can't adapt to sudden environmental risks. Integrating this functionality would place increased priority on product integrity, which is core for vital medications.

This could be implemented by utilising AI to route in real-time and provide packaging recommendations based on current and forecasted temperature/ humidity, traffic conditions and types of product being transported.

And that's it.

Simple hardware combined with a relatively straightforward software. A market which is a serious roadblock in modern pharmaceutical manufacturing and distribution, and slightly too specialist to be offered by existing logistics providers.

This is a ripe opportunity for the right person; companies with large cash reserves or access to capital should consider moving with agility, and the market could be cornered relatively quickly.

In addition, there's additional opportunity for distribution of blood, breast milk and organ and tissue transplants between medical facilities also if the tracking and traceability protocols are refined sufficiently to meet regulatory compliance.

Although this has the potential to be a gold mine for the company that corners this market, there's a more important outcome from this -less missed opportunities and treatments, and increase in patient welfare and probability of successful outcomes.

TH

Share

Find me on Linkedin

You may also find these of interest:

There's one sector of property that is showing increasing promise despite its challenges: the investment into data centers. These facilities were once solely invested in by tech companies or cloud providers, whereas now venture capital firms and REITs are seeking an increasing amount of this square footage to form a key part of their portfolios.

I'll state the obvious though. A data centre is not a factory. It is not an office, and it's quite unlike any other form of commercial real estate. Carrying more complexity, demand, and competition than some other asset classes. Specialist in many regards and to a large degree in some aspects. Not as specialist as many other infrastructure installations, such as power distribution, renewables installations, or oil and gas facilities.

So, for traditional investors looking to dip their toe into this new world, the market appears to have stabilised sufficiently to begin to give a broad overview of the types of deals and negotiations that often take place for new and existing sites. These are a different beast to conventional commercial and industrial property however, and there's certain considerations and differences that can hugely affect a property's viability and value.

Broadly speaking, there's three main threads that run through all aspects to inform the property deals - power distribution, cooling capacity and connectivity.

The money, the makers and the mechanics

There is currently an unprecedented demand for good data centre sites. These facilities were traditionally once largely funded by major tech companies (what would have once been referred to as FAANG - Facebook, Amazon, Apple, Netflix, Google - companies). They would have secured the sites, constructed the data centers, and operated them as the freeholder thereafter.

After the first few operational years in the early 2000s, there was a marked shift towards venture capital firms providing the funding to construct these properties which are then leased to the above tech companies; new tech companies (Oracle, Salesforce etc) or increasingly specialist data centre operators (Equinix, Iron Mountain etc). Many sites would require investment into increasing infrastructure capacity also. Even legacy sites could now require additional investment into increasing capacity again, as AI applications require much more power and cooling.

This is to enable the larger tech companies to utilize more of their capital in the increasingly costly fit-outs of these properties - the server fit outs, cooling solutions and networking infrastructure will be of the absolute bleeding edge of the current technology, in order to provide a little future-proofing to their investment.

Leases appear to be typically offered for 15-20 years. Rent/rates review clauses were quite variable on older leases; but owing to the current demand for these sites, it's expected for more frequent review clauses to be more commonplace.

Additional conditional review clauses can also be implemented in the event of a phased infrastructure investment plan that may not be fully operational at the time the lease commences.

Reutilization at renewal

A recent report on the churn rate of existing legacy data centres that have been under lease for the past 15 to 20 years has shown that typically, on average, around 86% of sites have been re-utilised at the end of an existing term for a similar use.

This is predominantly due to the site's relative interconnectivity between other infrastructure and other data centres - factor that is of more critical importance to the overall operations than building and hardware itself.

Again, on average, rent/rates appear to have increased by up to 22% on renewal leases. However, it should be recognised that sites with a greater power capacity (even if that capacity is not already realised or operational) are now starting to attract much more significant premiums owing to a low number of sites that would be suitable for AI hyperscale data centers rather than the traditional compute types.

The general consensus within the industry throughout the late 2000s was the expectation that rents would decrease by around 15% upon the renewal terms, as it was expected that these properties would have more limited use, and may not necessarily be reutilized at the end of their existing terms. Legacy sites were once thought to become obsolete in favour of more modern infrastructure, but they do appear to have a intrinsic benefit where a lower latency is required for certain applications - it’s more achievable for those targets to be served by local facilities rather than trying to force more through a centralized hyperscale solution.

These sites could be utilized for modern applications, but will likely involve end users having to place more reliance on inference - using data locally stored on devices to inform responses to queries, with lesser requirement to route through data centers and cloud facilities.

It should also be expected that the premiums such sites are currently attracting will inevitably likely soften as the overall network of data center infrastructure spreads out wider into a more even and uniform distribution; and especially if inference applications increase in use.

A concept you'll be used to...Location is everything, but not necessarily for the same reasons.

Traditional real estate is dependent on location; most commonly for desirable areas with strong demand for rental, good transport connections, local prosperity, centralised locations, distribution networks, or otherwise.

Whilst arguably these considerations are factors in the context of data center sites, there are really four parts of the location in particular that have significant sway on the value and the variance of demand a certain site may receive.

1. Ashborne, Virginia

Likely not the one you thought would be key, but Ashborne - located in Virginia - is currently the hot spot for the US data center development. This was one of the first critical areas where significant infrastructure investment was made in the early 2000s. Currently, it's estimated that around 70% of all internet traffic in the US passes through data centers located here.

Significant investment continues to be made in this area, and as a result, sites are trading for a significant premium far beyond and in excess of any other sites in the country.

2. Power - Grid Infrastructure, Distribution Networks and Generation

There are some variants in quoted figures in terms of power requirements for data centres, but loosely speaking:

• It is thought that a typical compute data centre can use an average 36MW of power, easily stretching up to 60MW of power.

• However, in comparison, an AI hyperscale data centre can use anywhere between 100 to 300MW of power for the equivalent size of facility. T

• o put this into normalised terms, 100 MW of power is enough to power around 100,000 homes in any one region.

Therefore, the infrastructure required to run these facilities are significant; and as a result the number of areas which currently have the ready capacity, distribution and existing grid infrastructure to serve these facilities are relatively slim. Those areas that do possess such capacity and distribution will carry a significant premium over the existing.

The power requirements can be mitigated to a partial degree by an adjustment in cooling methodology adopted within the facility. However, whether liquid or air-cooled solutions are chosen, either will have a significant power component contributing significantly to the draw of the facility. For context, most facilities typically employ a hybrid system with a combination of liquid and air-cooled solutions.

3. Cooling - Water, Geology, Altitude and Climate

A concept that has been widely written about is the challenge of implementing cooling within modern data center developments; as these facilities have significant requirements to maintain a stable temperature. The hardware and associated infrastructure required to run it are renowned for producing significant amounts of heat - all of which which needs to be dealt with, processed, cooled and re-circulated either in liquid or gaseous form as a continuous loop as these facilities operate - 24 hours a day, 7 days a week, and 365 days of the year.

The cooling system can simply be an extension of the power requirement, especially in the event of the most basic air-cooled solution. However, more commonly, capacity tends to be met by leveraging the data center site itself. The access and proximity to bodies of water - be that open forms in rivers or lakes, proximity to sea/ocean water or access to subterranean aquifers - can assist with site selection criteria. For instance, sites located in areas with colder climates will obviously have less requirement for ancillary cooling solutions over those which are located in warmer temperate climates. If you were selecting for cooling ability alone, you would consider favouring Alaska over Arizona.

A lesser consideration - but one nonetheless - is a site's altitude. For a site located in a higher altitude above sea level, the ambient air may be considerably thinner than in other parts of the country. Additionally, climate and altitude can inform the natural humidity of the air which can have a huge impact on its suitability for air-cooled solutions within a data centre facility. In subtropical and humid environments in particular, any air that is taken in usually must have a large amount of moisture extracted before it may be used for air cooling purposes to avoid condensation build-up and to reduce the air density around the hardware within the facility.

A process such as that inevitably places additional strain on... you guessed it... power requirements.

This is just one example of the co-dependence of many of these factors, which are currently creating significant challenges for suitable site acquisition for major companies.

4. Connectivity - Latency, Inference, Transfer Rates and Compatibility

The argument for connectivity remains a continuous battle. The critical goal is to reduce latency as much as practicable to win the business of specific clients who demand a premium service. For example, Financial Institutions executing stock market trades, Defence Contractors, as well as Emergency Service Communication Channels and other core operators within a modern domestic society.

As mentioned previously, latency can be overcome to a partial degree by increasing inference on a user device level basis to ease reliance on the required data centre infrastructure.

Thereafter, within the data center facility, transfer rates and compatibility are the two key factors, although it should be regarded that this is less of an issue for the landlord or investor and more of an issue for the tenant or data center operator. Systems in most modern day installations are currently fibre optic based, and switch architecture is regularly updated as part of the ongoing maintenance and refinement of data center systems by operators.

On a more macro level, insofar as the investor is concerned, connectivity as a topic pertains more to a certain facility's proximity to other facilities by the same operator which could make a certain site a more valuable addition to one operator rather than another. As operators begin to roll out and create a network with a more uniform distribution across a country or continent, this will become a lesser factor. This sector may develop in time to be more akin to practises adopted by mobile and cell operators by sharing physical facility and infrastructure space with their own equipment.

Connectivity is arguably one of the lesser considerations for the time being and is relatively easily updated and overcome in comparison to some of the other factors. However, it can remain as a roadblock on some sites which would otherwise be regarded as particularly suitable. As wireless and satellite communication is developed further, sites deemed to be unacceptable on the basis of connectivity alone may soon become a more economic proposition for investors. Therefore, keeping a finger on the pulse of the developments within that space would be a wise move going forward.

Location sorted? Onto the Lease Structure

It is difficult to realistically give a broad brush approach, when so many sites operating in so many jurisdictions will ultimately have a huge variance in contextual factors. However, some first-order principles can be used to form the basis for leases. These are not designed necessarily to be exhaustive but perhaps serve as a good starting point to give illustration as to what parallels or differences may be drawn to deals which conventional real estate investors are more akin to.

• It is typically going to be a long lease term of 15-20 years in order to enable a realistic return on investment to be realised. As mentioned above, rent or rate reviews throughout that term will likely be structured at relatively regular intervals (every 3-5 years, to market rate or conditional on operational metric) within the current market. This may adjust as more sites become operational going forward.

• Of all the above factors, the power bank and grid distribution infrastructure will likely remain one of the most important factors going forward. Even if capacity is not currently required, it will nearly certainly be required in the near future. Sufficient funds should be planned to continuously upgrade infrastructure within the locality as required, and such infrastructure should be written as terms within the lease to enable increased rates to be charged upon completion or phased rollout.

• The investment in infrastructure will represent probably the largest cost for the investor, and therefore the maintenance of this infrastructure is critical. Certain provisions should be expressly written into leases as to the roles and responsibilities of such maintenance.

• An unconventional clause, but a consideration in light of expansion and connectivity; trigger clauses drafted to enact increased rates should operators open a number of sites in close proximity to a certain facility. Long term, this could soften the value or demand for the investor's facility - as competitors will not want to exist as a sole facility in the center of another dominant operator in a certain area. As a result of this, a reduced market demand will enable a softer lease renewal price going forward. Contractual provisions may be considered to be drafted in order to recognise this.

This is an exciting sector that will soon develop into a level of maturity that the remainder of industrial property has undergone. Unlike conventional infrastructure arrangements, which typically see a more specialized market, the requirement and prevalence of data centres forming part of community infrastructure assets going forward is more likely to see a more standardised deal structure, more akin to traditional office, retail, and manufacturing space.

Until this point, investors should be prepared to consider all opportunities potentially containing a range of vernacular agreements specific to site and context. And be willing and open to take such decisions based on the merits of each individual proposal.

As with many opportunities in business, favour fortunes the brave. Those who took the brave leap in the early 2000s have ended up becoming some of the most powerful and influential companies in human existence. Equivalent opportunities exist for the wealth and facilitators for these businesses also.

TH

Share

See more business posts

Find me on Linkedin

You may also find these of interest: