A few weeks ago, someone asked me what worried me the most about being a CIO in today's environment. I thought
about the question for a few moments. I pondered the depth, breadth and complexity of my project portfolio. I mentally reviewed my staffing challenges. I considered my own shortcomings. But those all paled in comparison to the one thing that I worry about the most -- not being fast enough.
Technologies change business rules. Technologies drive innovation. And we, in our IT leadership roles, must handle these changes while also delivering excellence in managing everything else in our technology products and services stacks. We have to be really good at mobile, social, analytics, collaboration, consumerization, et cetera while also making sure that we don't let ourselves get bad at network, CRM, ERP, desktop management, service level management, et cetera. And, we somehow have to do all of this faster than ever, lest we slow down the organization by becoming bottlenecks.
Niel Nickolaisen CIO, Western Governors University
In my efforts to deal with my big worry about not being fast enough, I have to look at a range of approaches including simplification, automation and off-loading as much as possible to someone else (as long as that someone else is better at the activity than I am). What does this have to do with disaster recovery and business continuity (DR/BC)?
First of all, virtualization is the gift that just keeps on giving (last week, I told someone that virtualization is the one thing that has really transformed IT operations). We have virtualized all of our systems and storage and this has simplified our DR/BC. Using available tools and the scripting capabilities of virtualization, we can identify the most critical systems and data and shift around and recover in near real-time. Virtualization also makes our DR/BC portable -- the location of our hot, warm or cold site is irrelevant as long as it is available. This results in incredible flexibility including the ability to use someone else's cloud services as my DR/BC site (more on that in a few seconds). How does this help me speed up IT? What used to take lots of time and money -- implementing a DR/BC plan -- now takes a lot less time and money.
More on disaster recovery strategies
Second, one of the historical barriers to the actual deployment of a DR/BC plan was the cost of the replicated hardware. As long as we are careful about prioritizing what deserves redundancy and recovery -- and many systems don't deserve DR/BC -- (in my case, I can survive quite a while without a recovered document management system but can't last more than about 5 minutes without email), we can use someone else's hardware by doing DR/BC via a cloud service. Of course, this depends on the reliability of the cloud service, but it just might have to be better at that than I am.
Of course, the availability of cloud services can also be something of a pain. I have a couple of departments that decided to pursue their own backup and recovery services by purchasing a less-than-secure and less-than-adequate cloud service. A radio advertisement and credit card was all it took for them to sign up for what they thought would be a great solution to their backup needs. That was until one of the departments had to actually recover a document that was lost. It turned out that their cloud service was not as good at recovery as we are.
This experience taught all of us a lesson. Those departments learned to check with us first, and I learned never to give my customers a reason to not use me, which reinforced my biggest fear. What is that fear? That I am not fast enough.