SAS, Outsourcing and Business Risk

Update:  This post has nothing to do with these guys.

I have long been a fan of outsourcing (not necessarily offshoring, which is a different animal).  Take the stuff that's not the core of your business and move it off to those who are experts in it.  I think it gets even better when that service can come through a nifty lightweight web 2.0 interface.  In other word, Software As a Service (SAS) UPDATE: Sorry - this should actually have been abbreviated "SaaS". Acronym fixed in the rest of this post.

So, along those lines, we here at Ai use a number of web-based outsourcing services to handle our non-core activities.  We use BaseCamp as a collaborative project management tool, and Harvest for time tracking, to name a few.  These decisions are cost-effective for us, because we're not in the collaborative project management tool business, nor the time tracking tool business.  We build websites for clients.

There's a catch, however (you knew the catch was coming, didn't you?).   There is a question of risk for each business function that is outsourced to a SaaS.  This risk can be difficult to quantify, so it can be a bit much for the more risk-averse business people.

SaaS-related business risk generally falls into two categories:

• Availability:  How often does the SaaS go down, and become unavailable to its clients?  Depending on the level that business depends on the SAS, lack of availability can have a serious business cost, usually taking the form of paralyzing the business in some way.
• Data Loss:  Much worse than availability, when mission critical data is put into an SaaS, data loss can be deadly.  Data loss can kill a business.  Dead.  A less deathly, but still damaging variant on this is vendor lock-in, where there's no expedient way  to leave the SaaS, because all of the business' data  is in the SaaS system, with no way to export it. 

Am I being hyper-cautious?  Are these risks just hypothetical?  Well, in the last week BaseCamp (actually all of the 37 Signals apps) went down because of a bad router.  There was no backup router in the rack, apparently, meaning that the entire suite of SaaS apps from 37 Signals had a single point of failure which, well, failed.  For all of Friday morning, no one derived any benefit from BaseCamp.

Last week Twitter (admittedly not the first thing one thinks of for business-facing SaaS, but still...) died unceremoniously during the Steve Jobs Macworld keynote.  Too many Apple fans live-blogging for Twitter to stand, apparently.

These risks slow SaaS adoption.  In order to make the leap across the chasm from early adopter types to the majority, SaaS providers must find a way to mitigate these risks.  This kind of thing  will be tolerated by a certain breed of early adaptors, but the more  conservative majority need more assurances.

Hello, SaaS providers - I'm talking to you now:

1. Service Level Agreements for SaaS:  How about an uptime guarantee.  That is typically followed by an investment by the provider in the technical infrastructure to provide the agreed upon service level.  Like backup routers.
2. Data backup and export:  Some assurance that a) our data is safe and b) we can get it away from you would go a long way to mitigating fears of certain business death in the event of a technical failure of an SaaS, or should we decide that we want to switch to another SaaS.

Now I'm not asking for regulation or anyone to pass a law or anything.  But it would be nice to have a certifying body out there somewhere for this kind of thing - a "Hacker Safe" for mitigating SaaS business risk.  That would provide businesses the assurance they need, and allow SaaS to fully cross over into the mainstream.