Thoughts on what businesses actually need from the Cloud, not what vendors wish they needed.

Chris Bliss

Subscribe to Chris Bliss: eMailAlertsEmail Alerts
Get Chris Bliss via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

Integration is a double-edged sword: API integration and why it’s not always the right way forward

Spend anytime among the cloud-computing crowd and you’ll soon find that API integration is a hot-topic. How friendly or unfriendly a given app’s API is, how many native integrations it has, the price-point at which API reference keys become available: all those factors are huge selling points for SaaS and a major consideration for would-be consumers.

Naturally, we also think API integration is great, especially when it’s native (see our recent review of RightSignature as an example of a service we think would benefit from more integration). When two or more apps play nice with one another it can mitigate double entry and other workflow “knots,” making IT more bearable. Next-gen apps are (should be?) all about simplicity and function, which integration can (sometimes) deliver.

Thing is, the urge to integrate is a double-edged sword. It’s an understandable urge – and as we say above, it’s an urge that’s often justified – but it’s also something that can negatively perpetuate legacy business processes. Let me explain.

Sometimes users want products to integrate to deliver some new functionality (Solve360’s recentish Gmail gadget is one example). That’s awesome. Sometimes, however, users want products to integrate so that the new system looks like the old system. That’s not awesome. For example, we speak with clients all the time who want API integration in and amongst everything: email, CRM, ERP, invoicing, shipping, accounting, everything. We certainly understand that desire – who doesn’t want a “one-stop shopping” software solution? – but more often than not the desired outcome is something that mirrors old systems and processes. The question asks itself: why change software solutions if you won’t change workflow habits?

While I’m at it, I might also note that non-native integrations (ie integrations that aren’t available “out of the package”) can also decrease the scalability of SaaS solutions. If today you spend $5k integrating two products and tomorrow decide those products aren’t right anymore then you’ll have sunk $5k plus interest in a system you’re not using. Hardly the flexibility you were looking for in the first place, is it?

The point isn’t that API integration is bad: it’s that users should think long and hard about what they’re trying to accomplish before they invest in integrating solutions. In particular, non-native integrations need be examined for cost (including scalability costs) versus value. Above all, businesses need to accept that new software systems will invariably result in new business processes, and that change can be good.

Enhanced by Zemanta

Read the original blog entry...

More Stories By Chris Bliss

Chris Bliss works at VM Associates, an end-user consultancy for businesses looking to move to the cloud from pre-existing legacy systems.