SaaS integration without the lock-in

After reading my post about Appirio’s eat-your-own-dogfood SaaS integration at the weekend, Zach Nelson of NetSuite wrote me an email to point out some of the downsides when integrating many different services in the way that Appirio has done:

"How much would it cost to do what you described, and how much does it cost to maintain it, what sort of resource do you need on staff to address re-programming when you want to exchange different data than was originally envisioned, or when one of the 10 vendors decides to change their API?"

Nelson's point, of course, is that NetSuite customers avoid all these integration hassles because everything is pre-integrated into the suite, including links to popular external services such as Google AdWords. Which is fine if customers are happy to go with whatever NetSuite sees fit to build into its suite. But what if there are best-of-breed services that are an irresistible fit for your individual business needs? Then the extra hassle and/or the cost of hiring an integrator like Appirio to take care of it might well seem worth it.

In either case, customers still give up an element of control because they're relying on a third party's proprietary skills and intellectual property. Doing everything through NetSuite (or one of the emerging ecosystem platforms such as Salesforce.com's AppExchange) means banking on the vendor (or ecosystem) in question continuing to meet your evolving needs as a business. Paying an integrator to stitch together best-of-breed solutions ties you just as firmly into that integrator's services. What do you do if the relationship begins to turn sour? That's when you realize how much effort it would take to disentangle your business from software that's only available from that unique source — a phenomenon known in the trade as vendor lock-in.

I was therefore pleased to discover that a group of vendors last week have got behind an initiative to converge on an agreed set of existing open standards when integrating SaaS applications and other on-demand services. The initiative is called OpenSAM, which stands for Open Simple Ajax Mashups, and the OpenSAM website succinctly describes its mission and scope:

"Unsurpassed Web 2.0 solutions can be built by combining best-of-breed applications rather than relying on a single suite of applications.

"Current standards support single sign on, document and data transmission, and rich application interoperability. OpenSAM's purpose is to establish uniform ways of using the current standards.

"OpenSAM specifies how to do the following using well established standards:

• Application discovery, provisioning, branding and identification
• Application launch, including workflow context and meta-data passed via defined CGI parameters
• Centralized document storage, read/write, browsing, and meta-data semantics"

OpenSAM was founded last September by ShareMethods.com and iNetWord.com, who have been joined for last week's launch by eight other vendors including Web 2.0 rising stars such as EditGrid, Joyent, Caspio, EchoSign and Preezo. The consortium also launched ShareOffice, an Office 2.0 suite assembled using OpenSAM from best-of-breed components contributed by ShareMethods, iNetOffice and EditGrid. (See Read/WriteWeb for a writeup of ShareOffice and some informative diagrams). In an interesting twist, ShareOffice is delivered with AppExchange integration, which is further evidence that various flavors of interlocking on-demand ecosystems are emerging, rather than one or two dominant ones.

One thing to point out straightaway is that OpenSAM integration is very much focused on what happens on the client (not surprising considering what the acronym stands for). So for example passing context between applications is done using CGI parameters and data is accessed via the WebDAV specification. It still doesn't address the kind of service versioning and repurposing that Nelson called out in his email to me. But in these days of web services and SOA, it's not rocket science to build a standards-based infrastructure that manages that kind of API-level data integration. It just needs formalizing so that it has a chance of becoming common practice.

What's important is for an open, standards-based option to be out there in the market, so that customers have an alternative that avoids the kind of vendor lock-in I mentioned above. History warns us that it's not going to be easy to get this going, but we also know that the Web is most successful when everyone adheres to the same standards, and that ought to be just as true for applications and services as it has been for content.