Service Escrow

A small SaaS company bites the dust, reports Gianpaolo Carraro, Director of SaaS Architecture at Microsoft.


Obviously this is not just an SaaS problem. Companies fold all the time. If you are dependent on some external capability, you'd better have a plan for business continuity. And if you have entrusted your supplier with important assets (e.g. data) you'd better be able to get your assets back quick.

A pessimist might regard this risk as a reason to avoid SaaS altogether. But I don't think Microsoft employs many pessimists. For his part Gianpaolo sees this risk as an opportunity for some enterprising SaaS undertaker - selling services to those whose beloved supplier has gone to the great SaaS graveyard.

I prefer to see this as an architectural challenge:

• How can we design a robust network of services, one not affected by a single point of failure? (This is of course a classic problem of distributed systems.)
• Are there patterns of collaborative networks that will stand up to the loss of any single organization in the network?
• What are the appropriate SLAs to support these patterns?
• And what are the interoperability requirements to make this work?

Structural problems call for structural solutions. That's what architects are for.

Update

Gianpaolo's initial response here: SaaS Undertaker (April 2007). Shortly after my exchange with Gianpaolo, a company called Iron Mountain launched an escrow service. See my post Service Escrow - Iron Mountain (May 2007).