What are good ways to guarantee business continuity with a SaaS product?

For my Bachelor Thesis I am researching how SaaS providers can arrange some sort of business continuity guarantee.

You probably know the Source Code Escrow arrangements for 'shrink-wrapped' software. They give 开发者_开发问答customers access to the source code and all applicable documentation whenever the software supplier gets into (financial) trouble. This clearly does not work for SaaS, because customers have no use for just the source code, and customers probably can not afford not being able to login to their CRM system for a couple weeks because the SaaS provider went bankrupt. I am currently researching different methods to solve this problem.

Do you know good and practical solutions to solve this continuity problem? Or companies that already offer a good solution?

Thanks!

I think you need to distinguish two cases:

1. A SaaS supplier is supplying a quasi-generic service. It's conceivable the data could be transferred to an alternative supplier, and a supplier could promise to make the data available in a form that could be used by that supplier.
2. A SaaS supplier supplying a unique service. There is no practical alternative to the supplier other than creating your own data center. By the time you have done this, you may no longer be in business.

The question you ask normally comes up in the context of a company considering using SaaS services. In these cases a prudent company (as part of its business continuity plan) needs to (a) assure itself of the financial viability of the supplier (interesting that most people answering this question see this as the main risk), and (b) assure itself that the supplier has an adequate business continuity plan which will assure services in the event of all major risks. (For example, if a data center has a fire and has to be shut down temporarily, is there an alternate. Is it on hot standby? Is data duplicated? How much data could be lost? Can network traffic be re-routed? etc.)

Of course, the customer also has to worry about network connectivity issues: the supplier may be in business but unreachable. And (in cross-border cases), political and regulatory risks.

The concerns for a SaaS supplier are in fact not that different from any other provider of outsourced critical services or products. (If you have assemble custom flanges and custom grommets to produce widgets, you will be in trouble if your supplier can't supply you with your flanges for whatever reason.)

Interestingly a concern for a SaaS supplier with a few large customers is the financial viability and business continuity of its customers. Failure of a major retailer sometimes results in the failure of its suppliers: not only are the suppliers left with large unsecured debts, they are left lacking a major part of their distribution chain.

Jan Husdal writes an interesting blog on issues of supply chain business continuity, although I don't think he has covered SaaS issues specifically.

One indicator to watch for the future may be the requirement for a supplier to have a business continuity plan audited to a recognized standard (e.g. BS-25999). It may be that we will see business continuity standards propagating in the way that ISO-9000 standards propagated as each company pushes back certification requirements to its critical suppliers.

Good luck with your thesis. You've chosen an interesting topic. You might also want to ask your question in the Disaster Recovery Journal group on LinkedIn. It's the only really active discussion area on Business Continuity Issues I've found.

Service availability is always something to consider when outsourcing anything at all, be it development, catering, or hosting (what would you do if you run a factory and your catering provider goes bust, leaving your company restaurant with no staff?).

In the case of software, code escrow is a step to ensure minimum disruption (even if there will of course always be some disruption).

Having a contract with a backup hosting provider where the application is deployed on cold standby with regular database synchronisation can sometimes be an option. For applications that require high uptime (which I assume is the case here as you state you can accept even a few days downtime) that's a necessity anyway. After all, the SAAS provider might not go bankrupt but if an aircraft crashes on the building hosting their serverfarm your application is going to be disrupted too (I've worked for a SAAS provider, and we had our own backup server farms in several locations to ensure continuity of service, plus regular code dumps sent to an escrow service and sent off to storage in a secure location to have off-site backups, no reason why a customer shouldn't want to have their own cold backup as well, or at least a contract option to take over the hosting contract in case of disruption of service due to bankruptcy of the current contract holder).

As a small SaaS provider, we are frequently asked this question by prospective clients. We addressed it by making our product open source. This may not be an option suitable to many but was the best for us.

Well we do SaaS but I'm not sure management has though about continuity. I believe the most common state of affairs is that an SaaS provider limits his services and liabilities per contract so that they don't even have to think about it.

As a possible solution: company may agree per contract to provide some amount of effort to migrate the data to an alternative software system of customer choice in case it shut down its operation. Short of that, there is hardly anything to expect.

As a very bald option: give the database backup to the client who will employ consultants or make bits and pieces out of it. But it's rather an emergency case.

I suppose you could always design your system so that in case your company is about to go under, you could provide customers with enough server-side software, config files, and data that they could host their own version of your service. Essentially, give/sell them an image of your system for them to host (either internally or pay someone else to) long enough to move to a new system. If you run all your server-side software inside a virtual machine, this may make it easier to (in essence) give the customer your server. You may even be able to arrange for the VM image to be transferred directly to a third-party hosting provider (and pre-pay for enough time to fulfill the remainder of the customer's current contract) if your company is about to shut down.

As a customer of SaaS I highly depend on services such as invoicing, e-mail, and software bug tracking. Until answering this question I hadn't given it much thought: I can quit the contract anytime, why can't they? On the other hand: my data needs to be secured. I have asked my suppliers (not expecting an answer soon from gmail :-) and in the mean time taken measures to frequently back-up.

Scary: none of my providers actually explain what happens in detail in their terms of service. Where should I expect such information? Where would a developer place such text?

With regards to this problem, a possible way to handle it is to realize that while I have business with company X for a piece of software, it's my data that resides in that software's data store. Ergo, I should be provided with a copy of it (in XML, or whatever format agreed upon). That way, if the company should go out of business, I simply need the latest copy of my data, and I can take it elsewhere.

Having worked in the SaaS industry, I know that a lot of companies have different ways of saving user data -- but they also are aware of their competitors and want to make it easy for companies to bring data to them to load.

Good question. At a SaaS company I worked for, I was on a team that developed a suite of tools for internal use by the hosting team to rapidly deploy a customer installation. Deploying a customer was a complicated procedure involving test/production sites with 7-10 servers each. We also had procedures in place to take nightly backups of customer data.

I suppose the tools we developed for internal use could have been productized for the purpose you describe, and these tools along with the customer's data could allow them to take over the product. The toolset was flexible enough to allow the customer to redeploy their data on a different server configuration. For example, in an emergency they could deploy an app that had been running on 8 servers into a 2 server configuration, and once they had their data center set up, redeploy again to the more performant 8 server configuration.