Late last year Yves Hiernaux guest posted here on CloudAve with a post that absolutely resonated for me. Given my lengthy background at the coalface of small business, it’s not surprising that I have a real affinity for solutions that facilitate the integration of discrete applications and, in doing so, make life a whole lot easier. It’s really easy for those of us who spend our days reviewing and exploring software to forget the realities of the user – especially in the traditional enterprise software world it seems customer advocates and mentor are more about advocating and mentoring IT departments than the poor downstream users of the software.
Maybe that’s why SaaS is so appealing to me – it’s a quick and easy solution that really lends itself to end-user implementation, thus avoids the eternal “it meets the IT departments needs even if not the users needs” problem.
As indicated above however, end user implementation falls down a little when we’re looking at integrating a number of different applications. While I’m a firm believer in the value of APIs, a post I recently read gave me pause for thought as to whether they’re in fact the best solution to the integration problem. As Bob points out;
Even though there are web services “standards,” everyone implements the standards in a different way. Things like authentication, session management, protocols, meta data browsing, and exposing customizations are rarely implemented the same way from application to application…..But even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. For example, APIs don’t handle the transformation of data between applications (required because every app describes data in a different format, even when multiple apps are describing the same thing such as a Customer). They don’t handle the validation, business logic and error processing of the data as it moves between apps. And they don’t handle the interaction with the API of another application that’s being integrated. Even two apps built on the same PaaS platform are not natively integrated with one another.
Obviously it’s a post that furthers this particular vendors solutions – but in this case their solution would seem to make sense. AtomSphere is a SaaS integration solution that essentially prepares a platform by partnering with different SaaS vendors and then offers the end user a cut and paste option to integrate various services.
AtomSphere natively handles the different integration aspects such as multi-tenancy, customization, changing APIs etc. They abstract all of this complexity and detail away from users so they can focus on easily connecting their apps – in the same way that an iGoogle page allows users to plug and play widgets at will without thinking about linking and other issues.
Another similar offering comes from SnapLogic. Their product "delivers a uniform environment for developing data
integration interfaces by eliminating custom web services programming
through its combination of connectivity to SaaS applications and
on-premises data sources" – a nice analogy of what they provide is neatly articulated by the term "RSS for data". SnapLogic have a couple of great webcasts to show an overview of their product, and an example of a SnapLogic enabled mashup.
Of course both vendors and customers will have concerns about relying on a third party platform such as AtomSphere and SnapLogic – in this department SnapLogic wins out – it’s an open source product.
As always, we’re keen on feedback and are happy to hear the thoughts of people with a technical overview of the issues around integration