The cloud model has put a large and growing range of products and services within reach of virtually any kind of organisation.
As cloud offerings have matured, single ticket items have been complemented with much more complex services. It's now possible to purchase quite complex things − such as platforms, for example − from the cloud quite easily.
One notable example is disaster recovery (DR), which is a highly-complex service and one on which, in the last resort, the organisation will depend; it's the classic “last plane out of Saigon” (or perhaps Kyiv).
DR includes backups that have been offered as a service via the cloud for a while, but it's much more than just that. The almost complete dependence of most businesses of any size on IT has propelled the governance of technology onto the board agenda.
King IV's Principle 12 states: The governing body should govern technology and information in a way that supports the organisation setting and achieving its strategic objectives. Recommended Practice 13 specifically alludes to the need for the board to ensure IT systems can be recovered effectively in order to keep business disruptions to a minimum; “the governing body should exercise ongoing oversight of technology and information management and, in particular, oversee that it results in...arrangements to provide for business resilience and proactive monitoring of intelligence to identify and respond to incidents, including cyber attacks and adverse social media events”.
In the pre-cloud world, DR involved providing a recovery site that mirrored the organisation's data centre. The entire IT environment had to be replicated at determined intervals to the recovery site to ensure that, in the event of a catastrophic event, the company could switch over to it and continue operating with the minimum disruption.
This naturally involved a great deal of capital expenditure, plus a punishing commitment to the management and support of the DR site, including regular testing to ensure that, in the event of need, the environment could be recovered successfully − definitely not a foregone conclusion.
Getting DR right isn't easy, but it's essential for any business for which downtime is costly.
Many companies find it hard to justify this kind of Rolls-Royce DR; for those that must have it for regulatory reasons − or their adoption of governance best practice − it's inevitably something of a grudge purchase.
The advent of the cloud made it possible to purchase a largely automated backup service via a third-party, something that many consider to be adequate. It's certainly a big improvement on what was the norm previously − typically a tape backup taken off-site physically, which often turned out to be unusable!
But even automated backups uploaded to a third-party data centre are not a complete answer to a disaster. An organisation's IT environment is much more than data − the average organisation will have a set of applications that are integral to the network of business processes on which it relies to do its business.
In other words, to provide a DR solution, one needs to be able to allow the business processes to flow as they would normally. To replicate this means first undertaking a rigorous analysis of how the various applications fit into the business and, critically, how reliant it is on each of them. This will help to determine the resources that need to be allocated to each application.
This highly-granular understanding of the nuts and bolts of the business, and what the dependencies are across the whole business process, IT and application networks on which it runs, is something most businesses do not have. Nor is it easy to obtain − one of the key value-adds the DRaaS supplier should be able to offer is expertise in this highly-specialised and essential task.
An important initial step is also to undertake an analysis of what the costs of the IT systems going down would be. Once one understands what the cost of each downtime hour actually is, it's much easier to make the business case for DR. I usually recommend people concentrate on the quantifiable costs, such as lost orders, undelivered product and staff costs, but one should also bear in mind the unquantifiable costs such as reputational damage.
This analysis should also consider multiple scenarios. For example, the disaster might be a fire or industrial action that would make it impossible for employees to work from their usual offices. It's thus critical that the DR arrangements will allow employees to work from anywhere.
Having understood why DR is so important for today's increasingly digitalised businesses, let's turn our attention to the benefits of DR-as-a-service, or DRaaS.
The first of these, naturally, is cost. Because no hardware needs to be purchased or a DR site set up and maintained, one is looking at major savings.
As important, DRaaS costs are better shaped. They are (or should be) a fixed monthly cost, easy to budget for and manage. In addition, and this is music to the CFO's ears, they are very much operational rather than capital expenses.
DRaaS is also easy for the CIO to manage and involves no onerous commitment to undertake regular testing to ensure the system is working.
Getting DR right isn't easy, but it's essential for any business for which downtime is costly. Obtaining it as a service makes it much more affordable and relatively quick to implement − but choosing the right vendor to work with is vital.
In my second article in this series, I want to broaden the discussion to look at how thinking about security must change in order to protect the modern organisation from cyber threats and avoid a disaster altogether.
Share