There is an old joke in sales that things would be great if it wasn’t for the customers. Of course, it is the customers that buy and that keep salespeople in a job. More generally, people accomplish tasks, do projects, have ideas and help to run businesses. Business continuity is inextricably bound up with people. They may be unpredictable as individuals, but display rather more predictable behaviour when grouped together. Predictive analytics has already been growing as a method of forecasting market conditions, economic trends and environmental developments. Increasingly, these techniques are also being applied in cases where people have a direct impact on business continuity.
Information technology has certain features that make it possible to calculate probable dates of demise. It’s all digital, with a finite number of bits and bytes, and calculable error rates. As disk storage capacities increase, technologies viable today may run out of steam tomorrow. They cannot scale forever. Unlike vinyl records in the music industry or Polaroid cameras (a bit of cheat) that were written off, but then experienced resurgence in their markets, when a disk drive is dead, it’s dead. Here is the thinking behind the disturbingly precise estimate that by 2019, RAID 6 drives should no longer be part of the IT landscape or the disaster recovery scene.
Concepts and fashions in business come and go. And sometimes they come back again with a new look or a different name. The origin of the DevOps name is simple to guess. It’s a combination of development and operations. The advantages cited of using a DevOps approach include a lower failure rate of software releases, a faster time to fix, and a faster time to recover if a new release crashes your server. DevOps is currently a buzzword in IT circles, but despite an inception date of 2008, just how new is it?
If the title of this post makes you go cross-eyed, don’t worry. All will become clear. Let’s explain. Active/active IT configurations consist of computer servers that are connected in a network and that share a common database. The ‘active/active’ part refers to the capability to handle server failure. First, if one server fails, it does not affect the other servers. Second, users on a server that fails are then rapidly switched to another server that works. The database that the servers use is also replicated so that there is always one copy available. Now for the other two acronyms: HA stands for high availability; DR (of course) for disaster recovery. It is DR that is more affected in this case.
First there was the dedicated, physical server. Then came virtualisation to help organisations mix and match over different servers on their sites. After that came cloud computing with more virtualisation (and multi-tenancy thrown in). However, organisations typically still did their virtualisation between machines in close physical proximity, even if they were using cloud services. Now the next step is to see how well virtual machines and their data can be transferred between racks of machines not just separated by a few feet, but by hundreds of miles – or at least far enough to be out of range of the next tsunami.
How often have you heard the expression ‘no pain, no gain’? These four words sum up the idea that if you are to receive benefits, then you must suffer (or at least make an effort). Alternatively, you could take it to mean that if you don’t make an effort, you can’t expect benefits. An example in the domain of disaster recovery might be ‘if you skip regular data backups (no effort), you’ll fail when your hard disk crashes (no benefit)’. The problem comes when people use chop logic to infer from ‘no pain, no gain’ that ‘if pain, then gain’ is true as well.
Think you know it all when it comes to business continuity? That’s great. Think you can store all that knowledge? Think again. The way most information technology has developed, it’s great for storing information (bunches of related data), but not so hot for knowledge (insights and deeper relationships). There is no shortage of information to define business continuity, list its component parts, describe planning methodologies and offer case studies. You can access that information, transfer it and store it on your PC or mobile computing device. The problem is in storing your understanding of that material, and the model you develop to see them as a connected whole.
Tape data storage just keeps on going. It’s almost like the steam punk of IT, a branch off into a different universe where everybody reads with bigger candles instead electric light bulbs. But it works. In fact, it works well enough for the largest IT vendors to continue pushing the envelope on data storage density on tape and storage and recovery speeds too. However, tape is not disk. You cannot ‘dip into’ tape in the same way you can randomly access a hard drive. And so, for backup and recovery in particular, the virtual tape library was invented to offer advantages of tape and disk altogether. Nevertheless, there are both pros and cons to consider.
Where are the weak points in your organisation and its operations? Where could disasters or criminals do the most damage? Vulnerability testing, as its name suggests, is done to find out where the soft underbelly is. Then protection and security can be suitably reinforced. In a general sense, it can cover everything: from freak weather conditions to power outages, supplier failure and IT disasters. Indeed, the latter category of IT is where vulnerability testing is often the most performed. This is partly because of the critical role of IT throughout many organisations, and partly because IT vulnerability testing is relatively easy to automate. However, even systematic automated testing can’t do it all. So what’s the solution?
As a business continuity manager, CIO or company risk office, you’ve probably already done numerous risk value calculations. In order to make a table to compare risks and their impacts, you might assign percentages or relative scores to risks, and monetary values or relative scores again to impacts. The risk value in each case is then simply “risk X impact”. You get a simple table that allows you to rank risks in order of their risk value and set your priorities accordingly. However, what may be forgotten is that risk calculations can be positive as well as negative.
Disaster recovery planning for your IT installations may use automated procedures for a number of situations. Virtual machines can often be switched or re-started in case of server failure, and network communications can be rerouted without human intervention. For other requirements, people will be involved in getting IT systems up and running properly after an incident. But people do not switch into auto-run modes like a machine. They can be affected by the surprise factor of an IT disaster and by the pressure to bring things back to normal. Five aspects of usability may need to be designed into your DR planning if you want the best chances of a satisfactory recovery.
Forgot your password? Call in-house IT support. They’ll ask you a couple of questions to verify your identity (maybe your date of birth, your favourite colour). Then they’ll reset your password and tell you what it is so that you can go and do that work that’s been piling up. Or so that you can break into that user’s account and from there into more databases and servers – because you weren’t a panicked user at all, but a hacker successfully masquerading as one. What’s the answer to this IT security risk? Harder questions? Passwords that are easier to remember? Or simply taking something out of the equation that shouldn’t have been in there in the first place?
Picture this. A main water pipe bursts and water begins to flood the warehouse, which is also where you happen to be, smartphone in pocket. To avert serious damage and downtime, you need to find the cut-off valve – quickly. At this point, two scenarios are possible. First scenario: you try to find out who can help by calling reception and trying to note the names they suggest and the phone numbers. Second scenario: you access a directory of resources directly from your smartphone, call the person concerned and turn the call into a video call from that person’s desktop so that you can be remotely guided to where the cut-off valve is and how to shut it. How do you get from scenario one to scenario two?
No, there is no typo in the title. In today’s C-level world, CRO can stand for Chief Risk Officer, but can also mean Chief Reputation Officer. By definition, the Chief Risk Officer looks after the governance of significant risks (both menaces and opportunities). The Chief Reputation Officer supervises the management of an organisation’s reputation, brand and communications. Looking after risks and reputation are both vital functions for organisations. The question is whether specific job functions are to be created for one or both of them. The definitive answer will depend on different factors.