Blog post

Are You a Victim of “API Slamming”?

By Benoit Lheureux | December 11, 2009 | 4 Comments

This week in Las Vegas at Gartner’s SOA / ADI Event I hosted a Analyst / User Roundtable on the topic of Cloud computing / SaaS integration.

One attendee which has already (impressively) leveraged the services of a dozen SaaS vendors claims that four of the twelve  providers have changed API’s without notifcation, impacting production operations. A few other members of the group cited some experience with what I’ll coin here (strictly for the entertainment value, of course) “API slamming”.

By any interpretation API slamming is not good. While I understand how this can happen at a technical level, in the SaaS user’s defense I don’t understand why any SaaS provider would change its runtime API’s without notifying users (er, in advance, please). In the SaaS provider’s defense, I can imagine that implementing a proactive notifcation mechanism quickly becomes non-trivial, e.g., just maintaining user contact information is problematic

When I said that a leading SaaS vendor claimed to take a different approach, since they told me it “never” changed its API’s and instead just revisions them and keeps the old — the skepticism around the table was palatable.

This group of users considers “API Slamming” to be a Cloud computing / SaaS integration “risk and concern”.

So what do you think?

Is it possible that I just happened to run across a “tough crowd” and an associated exceptional but perhaps not so representative data point on API slamming? Or is it possible that I’ve just uncovered an ugly little secret (and risk) of Cloud computing / SaaS integration?

Comments are closed

4 Comments

  • Thank you Benoit for this very interesting article !

    It definitely reflects the need for API providers:
    1.to consider API as part of their strategy and therefore allocate adequate resources (product manager, customer support, etc)
    2.to use a proper API Management Solution enabling them not only to control, manage and monitor the usage that is done of their API but also to communicate with, interact with and support properly their API users.

    I would like to leverage your article to present 3SCALE, a Sunnyvale-based company that is one of the leading provider of API Management solutions:

    3SCALE enables cloud-based businesses with a secure, scalable and efficient SaaS platform to manage their APIs and reduce time-to-market.

    Its on-demand infrastructure platform offers to API providers the following features:
    – API Access control and management
    – API Usage Monitoring and Analytics
    – API User/Partner portal (including CMS, Wiki, Forum, etc)
    – Billing and Payments management

    API providers can register for a FREE account there: http://www.3scale.net/signup/new

    Cheers,

    Guillaume

    Guillaume Balas | VP Sales & Marketing Europe

    3SCALE NETWORKS | Unleash the power of your API !
    mob: +34 619 824 976
    email: guillaume@3scale.net
    web: http://www.3scale.net

  • John Radko says:

    Benoit,

    Very real problem — especially in a young market. The challenge is to be agile, add new features, and preserve compatilbility (as usual, pick two!).

    I think the SaaS vendors vary in how important they consider this issue, but I think it will make or break the platform vendors like Force. Loved ADDI — watch for a blog posting referencing your BPN taxonomy (with attribution!!!),

    John

  • Rick Nucci says:

    Hey Benoit!

    No you are right on, it definitely does happen. Our experience has been that it is correlated with age of SaaS ISV – the younger guys are earlier to market and do not yet have a versioning strategy. This problem has the made the list of our Top 10 API Pitfalls:

    http://www.techcrunchit.com/2009/11/08/the-top-10-most-common-api-pitfalls/

    This question should be in the evaluation criteria of any customer looking at SaaS -> “do you version your API and maintain backwards compatibility?”

    This is another reason that an integration layer can add value. We can, for example, change our connector which sits between the customers environment and SaaS vendors API once, and it will propagate to all our customers simultaneously, shielding them from the API change. It is easier for the SaaS API provider to notify us of the change (one company) vs. all their customers, and we can help eliminate the impact of that change.

    -Rick

  • Bernd Huber says:

    So, this might sound like a stretch and I recognize that. But I was watching Avatar (3D) last night, and I was consistently reminded of this article about API spamming.

    In the more abstract of the concept: There is such a tremendous value in a global API standard (like it, not like it – but see what USB has done with all its flaws, VHS, MP3 etc). One would expect that some visionary company (Google, SFDC, MS) would take the initiative and create either a basis or an \open group\ to steer the API discussion and build an interface standard in the cloud.

    This leads me to pose the question: Is the API discussion for *aaS at a such early stage and we are simply asking for too much too soon, and it will evolve – or is this truly an unconsidered area of the cloud?