In-Depth
Building a Disaster Recovery Plan for Your SaaS Vendors
Here are four steps you need to take to ensure your data is safe and recoverable when you use a software-as-a-service provider.
by Joe Ruck
With the popularity of software as a service (SaaS), the software business is in flux. Now, traditional infrastructure players, who used to rule the roost, are up against tough new competition, as customers look for easier, more cost-effective solutions.
By going the SaaS route, customers are in a position slash infrastructure expenditures, shorten implementations, and deliver applications at a lower cost with less risk. The problem is that all too often, employees can get over-confident and make the mistake of short-circuiting necessary processes; for example, security standards or system reliability can be compromised. Above all, business users may not pay enough attention to questions of business continuity; instead, they may be naively relying on their SaaS vendor to just work well all the time.
SaaS is an easy way to deliver applications at a lower cost with less risk. However, some SaaS vendors have proposed cutting out IT completely, removing any need for the customer to think carefully about the issues of business continuity. Regardless of the SaaS vendor's reliability, a SaaS vendor is still a single point of commercial and perhaps legal control. Single points of control always have the capacity to become single points of failure.
For example, last year Google users were unable to access their Gmail accounts (see http://www.datacenterknowledge.com/archives/2008/08/11/gmail-service-outage). Although some could argue that this is a minor inconvenience, it exposes a company to failure if it relies on SaaS for a business-critical function. Can you imagine not having e-mail for hours -- even minutes? As more companies place more of their business data in the trust of SaaS providers, it's crucial to give serious consideration to a disaster recovery plan.
Certainly all responsible SaaS vendors work toward preventing downtime. Back-up data centers and redundant architectures are standard. Even so, you cannot predict the future, and it's naïve to take for granted a vendors' disaster recovery plan, since this assumes the vendor has made all the necessary investments. It also doesn't factor in natural and manmade disasters (i.e., acts of terrorism, stormy weather, etc.).
The good news is that creating a business continuity plan is not hard. A few simple steps go a long way to address this issue.
Step 1: Look at the Source
The first step is one you may have already taken, and that is to make sure that the SaaS vendors' own internal business continuity plans passes your litmus test. Business continuity is really independent of security, but is often tacked on the end of security questionnaires, and is covered by the IT security standard, ISO 17799. Your IT department will have the experience with this standard -- another reason why it makes sense to include (not exclude) the IT department when making SaaS buying decisions.
Step 2: Consider the Total Impact
The second step is to examine the impact of total loss of service. For each vital application, determine what you will do to continue operations if the application is impaired. For some applications, this may be as simple as "I won't do anything." As long as this represents a conscious choice, this can be adequate. An example of an application that might fall into this category is Web site analytics. For most companies, Web site traffic trends are shaped in weeks, so if your web traffic vendor is out of commission for just a few days, there may no meaningful business impact. If the outage goes longer than a few days, you should be in a position to migrate to another Web traffic monitoring system.
Step 3: Getting Your Data Back
The third element in your plan is data retrieval. You will certainly want all your original data back. Almost as certain: you won't be able to access that data easily when the time comes. This means making regular backups with a frequency appropriate to the business process, and storing those backups outside the control of the SaaS system they were taken from. This could certainly be another SaaS vendor. Lightning might strike once, but twice is unlikely.
For certain business processes you might not need backups, since the original content is created and managed in a distributed fashion; in other cases it's not so straightforward. In just about every case, it is possible. For example, with Salesforce.com, you may export your data as Excel spreadsheets, although given these are 'flat' representations of a complicated database structure, converting these to a format that could be used by an alternative system would not necessarily be straightforward – all the more reason to start planning how to do that now.
Step 4: Use It or Lose It
Finally, business continuity plans that aren't exercised are unlikely to perform when needed. A solid disaster recovery plan must be tested and exercised periodically -- at the very least, annually.
Some find it taboo to take a hard look at low-frequency/high-impact events -- a feeling that talking through the consequences is somehow bad karma. Certainly, this level of intellectual honesty is always uncomfortable, bus consider a worst-case scenario for such events. When they finally do hit, they are catastrophic. Nevertheless, people often retreat to the fuzzy comfort of, it'll never happen" and ignore the potentially devastating impact of the event.
I am bullish on the future of SaaS. Perhaps this to be expected coming from the CEO of a SaaS vendor. My own company uses SaaS vendors for most of our internal business functions, including marketing and customer relationship management. I see SaaS as having overwhelming advantages for most (but not all) companies and most (but not all) business areas.
Also, you do, of course, need to take these five steps for any internal systems. There is no disadvantage in using SaaS compared to internal systems when it comes to business continuity. Indeed, the rapid implementation and deployment of SaaS applications can actually make them a useful backup to more customized on-premise solutions. The reality is that continuity can't be ignored regardless of your IT deployment model.
Joe Ruck is the president and CEO of BoardVantage. Prior to joining BoardVantage, he was senior vice president of marketing at Interwoven and has held sales, marketing, and executive positions at Sun Microsystems, Network Appliance, and Genesys Telecommunications (since acquired by Alcatel). Joe holds a BS degree in engineering from Oregon State University and an MBA from Santa Clara University. You can contact the author at jruck@boardvantage.com.