I’ve written before on the difference between Business Continuity (BC) and High Availability (HA). Having delivered a presentation in London recently on Project Failure, and am writing another along similar lines for UKRC in June, I’d like to cover what I believe to be the number 1 strategy for successful BC that is covered in both of those.
A central tenet to BC is risk management. Within risk management one identifies risks, quantifies them, prioritises them and mitigates them. This is important, and for any operation of any scale it should probably be handled within a well structured methodology – whether PMI, PRINCE2, NIST or any of the other frameworks. But there is more..
A number of years ago while I was developing a BC strategy for a large hospital, I had an insight. I happened to be reading “The Black Swan” by Nassim Nicholas Taleb. Its a great book and well worth a read but one of the basic points is that if one were to look back over pretty much any period in history – the events that have shaped today’s world were simply not predictable. It was inconceivable that the events leading to the First World War would have the consequences they did. Ditto with the rise of Hitler and WWII, or 9/11 and subsequent military action in Afghanistan and Iraq. The individual inputs to today’s economic crises were well understood, but who predicted where we have ended up today? The notion that taking a finite number of inputs to a chaotic system and confidently predicting the outputs is flawed.
And it is the events that cannot be predicted that will always have the greatest effect – precisely because they are not predictable, and therefore cannot be mitigated against (at least, specifically).
In my mind, there is only one way to mitigate against the unknown risk. That is, to have skills and agility at your disposal to be able to react to the unexpected when – not if – it happens. That brings me to what I think of as a spectrum of programme delivery strategies.
At any point on the spectrum – there is a combination of internal resources as well as external (usually vendor) resources. I have my own preferences (having a technical background, I tend to back my own skills), but in many respects any programme (or initiative within a programme) can find a perfectly appropriate place anywhere on that spectrum. The histograms in the graphic indicate the level of influence that different groups have over the programme (albeit somewhat caricatured), But equally indicate where the skills required within the programme reside.
I’m old and hoary enough to remember the world of IT in the early ’90s. Back in those days – ‘downsizing’ and ‘outsourcing’ was all the rage. There was no need to have an IT department AT ALL, went the argument. A reputable, specialised service with properly written contracts and SLAs was all that was needed. But very quickly, a situation evolved in many organisations where the internal skillset had atrophied to the point that the organisation needed external help to specify and manage the contracts and SLAs. Enter the ‘consultants’, exit control and stability. Fortunately, ‘downsizing’ became ‘rightsizing’ where there was a recognition that it is of strategic benefit to retain some skills inside the organisation.
I would argue that the strategic benefit should extend to maintaining the ability to react to the unexpected in an agile – yet controlled – manner. To some extent, that means holding, and nurturing, skills, processes, tools, industry awareness and industry contacts within the direct control of the organisation. All of those – especially the latter two – require an investment in time that must be balanced carefully but are important nonetheless.
So at the extreme left of the spectrum lies ‘the cloud’. For the moment, I won’t quibble about the difference between ‘private cloud’ and ‘public cloud’. There is a huge difference but I’d like to consider the ‘public cloud’ – which is entrusting an entire service – its resources – and its data – to ‘somewhere else’. I maintain a positive scepticism to the public cloud – I use cloud products myself although only because I can reassure myself that I have the skills, the infrastructure and the tools to cope with anything that might happen within those (not under my control) clouds.
I do however see organisations choosing to occupy the left-hand-end of the spectrum inappropriately:
- Because it is a ‘default’ choice made through lack of awareness – or willingness – to consider alternatives.
- Because the cost savings documented can often derive from a perceived opportunity to divest of skills and agility.
Agility should always be at least considered as a necessary output from any initiative within a programme. To do otherwise may well be costly.
Note: This post sat as a draft for a while until an article from John Halamka prompted me to finish it off. The article covers the challenges often described as VUCA. Addressing those challenges very often requires – guess what – people having skills and agility
Latest from the Blog:
- High Availability
- Lessons learned
- Open Source
- PACS General
- Project matters
- Martin Peacock on Virtual Servers and PACS
- Edward Mangiola on Virtual Servers and PACS
- Globalstorage on Business Continuity Planning in Health IT
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game