Service Escrow - Iron Mountain

Last month I riffed with Gianpaolo Carraro about Service Escrow. A few days later, a company called Iron Mountain launched an SaaS escrow service, covering the source code, system documentation and data.

• Iron Mountain press release
• Link to ThinkStrategies white paper (written by Jeff Kaplan, commissioned by Iron Mountain)

Gianpaolo (who is one of Microsoft's SaaS experts) refers to companies providing this service as SaaS undertakers. But it might be better to call them SaaS support. By acting as a safety net for SaaS providers and their customers, they may reduce the risk associated with SaaS and contribute indirectly to SaaS market growth.

I phoned Iron Mountain to find out more about their SaaS Escrow service, and the extent to which it differed from the traditional software escrow service. Here are some of the main points of our conversation.

Storage Model

Iron Mountain stores both the software (source code, object code and documentation - all of which belongs to the SaaS provider) and the data (which belongs to the SaaS user). Whereas traditional software escrow can often operate on a fairly slow cycle, with new software versions deposited in a fairly leisurely manner, SaaS escrow generally calls for live data backup.

If the escrow conditions are triggered, Iron Mountain will release the software and data to the SaaS user. To avoid any perceived conflict of interest, Iron Mountain does not operate the software - even on an emergency basis. But this means that the SaaS developers (or some appointed third party) must install and test the software on a new server, load and test the data, and then restore the service.

This is probably not something that can or should be done overnight - so it is not going to provide much protection against a sudden and unexpected failure of a business critical service. A more likely scenario is a gradual worsening of the relationship between the SaaS provider and the SaaS user, and a growing dissatisfaction with service levels and support arrangements, approaching the point where the SaaS provider is in breach of contract. SaaS escrow means that the SaaS user has a reasonable exit from an unsatisfactory relationship, and cannot be held to ransom because the SaaS provider controls a key business asset.

The economic benefits of escrow therefore fall under the economics of governance - making sure the SaaS user has proper control of the relationship.

Charging Model

Although the SaaS provider may benefit from the existence of SaaS escrow, the prime beneficiary is the SaaS user. Historically, it has always been the user who has negotiated and paid for escrow. However, Iron Mountain is increasingly seeing more complex arrangements whereby the software provider pays for the escrow and passes these charges onto the sofware user.

In the case of SaaS escrow, a typical arrangement would be that the SaaS provider pays for the deposit of the software, while the SaaS user pays for the deposit of the data (depending on the data volumes).

It is in the interests of the SaaS user that Iron Mountain always holds the latest version of the software. Iron Mountain therefore encourages the SaaS provider to deposit software upgrades as frequently as necessary - preferably online - and does not charge on the basis of frequency. (Remember that SaaS software may undergo a faster improvement cycle than traditional software packages.)

Management Process

SaaS escrow only works if the SaaS provider has adequate software configuration management and data management, so that it becomes a matter of routine to send controlled copies to Iron Mountain. There is a certain amount of ongoing verification and audit that needs to be carried out, involving all the parties to the escrow arrangement, and Iron Mountain sees this as an important aspect of its own role.

Remember that the SaaS user does not see the software unless and until the escrow conditions are triggered - so it isn't possible to test the escrow arrangements in a trial run exercise. Instead, it is necessary to test the process at a higher level of abstraction, to provide some reassurance to the SaaS user that the escrow would work adequately.

Future

This is early days for the SaaS escrow market, and I shall be interested to see how the market develops ...

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).

Controlling Content

Some discussion from DevHawk and Scoble around owning/renting music. 

One problem I experience around rental is the anxiety of non-ownership. 

• What if the content provider wants to charge a much higher rental for my favourite content?
  

• Do I have to pay content providers whenever I upgrade media?
  

• What if the content provider restricts the media on which this content is available? (For example, forcing me to use a more expensive or less flexible format.)
  

• What if the content provider forces me to upgrade to a new version when I prefer the old version? (For example, I understand that Mike Oldfield regrets the haste with which the original version of Tubular Bells was produced, and would probably prefer us all to listen to the new perfectly engineered version. For my part, I prefer the original version.)
  

Scoble comments that most music isn't worth owning. Of course that's true. Some people like to listen to the same rubbish over and over, while others prefer a constant stream of new material (within a predefined genre). There are loads of radio stations that can satisfy both sets of people. (See my previous post on Shuffle). 

Of course, these risks don't only apply to music. I have lost track of several large repositories of useful material on the Internet. Have they been renamed/relocated, merged into something else, disappeared behind a subscription barrier, or taken down altogether? Perhaps I should have kept copies of some of the papers? 

Conversely, there is some content I'd prefer not to manage. Lots of fiction isn't worth reading more than once, so why do I keep so many novels? 

These are important questions in a service economy - the control and governance of the service and its content. Service dependencies in business dependencies; so service reliability/durability has an important bearing upon business risk. In some contexts, we may need some kind of service/content escrow to protect the consumer. 

Trusting Services

If there is only one implementation of a service then trusting the service entails trusting the implementation entails trusting the supplier. Furthermore, if there is only one channel to access this implementation, then this also entails trusting all intermediaries.

Typically this is done by having a large trusted supplier with a reputable brand. IBM or EDS. Large suppliers have a valuable brand image to maintain, and therefore may be supposed to have too much at stake to allow any service to fail.

We can break into this loop in three places. Firstly, we may note the ability of some firms to decouple appearance from reality. Reputation is affected not by real failure but by the perception of failure.

Secondly, we may be able to decouple the implementation from the supplier, through some kind of guaranteed escrow. If the supplier cannot deliver the service with the specified level of quality, then we or someone else will immediately take over the implementation (together with all resources required, such as persistent data). We should expect the web service platforms to support this.

More importantly, we should be able to decouple the service from a single implementation. It might be stupid to rely on a business critical service if there is only one small supplier. But if there are lots of interchangeable suppliers offering equivalent services, the disappearance of
one supplier doesn't matter very much.

Thus web services allows us to shift from trusting a single source to trusting multiple sources (market or ecosystem). Without this step, the service-based business contains many dependencies, and the business process may seem critically vulnerable.

The process implications of this are twofold. Firstly, the SOA process should include some consideration of the appropriate number/diversity of implementations of a given process - and should certainly not assume that the design task is always to select a single best-possible implementation. Secondly, the enterprise model of an SOA solution should allow some visibility and management of the true dependencies and consequent risk involved, since multiple independent implementations of a given service will generally be expected to increase the overall availability and reduce the overall risk.


Updated 11 December 2013