Service Escrow - Iron Mountain

Last month I riffed with Gianpaulo 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)

Gianpaulo (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 Gianpaulo 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.

The Bits Stop Here

One of the drivers for SOA, both commercial and public sector, is to extend and enrich the opportunities to provide services to customers/citizens over the internet.

But the more reliance we place on electronic identity, the more important it seems to be to link this back to some face-to-face identification by a trusted authority. And these processes are getting more tedious. Perhaps rightly so, as identity theft becomes ever easier and more prevalent.

For example, before I could open a savings account for my son recently, I needed a lengthy interview with a bank clerk, who apparently needed to take photocopies of my passport and utility bills. This routine is called 'Know Your Customer'.

[Wikipedia: Know Your Customer]

It's not good enough for the bank clerk merely to see these documents. A paper archive is needed for "compliance" - in other words, providing retrospective evidence that I haven't tricked or bribed the bank clerk to overlook some missing document. Is this because the bank doesn't entirely trust its own employees?

But the bank does trust the paperwork from other organizations with which it has (as far as I know) zero electronic interoperability (the passport authority and the utility companies). That's nice.

Until recently, UK citizens have been able to apply for passports remotely, but the Identity and Passport Service is going to introduce face-to-face interviews. At which I guess we are going to produce copies of bank statements and utility bills.

[BBC News: Interviews for passports 'vital', Robin Wilton: Face-to-face interviews for passport candidates, Tomorrow's Fish-and-Chip Paper: And talking of the Identity and Passport Service ...]

Meanwhile, the utility companies are trying to back out of this role in the network of trust, by producing electronic bills instead of paper ones. These are useless for identification purposes, because they can be too easily forged by amateurs. (Forging old fashioned utility bills does require a tiny amount of expertise.)

So there seem to be some infinite loops in the network of trust, with some pretty obvious vulnerabilities yielding countless opportunities for real crooks.

I was minded of this when I saw the problems faced by Tim Bray getting a new Canadian passport. Spent nine hours waiting in line.

[Tim Bray: Passport Hell, Emerging Chaos: How Long to Be Identified]

Maybe electronic identity (complete with biometrics and RFID) is going to save you a little time for each transaction, but if it takes that long to get/issue the credentials in the first place, then there is some catching up to do.

As it happens, there are some pretty bright people in the IT industry working on exactly this problem, and some pretty neat solutions emerging. But the managers and politicians running the organizations that actually handle identity on a daily basis (leaving sackloads of unshredded personal data on the sidewalk, losing laptops on a regular basis, that kind of thing) don't seem to have a clue about this, don't seem to realise that they are just making things worse.

Like I said, there is some catching up to do. SOA (with Identity 2.0) has the potential to solve a lot of problems, but the first step is for the people who are causing the problems in the first place to acknowledge that they need help.

Otherwise all these cool solutions will just remain interesting talking points for bloggers.