For as long as I’ve been working in IT, I’ve been an advocate of flexible, adaptable infrastructure. The reasons have always seemed compelling. Adaptable environments tend to cost less over their lifetime, they make it easier to respond to new business requirements, and they allow you to modernise incrementally rather than through disruptive big-bang projects.

In my experience, few IT professionals would disagree with any of that. Yet in practice, the principle often gets lost. When capacity runs short or a new project comes along, the easiest thing to do is place another order with your existing supplier for more of the same. That’s entirely understandable. Teams are stretched, the priority is usually quick delivery, and standing back to consider the bigger picture and longer-term needs can feel like a luxury.

What has changed is the volatility of the external environment, which can now make sticking with more of the same a riskier choice than it once was.

No longer one-off events

Every infrastructure decision is partially a bet on the future. For many years the ground was stable enough to plan with reasonable confidence, and when a crisis or disruption did come along, there was usually a period of recovery before the next one arrived. That no longer seems to be the case. Digital sovereignty, energy constraints, supply chain problems, shifting workloads, a moving AI picture and volatile prices are all in play at once, and the disruptive events now arrive faster than most organisations can absorb them.

When considering this, it’s important to recognise that even seemingly far-off events can often cascade right down to front-line IT. For example, an international conflict might restrict critical trading routes, leading to long and unpredictable lead times and higher prices for equipment. Procurement for a key project then gets brought forward to ensure availability, and before long you’re reshuffling funding and resources and replanning accordingly. Similarly, a key supplier under pressure from investors may unilaterally impose a product, policy or pricing change, leaving you to scramble to assess the impact on your longer-term strategy.

AI deserves a brief mention here. While many pundits talk as if AI is front and centre in every infrastructure discussion, for most teams it’s less about building dedicated high-scale environments and more about supporting AI extensions to familiar applications, or AI functions that vendors build into application updates. That too is a factor largely beyond your control.

Five principles for adaptable infrastructure

You can’t control most of these forces. What you can do is make sure your environment is adaptable enough to absorb the shocks. In a recent advisory paper, we set out five principles to help with this. The focus there was server technology specifically, but the principles hold if you broaden your view to IT infrastructure in general. 

1. Technical and architectural adaptability. Wherever possible, favour open, standards-based and modular platforms that can be reconfigured, extended or swapped out as requirements change. We still come across many systems that were originally, and arbitrarily, built around a piece of proprietary infrastructure that has constrained every decision since. Some workloads, such as VDI, HPC, AI and modern ERP, can genuinely benefit from tightly coupled stacks, but that should be a conscious choice made for the right reasons.
2. A balanced, sovereignty-aware vendor strategy. The risks to manage here are vendor lock-in, something I’ve written about before, and foreign government over-reach. Lock-in is not just about switching costs, but also about a vendor’s ability to impose new pricing or terms unilaterally. In an infrastructure component context, it can be worth paying particular attention to bundled management and patching software (which often includes remote access), and to the vendor’s home jurisdiction.
3. Financial and commercial flexibility. Demand can shift up, down or just sideways, which can be hard to manage with a Capex-centric or traditional leasing approach. Consumption-based models, where equipment sits on-premises but you pay for what you use, are therefore worth considering. These can help absorb change and, with the right contract, allow equipment to be refreshed without a capital write-off.
4. Efficiency and headroom by design. Facility upgrades rarely keep pace with server, storage and networking demands, and newer workloads tend to increase density, heat and power draw. Building in headroom helps prevent facility limits constraining your ability to adapt. Energy efficiency is the other side of the same coin. It enables you to stretch existing capacity, and it has now become a genuine first-order requirement.
5. Supply and delivery resilience. Shortages and price volatility now appear to be a persistent fact of life. An adaptable architecture allows components to be substituted from different sources, and if sovereignty matters to you, it makes sense to ensure some of those sources are located in your region.

Final thoughts

With volatility now looking like a permanent backdrop to IT service delivery, infrastructure adaptability moves from being a convenience that might save time and money later to an operational priority. But this is easier to say than to address in practice.

The truth is that adaptability is a shared responsibility. Decisions made at the server level, for example, ripple up and across as well as down. Others are likely to be impacted, such as application teams, database and middleware specialists, plus security, network and storage groups. Business, finance and risk leaders also need to be considered. And just as importantly, infrastructure teams need the freedom and backing to spend a little more time or money when it counts, rather than defaulting to another order for more of the same.

As ever, how you apply the thoughts and principles I have touched on will depend on your own circumstances and constraints. In the meantime, you can download a full copy of the paper I mentioned here.