A Cloud API Manifesto for Integration As A Service

Three events last week connected some dots on Cloud APIs for integration as a service:

• My peer review of Eric Knipp‘s upcoming case study on New York Time’s Open WOA
• A client specifically asked me — “do any B2B integration vendors offer Cloud API’s?”
• I spoke with the folks at ECGridOS — who offer a full set of Cloud integration API’s

Eric’s research tends to focus on how IT end user companies use Open WOA API’s. The storyline he’s unfolding is that there’s real value in API’s both from the technology point of view — e.g., to lower technical barriers to implementing collaborative multienterprise processes — and the business point of view — e.g., how API’s help companies to tap into “The Collective” of their external constituents to increase insight into their customer’s needs — and even their own business.

The same week a Gartner client was speaking with me about their B2B consolidation project — a typical strategic IT initiative focused on consolidating various B2B and Cloud services integration projects onto one shared B2B infrastructure (either via on-premise software or via some form of B2B managed services outsourcing). In our conversation after we’d explored all their options they casually asked me whether any of the B2B integration vendors I cover day-to-day offer a full set of API’s into their integration services, much like those publicly available for Force.com, Amazon S3, etc.

That was a great question. I’ve been following the emerging role of Cloud API’s for some time now — see Will WOA API Adoption Kill Integration? and Are You a Victim of “API Slamming”? — but not many clients ask about API’s related to integration services in particular very often. A typical use of API’s for integration services that I’ve seen is where B2B providers (e.g., GXS and Hubspan) publish API’s for their provisioning engine, e.g., so that IT end users or channel partners can provision new trading partners electronically, e.g., from Microsoft BizTalk into the GXS Trading Network. Or API’s to support automated message tracking, i.e., instead of forcing the consumer of integration-as-a-service to login with a browser or run a report.

But most API’s for integration-as-a-service are limited in scope — I am not aware of any prominent B2B provider that publishes a full set of API’s for their integration services. But Loren Data Corp — a very small Ecommerce provider with a history of OEM’ing basic VAN transport capabilities — has recently deployed a comprehensive set of API’s for their integration-as-a-service offering at ECGridOS.net. (As a .NET developer myself I was struck my the breadth and readability of these integration-related API specifications).

Without promoting one provider over another, I found it intriguing to discover such a full set of API’s devoted to integration-as-a-service. I wonder if other providers of integration-as-a-service also publish such comprehensive API’s. It also makes me think that perhaps other providers — who, Boomi? Cast Iron? Hubspan? GXS? — should also do so in order to better serve the needs of their users.

I will be following this closely, and welcome hearing more from other providers who publish API’s specifically for integration as a service. Everyone who knows me knows that I’m not prone to hyperbole, and frankly I consider API’s to be simply another incremental opportunity to enhance your overall value to external constituents. But given that Cloud services and the SOA approach to integrating distributed functionality is an enduring, high impact IT scenario I believe that B2B providers *should* be developing an API strategy for exposing their integration as a service functionality. If not immediately, probably soon.

What do you think?

– bjl