In discussions about IT resilience, the idea of sweeping change inevitably comes up sooner or later. A new architecture, a new operating model, everything transformed at once. It sounds impressive, and that is precisely where the trap lies. Revolutions look good on slides. Evolution delivers real improvements in resilience.
The first question that usually arises is whether resilience can be built in stages or whether it requires one major overhaul. The answer is clear. It can be developed gradually, and that is exactly how it should be approached. Redundancy is the absolute minimum required for resilience, while the other characteristics of a mature architecture emerge as the organisation develops. By its very nature, resilience is an ongoing process, not a project with a single completion date.
A phased approach does, however, come with one condition. The first step should be to eliminate the greatest risk. This point should be taken literally. It does not mean the risk that is easiest to remove, the least expensive to address or the one that happens to have an internal advocate. It means the greatest risk.
The methods described by Talex can help identify it: four uncompromising questions about preparedness, ten questions the board should ask the IT department and one question about the most significant single point of failure. The answers usually point to the same area. That is where the first stage should begin.
This sequence works for two reasons. The first is obvious: the company’s actual exposure begins to decrease from day one. The second is less apparent: each stage builds on the one before it. We saw this when comparing infrastructure models, where hosting or colocation may serve as the first step, while the environment created in this way can later become part of a hybrid model. Evolution does not rule out an ambitious destination. It simply provides a safer route towards it.
A phased approach also has a human dimension. A large-scale implementation that delivers no visible results for many months may lose support before it has had the opportunity to make a difference. Completing a stage within a reasonable timeframe gives the organisation tangible proof that the change is working and provides a strong case for taking the next step. Resilience then grows alongside confidence in the entire process.
One practical issue remains: how do you convince an organisation to pursue evolution when revolution sounds more attractive? The most effective approach is to shift the discussion from technology to business. Instead of focusing on technology, focus on risk and cost. In technology-led discussions, bold visions and innovation tend to prevail. In business discussions, what ultimately matters is the business case: which risk are we eliminating, how much will it cost and what will happen if we do nothing?
This change in language offers another advantage. It brings the board and finance into the discussion – the people who make decisions about risk and cost every day. We have previously argued that the board must own cybersecurity. Risk and cost are the natural terms in which that responsibility should be discussed.
Finally, an honest observation about slides. Plans for revolutionary change really do look impressive in presentations, and sometimes they are necessary. But business resilience does not grow in presentations. It grows with every risk eliminated, every scenario tested and every stage built on the one before it. Evolution may be less spectacular. But it works.
