I got an email the other day from Escrow Associates, a provider of software escrow services that has just today announced the release of their SaaS software escrow agreement. For those not accustomed to escrow services, they are a contract where by the IP of a product is held by a third party and is released to the counter party in the contract if the owner of the IP goes out of business or cancels the product – in other words they guarantee ownership of data – be it user data, application data or integration data.
From their press release, Escrow Associates explains their SaaS escrow services by saying;
Access to data is the primary difference between SaaS and traditional source code escrow solutions. Historically, an end user had possession of their data and could find another application if their software vendor failed. With SaaS, the data is often hosted offsite, and is inaccessible if the vendor fails. Escrow Associates’ SaaS escrow agreement, however, provides for the data to be deposited and updated, so that the application and data are always available for release. This allows businesses to resume their vital operations quickly.
While not overly exciting, SaaS escrow services are becoming ever more important. Recently I posted about a new third party application providing granular user permissioning for a particular SaaS accounting application. My post caused something of a storm, the net result of which was users and influencers of SaaS accounting software balking at the fear of data loss and lack of security for the core application.
Others have noted escrow services as being valuable in the event that a vendor goes under, providing,as they do, certainty over data ownership. However there is a bigger issues with the ability of escrow services to cover the IP of a third party application and therefore give ongoing certainty around the functionality of a third party integration. As Escrow Associate points out;
Some agents make the process even simpler by ensuring the integrity and currency of the source code with software escrow verification services. In a SaaS environment, these testing services can also recreate the hosting environment and provide access for end user testing. These services protect both providers and subscribers, because they know that the escrow account contains useable code.
So the way I see it, escrow services can remove the issues people have around SaaS and third party integrations. Unfortunately what they can’t do is provide a foil to all the FUD being generated about it… oh well.
Update: Further discussion by Frank Scavo - the comments to his posts are worth reading, too.
Ben, this seems a great way to increase confidence around accessibility of SaaS data in the event of the vendor failing. However, with an unprecedented collection of SaaS customer data respositories, hosted in one place, multiplied by x SaaS products, probably with medium-high value to a disreputable party, security of the escrow repository itself would be at the top of my mind.
Pete - fair comment... escrow services backed by security assessment and accreditation?
Ben, Just like SaaS vendors need to drop the baggage of the legacy software model to fully benefit from the SaaS Business Architecture, so too must Business Continuity providers if they wish to attract SaaS vendors and their clients. Legacy business continuity methods, including escrow and "data vaults" are a relic of the legacy software business. The value proposition of source code escrow, if the vendor goes away or otherwise violates some SLA (the "trigger event") then the client gets access to the source code and can run and modify the software themselves, fundamentally violates key elements of the SaaS value proposition. If I am leveraging a SaaS vendor, one of the things I am probably interested in (not always, but often) is that I don't have to runt he application myself. What these legacy methods of business continuity give me is assurance that when something goes wrong, everything falls back into my lap. No thank you. The big problem is that just as in the SaaS world, where vendors use virtualized desktop, single-instance apps spun up on a VM (ASP 2.0?), etc. to "SaaS-ify" legacy apps, we have legacy business continuity vendors doing the same thing. Some vendors bundle their escrow service with online data backups and call it "SaaS Escrow" or something crazy. Regardless of how well they handle multi-tenant systems (I want app-level meta data and just my tenant data, please?), the reality is that I don't want the raw data and source code. In most cases, I want Application Continuity which leads to the continuity of my business. (Remember: Business Continuity refers to the clients of the vendor, not the vendor) There are some vendors in the source code management and escrow space who are starting to move in the right direction. Chaperon, for example, has a real-time service they sell to legacy escrow companies that ensures the source code in the vault that is protected by the escrow agreement is up to date by hooking directly into SVN, git, etc. repositories. Chaperon basically allows escrow companies to come into the "agile" world. But at the end of the day, the "escrow model" is a non-starter in the SaaS world. OpSource and Servoy (announcement should be made in a week or two) both have interesting approaches to application continuity. I don't know all of the particulars, but they will essentially keep the application running if the vendor goes away or otherwise defaults on payment. Whether this is for long-term continuity or just to enable clients a controlled off-boarding, it is more aligned with the expectations of the SaaS clients (which is who we are here to serve, right?). Again, not sure of the inner workings of the agreements between those companies and the SaaS vendors they work with, but for the clients, this is much better than getting a DVD with some source or object code and a data dump or even a fully functioning VM image of the app... I just don't want it running on my premises. None of this, however, takes into consideration that a SaaS "product" is often the entire business for pure-play SaaS vendors. There is a lot more to a SaaS product than its core application. At Sixteen Ventures we say that the SaaS Business Architecture is a commingling of Marketing, Intellectual Property, Technology, and Business Model. When you look at it this way, its easy to see that, like most things in this business, providing business continuity for a SaaS vendor's clients is not a technology problem after all. - Lincoln Murphy (http://twitter.com/lincolnmurphy) Sixteen Ventures
Agreed...for me it would all hook on third party security accreditation. Some caution will still be needed given the unacceptable volume of data breaches. Lincoln mentioned 'the "escrow model" is a non-starter in the SaaS world'. I'd have to disagree, Lincoln. Surely some recourse of action has to be available for the client in the case of a SaaS vendor failing?
I would agree 100% with Lincoln. The customers are coming to SaaS for no-hassle to run on premise. I once jokingly said in a panel discussion that the developers themselves are finding it hard to fix bugs in the source code they created and what would a customer do with the escrow source code. I don't think source code is IP. Source code is just text files without the team behind it. We are PaaS provider. We deploy our application on 'Google App Engine' infrastructure. We use GAE as a 'Cloud OS' and we are like a middleware on top of it. One of the tenancy options we have among others, is to create a separate GAE account for the customer and deploy the app in that GAE account. This way the application keeps running for its life time (Okay, till Google's Lifetime) as long as they pay the GAE bills. This is somewhat like opsource example, but is surely a better choice that Escrow!
The clients of SaaS vendors are indeed the end-users and as I mentioned in the previous comment, the idea that, in the event of a trigger event (not meeting an SLA, bankruptcy, something in between), you give a client a DVD with source or object code and a data dump seems to be counter to one of the main reasons why the client chose to use your SaaS in the first place. I like the idea of spinning up an instance in GAE or some other PaaS or IaaS for a client, at least for a controlled off-boarding, but for a sophisticated SaaS vendor, I'm not sure that is the right answer either.... read on. Other than completely violating the SaaS value proposition, source code escrow is just fundamentally flawed when it comes to SaaS in many ways. First of all, SaaS is not just technology. For pure-play vendors, SaaS is their only business. The business is directly tied to the application and vice versa. There are inter-dependencies not only with various technologies, but also various technology providers. So again, I might be able to take a snapshot of the operating environment and put it in my data center or on a VM in the cloud, but I will not get everything that was provided by the SaaS vendor. So tack on "ecosystem contracts" as yet another point that must be managed by someone looking to offer SaaS business continuity. How does this relate to PaaS as brought up by @suresh? Because if the SaaS vendor uses a PaaS, that is another business relationship that must be managed. But what happens if the PaaS goes away? The SaaS vendor is okay, and the underlying IaaS or Hosting company is still there, but the PaaS company fails (read: Coghead). Again, the answer to this scenario is also as clear as mud. For starters, the clients of the SaaS vendor have no transparency into the value chain that ultimately makes up the service they subscribe to. The SaaS vendor could leverage a PaaS that sits on an IaaS that is perhaps leveraging yet another vendor's physical data center. The SaaS vendor could also leverage a third-party billing/metering system, single sign on service, and various commercial data feeds. The PaaS could leverage third-party monitoring systems, integration services, etc. that they provided to the SaaS vendor, who leverages that as part of the value-add for their clients. What is the answer? That is the $64M question that hopefully someone out there is attempting to answer. SaaS, or perhaps more appropriately Cloud, Business Continuity must take into consideration everything, including the source code, object code, database, infrastructure, ecosystem relationships, contracts, SLAs, etc. Complete visibility into all levels of supporting services, from the SaaS provider, through the PaaS, API proxies, IaaS, and down to the physical data center is probably what is required not just when determining business continuity but also when conducting due diligence on a SaaS vendor. The problem is, many of those relationships are part of the "secret sauce" so gaining that visibility will be difficult. There has to be an incentive for vendors to pull back the curtain. Just my $0.02... - Lincoln Murphy Sixteen Ventures
Escrow doesn't solve ANY SaaS issues unless the SaaS vendor is Microsoft, Sun, Apple (or running entirely on a linux platform)... because the problem with Escrow (as it existed in the past all the way through today) is that you don't get all of the third party infrastructure needed to bring up the service/application. And even if you do have the infrastructure vendor as the SaaS vendor, chances are that your escrow agreement doesn't provide all of the infrastructure apps necessary to run the service/app - you ONLY get the service/app code (and maybe your data - which you should have regardless and not have to pay extra for). As a side note: in the decade plus that I've been doing IT-related contract negotiations, and the decade before that when I was solely on the sysadmin side of things, I have never seen a successful escrow release.
[..] A lot of conversations have been going on recently regarding source code escrow and business continuity:here, [..]
Post Comment