I’m no business continuity consultant, but I have had training in this area in past lives, and have some experience of what can go wrong. This blog is largely stimulated by attending an iland event. iland provides secure cloud services platforms and is a bit of a specialist in “Disaster Recovery as a Service” (DraaS).
I am aware, however, that I’m going to be accused of squashing two articles into one here, as you read on; but this is deliberate. I’m a strong believer in the idea that one always has to take a holistic view of governance and security – there is no point in admiring the strength of one’s castle gatehouse while the enemy is crawling up a latrine chute around the back that one has completely overlooked.
In other words, when thinking about any one aspect of security or governance and fixing one weak point, cast around for any different issues that will now emerge as new sources of contingency issues.
I’ve been following iland for some time and have a lot of respect for it. I believe its founders are still involved and it doesn’t rely on external funding, so it’s free to follow its own (long-term) vision of what is best for its customers. However, it is also firmly customer-led, which is probably why it is talking “disaster recovery” at the moment, rather than “business continuity”. Nevertheless, I believe that what customers really need, rather than what they are probably asking for, is Business Continuity planning, not Disaster Recovery planning. More on that later.
iland provides a secure enterprise cloud services platform for object storage, secure Cloud hosting, Cloud backup and Office 365 backup. Even more importantly, perhaps, it provides skills-transfer consultancy and has a good (supportive) channel. I’m impressed when I talk to its technical people.
Its newest thing is Catalyst, which seems to me to be a discovery tool on steroids for VMWare Cloud migrations. It lets iland (and, especially, its Channel) streamline the routine preparatory assurance work up front, freeing up skilled people to address any tricky issues that arise. And, it can help to quickly weed out customers that aren’t really suited to what iland offers.
Catalyst gives you assurance, that:
- Your application’s needs match with the Cloud resources available;
- iland’s cloud services are compatible with your workloads;
- You understand the bandwidth that will be needed to optimise the performance of your applications;
- You can reliably estimate both “per month” and “ad hoc” service costs;
- Your network resources are sufficient to support feasible backup, disaster recovery and migration use cases;
- You can adequately analyse your network, in order to estimate initial seed and ongoing data transfer times.
iland describes Catalyst as a “single universal tool”, which it sort-of is (it handles both Windows and Mac) – as long as you stay in the VMware space (so, not quite “universal” then). Nevertheless, according to Chris McDuffie (vice president of cloud architecture for Structured, a solution provider of secure, cloud-connected digital infrastructure in Clackamas, Ore.)
“When working with new customers and prospects, intelligence and insights are the top competitive differentiators, iland Catalyst gives us the ability to know exactly what resources our customers need to make their move to the cloud a success. With Catalyst we have the ability to get it right the first time around without over or under provisioning”
– which is the sort of thing that many of us need, or need access to.
This is not an InDetail review of Catalyst, but I do think Catalyst has interesting possibilities. It is not, however, a magic bullet that will fix all of your issues (it doesn’t handle all platforms, for example) – but iland is not claiming that it is, just that what it does do it does well.
Thinking about Catalyst has prompted other thoughts. For instance, about GDPR, mentioned in the Catalyst data sheet referenced above. Yes, one might want one’s service providers to have some form of “GDPR certification” (whatever that could mean – an article in itself) but if an organisation wants to claim any sort of real “GDPR compliance” it needs to design data privacy into its systems from the ground up and implement business processes that have privacy at their very core – and that’s not something one can outsource to a Cloud service provider (although a suitable “mentoring consultant” can help an organisation to achieve this).
Then there is the whole question of Business Continuity as opposed to Disaster Recovery, as I mentioned before. Yes, one does need Disaster Recovery planning (for when one’s offices are under five metres of floodwater, perhaps) but that is only part of maintaining Business Continuity as a whole – having the ability to carry on with doing business, and keeping customers happy, no matter what.
Many years ago, the bank I was working at got around to testing its Disaster Recovery procedures and recovered all of its databases and associated applications successfully, to a spare data centre a few miles down the road. Unfortunately, it couldn’t do any business there, because the village in which this data centre stood didn’t have the requisite number of phone lines for what the bank needed. I’d maintain that what really mattered here was not “disaster recovery”, but a tested ability to continue doing business – “business continuity” – no matter what happens.
My story is from many years ago, but I believe that many companies still focus on getting IT assets back after a disaster, not on continuing to do business. And there’s a risk management story here too, as protecting 100% against all contingencies will be infeasibly expensive and, ultimately, impossible. This means risk management; protecting and recovering non-IT assets; and remembering that a contingency short of actual disaster (nothing fails, for example, but everything runs slowly) can ruin the customer experience and put you out of business as surely as a data-centre fire. Moving stuff into the cloud hasn’t really altered this – even Cloud providers can fail or run slow.
Something that is often overlooked in the Business Continuity story, is the importance of Configuration Management (perhaps I’m biased, I’m on the committee of the British Computer Society Configuration Management Specialist Group). Configuration Management manages Configuration Items (CIs) and a CI is something – anything – essential to the delivery of a business service (and a CI needn’t be a computer asset). Even having sufficient toilets for your staff to be allowed to work in your offices post-contingency might be considered a Configuration Item (and might also be part of Business Continuity planning).
Surely management of Configuration Items should support Business Continuity planning? Configuration Management is about knowing what you have, where it is, how it is configured, who is responsible for it, what business systems it impacts, and how critical it is to the business. It is about relationships – if we lose this database (or this key person or this key document) what related business functions are impacted? That is exactly the sort of information that is needed to make an effective business continuity plan – heaven forfend that duplicate databases of such info are maintained separately (and inconsistently and expensively) by the Configuration Management Group and the Business Continuity Group. And another, related, point: Configuration Management information is maintained in a CMDB (Configuration Management Database). This should be a federated, logical, store of relevant information, not a single physical file. If Business Continuity information is relevant, to relationships perhaps, one needn’t copy it into the CMDB, the CMDB merely needs to point at it, to where it is being maintained.
This reminds me of another issue that is often overlooked, which is the testing of Business Continuity plans. If you don’t test them at the business delivery level (perhaps key information isn’t up-to-date), then you don’t really have a Business Continuity plan. But, testing Business Continuity plans on real data can result in a real disaster, if your plans fail. On the other hand, testing on generated data, or subsets of data, may not validate your responses to a real contingency, which have to take account of the possible unavailability of key people and even the tendency of people to make more mistakes when in a state of panic. Design of continuous low-risk, but still realistic, continuity testing is a huge issue, I think, something that iland say it would put its consultancy resources into.
All this is especially important for the Mutable Business, in a constant state of evolution. Such organisations need to move fast, but they also need to manage the risk associated with change, or they will soon become Mutable in name only. This means that they need more maturity and higher skill levels than old, staid companies. They need effective Business Continuity planning and “agile” Configuration Management, so that they can manage the scope of impact of changes – and failed changes – or contingencies effectively.
Given strong, well-engineered, systems and effective governance processes, a Mutable Business can cope with change better and take more risks than less mature and superficially more agile (or, rather, less well-governed) companies.