The previous part of this article ended in fear being a driving force behind iPaaS adoption. It might sound like a Wild West story, badly adapted for an incorrect setting. But being a Cloud Integration Architect, I have seen how customers literally cower at the sight of a simple heterogenous system like this:

So the iPaaS seller enters the scene with his magic solution. He doesn't have to do much towards selling. He has to just draw this picture and give a demo.

This picture looks so much better! Half-a-million dollars a year is a small price for that.

In the olden days a middleware used to do the same job of integrating diverse systems. The middleware market is quite mature. After years of attrition and bloodbath, it has settled down for a duopoly. You have two major players - Weblogic from Oracle and Websphere from IBM. And those two are much more expensive than even the top-of-the-line iPaaS.

Today's iPaaS solutions are stripped down versions of middleware. You do not get BPEL, onboard database and analytics. Also, mostly do not have any customization ability.

This is how a middleware looks in its full glory:

The careful reader may note that there is a runtime as well. It is mostly a Java runtime and accessible to users via APIs.

The iPaaS solutions do not have that option. And that is where things occasionally go wrong. They are essentially ETL tools with middleware-like connectors added to push and pull data of any format. ETL tools are dumb data pipes with no significant programming ability in the central part. So is an iPaaS. It is just that the latter exudes a lot more glamour because of its address of residence. The poor ETL used to spend most of its life inside a dowdy and dusty UNIX box, sometimes without even the dignity of a monitor.

Most of the iPaaS tools fail when a sync operation between two systems becomes a multi-stage transaction in nature. Single pass transactions are straightforward to manage and that is what most of the tools do. A new customer is created in SFDC. Create a replica in Infor.

How do you deal with a deletion? Do not blindly delete the customer in Infor. First check if there are pending Sales Orders or invoices. Then only delete the customer. Otherwise capture the error - pending SO or invoice - and email a designated person. A real-world use case is even more complicated. The automated program has to supply Sales Order or invoice numbers in the email body!

This time usually the iPaaS vendor ducks for cover. Coming from a middleware background, I tend to be demanding in vendor evaluation rounds. As a result, I have got to witness quite a few high-profile vendor exits when subjected to rigorous and live evaluation processes.

I still advise my customers to go for proper middleware instead of iPaaS. The extra investment will eventually be recovered over its lifecycle. These days there is a thing called Middleware As A Service too. It is subscription based and hence not heavy on capex.