While having a look at what’s trending with regards to integrating business and enterprise software, it’s becoming a little more crowded. The buzzword space is certainly expanding at an impressive rate. For what used to be the boring kid in the corner (Enterprise Service Bus (ESB)) there’s now a crowd of hipsters with names like EiPaaS (Enterprise Integration PAAS) , Data fabric platforms and so on. In this brief post we’ll place a few sidenote’s, and ask some questions, while shamelessly promoting our services.

Cloud sure, but which one where?

When there’s a lot of new stuff coming out in the market place, we generally see, unsurprisingly, different folks opting for different avenues, further fragmenting the perceived domain. Often complicating needed consolidation at a later stage.

The stage

Integrations, that stuff that we like to call our specialty. At it’s most pre-historic level is still very much the same as it was when Novell networks came to the fore. Pushing data from A to B, usually with a database in between. Then came the formalism ‘client-server’, together with “The network is the computer” (remember ?). Scott McNealy was more visionary then than most people had given him credit for at the time. Fast forward to now, the network really does appear to be the computer with your functionality running somewhere captured in a micro service on a third party cloud. At the same time we tend to argue things haven’t really changed all that much. You’re still generating orders with line items and invoicing with tax lines, all the while sending data from A to B.

But you probably have a lot more different software packages to run your operation. Some integrated and some not. Then there’s Gary from accounting who has suggested to integrate more back-end processes so he can prevent shipping delays in the future, all the while you’re stuck with a decision …. What flavors to choose from ?

• iPaaS
• ESB
• API management
• Direct custom connectors
• A combination of the above

Oh and to make it more exciting a budget revision has just been effectuated, giving you 15% less to spend this year. Due to economic uncertainty. Yet traffic volume is expected to remain stable, with moderate growth forecast. To get through the forest we’ll start by cutting down some trees. As the buzzword list translates to functionality that has a lot of overlap. This is certain to upset Tech purists, please consider yourself forewarned.

A small history lesson

IPaaS ( integration platform as a service) , ESB (Enterprise service bus) , API management. All the previous have distinctive features that make them a little different than the other two features. The functionality, and how they are used however is remarkably similar. Again: Identifying the glaring similarities is bound to upset Salespeople and Tech speak folks alike, but that’s why it’s an opinion piece. A little abbreviated history to lay the groundwork; In the beginning of time, once came a very cool (and useful) innovation in the software space. It was named CORBA or Common Object Request Broker Architecture, by the Object Management Group (OMG ,pun not intended). According to the website the first spec was published in 1991.

Slowly but certainly Objects were becoming all the rage in Software land. (they were already on a long march towards increased popularity since C++ became available for the masses in 1985).

CORBA was a powerful concept, encapsulating many features that are now taken for granted by everyone. CORBA allowed for programs to notify other programs , or be notified, with specific messages containing relevant information for or from adjacent systems. Theoretically, regardless of location, protocol or host. This effectively allowed for true decoupling of functionality between systems and processes. *Note the previous description is a gross oversimplification of the concepts.

Because CORBA was a very ‘heavy’ and cumbersome protocol to implement and keep up. (Yours truly has only once encountered a limited implementation of it in the wild, and that required a dedicated dev. Team to manage and maintain.) it never really made it to the mainstream. Where most folks opted to simply build applications directly on the TCP/IP encapsulation the OS provided. ( If you ever played the original Wolfenstein or Doom in Multiplayer you probably remember entering the IP of the host manually) Nevertheless the idea really stuck because people understood the power of the idea. Cue the next step in this little history lesson: The Service Oriented Architecture (SOA). Promising pretty much the same stuff as CORBA, but the term was more abstract or general, allowing for different vendors to fill in more implementation details. I’d argue SOA really laid out the blueprint for our service oriented architectures of today. With SOAP ( Simple Object Access Protocol) as a typical early implementation of a platform and protocol agnostic messaging protocol.

With SOAP and similar protocols becoming more prevalent, in conjunction with ever expanding internet presence, some order in the chaos was required to prevent the then limited bandwidth from being chewed up as well as provide for more standardized and failure resistant communications. Hence in the early 2000s the ESB concept came to life.

Back to the now

Why am I boring you with this ? I’m trying to make a case that all the buzz words from the start of this article are actually the same thing, that evolved into what is now commonly known as iPaaS. The different names, to me, seem more like markers in time that identify the same basic functionality: Software implementing a standard to, Send messages/data from A to B. Just like it was always intended since 1991.

It was first themed the ESB (*One could argue that the Object Request Broker (ORB) was the first iteration of the concept, but let’s not go there). And stayed there for a long time. With the advent of the Cloud different implementation formats took to the stage. And it slowly morphed into API management software. Largely in part due to the fact applications were hosted and structured differently as a result of industry needs and clever marketing. The latest iteration: iPaaS signifying API management software in the cloud, as a service of course. Because that’s a great revenue model. Many bells and whistles have been added. Useability and ease of use of these products has grown tremendously in the process, particularly looking at the ‘no code’ offerings popping up everywhere.

Here come the questions

So while you’re sitting through demos of various products by pre-sales folks who are convincing your staff how easy it is to ‘Send data from A to B’ with their cloud based no-code platform. Ask yourself a couple critical questions:

• If you’re a SMB: Is this really as cost effective as it seems ?
• What happens if the platform goes out of business or is taken over ? Better yet, what happens to your subscription fee …?
• How often do my interfaces change to justify the extra expenditure ?
• Does iPaaS solution X work well for all, or most of my specific use cases ?
• What happens in scenario x/y that for instance involve a legacy system the iPaaS platform doesn’t have a connector for ?

In short, if you: ‘Just need to connect one system with another system’ in your landscape. And don’t expect this will change any day soon, do you really want to pay $xxxx-, per month in perpetuity for that interface ?
Also bare in mind your iPaaS platform is intended to provide a multitude of interfaces, with what basically is a 'one size fits all' tool, it's not uncommon a business still ends up having to build interfaces for a remainder of integrations that don't fit well with the platform or the use cases it serves out of the box. That’s not taking into account exogenic factors pertaining to the supplier relationship etc.

Bottom line

The art and science of moving data from A to B, has come a long way in the past +/- 35 years. Current commercial iPaaS offerings often promise to be the: ‘Be all, End all’ solution of all your integration woes. Without needing any code to boot ! If your use case, and the subscription model fit. Great ! We’ll be happy to help in case you need an extra hand with regards to architectural challenges or setting up your new platform. If it doesn’t, no worries, and reach out to inquire how we can fix your integration needs.