After you go through all the effort of assessing the reliability of a SaaS (software as a service) provider, do you need to implement your own data backups too? This is a question that I’ve pondered about more than once. Isn’t one of the principle value propositions of SaaS the fact that all the worries about administrative task like backups have been outsourced?
The brutal reality is that IT organizations are still on the hook to provide mission critical data to the business, whether the SaaS provider has failed to deliver, or whatever the reason. The challenge is identifying what is mission critical data, and then, what level of risk it is exposed to, and finally, how quickly will the business need access to it when there’s an issue.
What is mission critical data? Practically speaking, some critical attributes are: system of record and operationally critical. Data can have either attribute or in some cases, both. Examples:
- System of Record: Last month’s sales receipts.
- Operationally Critical: Urgent customer support tickets.
Although last month’s sales receipts are very important data, critical for financial reporting and needs to be preserved for years, if the system that stores this information goes offline, chances are that business can survive for a 48 hour period without access to this information. In contrast, an urgent support ticket is information that is needed immediately. There may be Service Level Agreement at stake. What do you do if your SaaS provider tells you that access to this information won’t be possible for a couple of days. What do you tell the business?
We have made the decision to back up both types of our data nightly to our own corporate databases. Great SaaS vendors make it easy to access this data… it’s OUR data. But if the worst happens, we will be able to create ad hoc reports to satisfy immediate needs.
If you have engaged a quality SaaS provider it’s unlikely they would be off the air for more than 12-24 hours. And failures like that shouldn’t occur often. Make sure you ask about Recovery Time Objectives for disaster recovery when you are shopping for SaaS services. Your prospective SaaS provider should be prepared with an answer!
TrackBack
• Digg This
• Add to del.icio.us
Posted in On-demand (SaaS)
You can leave a response, or trackback from your own site.
hi Rob,
Interesting post, thanks for sharing your thoughts.
It strikes me that this shows the immaturely of SAAS. This is really about trust right? If you trusted your vendor with your data, if you trusted them to response in line with your SLA (lets assume that the SLA are set up to support the buss. in the right way – a big assumption I know!) then there really is not case for doing you own back ups.
This is a case of better save than sorry really, and probably also because the IT function and the business still see the IT function as responsible for the system.
I reckon that as SAAS become better understood by everyone involved this need to back up your own data will become less of a issue.
Thanks
Ross
Interesting discussion point.
Not being in complete control of data is a reason some businesses won’t proceed with SaaS. Although some definitions here about SaaS and Cloud computing help i.e. look at who provides the comms, the hardware and then the software. There can be multiple parties involved.
This type of arrangement has been going on for years in IT. How the companies view the proposition can depend on their attitude to risk and how to manage it.
One more thought on backing up your data that’s hosted in the cloud: The recent security fiasco at Sony Entertainment Systems demonstrates that a security breach has the unfortunate potential to take a cloud provider offline. This is not to say that their cloud is unavailable forever… but what impact would there be on your business if your CRM system was offline for a week or two? And, unfortunately I believe that all high profile cloud providers are hacker targets. As a cloud customer, you need to satisfy yourself that your provider has their security act together by insisting on proof that their service is secure. How is it being tested, and how often? Keep them honest!