Recently, I came across a statement that ESB, as opposed to iPaaS, was developed for access administration to obsolete, legacy systems (by definition on-premise ones). Indeed, the term ‘enterprise service bus’ allegedly made its appearance in 2002, while cloud computing basically arrived together with Salesforce in 1999, or so they say. So, it might seem as if ESB was indeed created in the already-cloud era to connect non-cloud applications.
However, to say it like this wouldn’t be exactly correct. The term ESB may have appeared in 2002, but the architecture model that it represents existed long before that. So, enterprise service bus wasn’t developed to connect obsolete systems. It was developed to connect systems, period. It’s just that it appeared when there was no cloud on the horizon yet.
Then came the iPaaS to seemingly replace ESB in the area for which it was too dinosaur-like — for SaaS. Even more so, iPaaS quickly evolved to connect to on-premise applications as well. It looked like the concept of enterprise service bus became out-of-date. Yet time is known for not standing still, and so now we have lightweight ESBs that support APIs as well as integration platforms that connect to legacy systems. All is getting thrown into one big pot.
This all made me think about the difference between iPaaS and enterprise service bus in the modern tech world. Where is the difference between ESB and iPaaS now, and is there any difference at all? Can iPaaS completely replace ESB some day or on the contrary, can they be used in parallel?
Why still enterprise service bus?
There is no point in saying that SaaS applications have disrupted the delivery of on-premise software — this is not news, it’s a fact.
However, it would be incorrect to say that on-premise systems are not deployed anymore and IT professionals now only have to deal with the legacy system remnants. SAP is still quite in even now in 2016, and ESB technology is recommended to be implemented for creating aggregated services, while lightweight ESB is preferred for embedded integrations.
Besides, enterprise service bus has evolved with time too, and modern ESBs can be cloud-enabled, have adapters to cloud services and can even communicate with RESTful APIs. Do such ESBs make the existence of iPaaS redundant?
Where iPaaS complements ESB…
The short answer is — No.
Even with all those modern, lightweight ESBs, there are still a few areas where it is highly advisable to turn to an integration platform as a service instead. Of course, it needs to be mentioned that I’m talking now in the context of large enterprise companies who have complex internal architectures and really need enterprise service bus to hold them together. If it is a smaller company with lower IT complexity and less on-premise software, ESB might be an overkill altogether, and it’s better to go for an iPaaS from the start.
So, what are these areas in which iPaaS can beat ESB?
When multi-tenancy is important
While multi-tenancy can be beneficial for quite a few purposes, its most important value proposition is cost reduction. By allowing multiple entities (“tenants”) to share the same instance, complex organizations can significantly reduce administrative and infrastructure costs, reportedly by even up to 40%.
Yet, most ESB products are not multi-tenant, or at least not fully multi-tenant, even some of the modern ones who actually claim they are. In this sense, iPaaS has actually an advantage as it usually does support multi-tenancy by nature.
Expanding B2B integration
While B2B integration — the kind of integration that happens outside own four walls, e.g. between partners or suppliers— is essential for an enterprise business, ESB is very seldom used for it. First of all, ESB is the kind of core piece technology that is supposed to stay inside and hold internal architecture together.
With B2B integrations, their very nature would require an enterprise service bus to be connected to external systems. Moreover, recently, cloud-based systems are chosen for the purpose of B2B integration more and more often. Nothing wrong with that, but it might pose some security issues as it makes it more difficult for IT departments to keep a close eye on its compliance with all corporate laws, rules and regulations. Not to mention the fact that it’s been common practice to use other systems than ESB altogether, traditionally EDI gateways or value-added networks.
Generally, there are several requirements within the scope of B2B integrations, which cannot or shouldn’t be fulfilled by ESB. To name just a few:
- High horizontal scalability
- Ability to connect own on-premise systems to external systems in general and to cloud-based systems and applications in particular
- High availability for trading partners and suppliers
- Ease of use for internal, non-technical users who would need to at very least access the information
Considering these points, it seems to be quite obvious why iPaaS has lately grown increasingly popular for B2B integrations: it is by nature horizontally scalable, cloud-based, and easy to use. Besides, it is just safe, because it usually has no direct access to the very core organizational systems.
Supporting ad hoc integrations
It goes without saying that historically, connecting systems and applications fell within IT departments’ remit. Among other things, it was due to complicated codes and limited programming literacy in general.
Nowadays, however, we see a growing demand for ad hoc integrations — the kind of integrations that are flexible, lightweight and need to be done within the shortest possible time to support immediate business goals and speed up projects delivery. On the one hand, today’s fast-paced business environment dictates this demand; on the other hand, the digital literacy has significantly grown and made such ad hoc integrations possible.
Yet, enterprise service bus model is simply too complex and too slow for this kind of integration projects. The involvement of an IT team is unavoidable, which thwarts the whole meaning behind ad hoc integrations and in worst case scenario can even slow the business down.
Not only this; ad hoc integrations usually go hand in hand with two relatively new “breeds” of integrators, who are not trained per se to use ESB: the so called ‘ad hoc integrators’ and ‘citizen integrators’. If the former may not be adept in enterprise-wide integrations, but are able to through some scripts together nonetheless, the latter, as a rule, do not code at all.
For this group of integrators an iPaaS is the enabler for a faster results delivery, better communication and streamlining business processes in due time. Provided, of course, that such an iPaaS offers easy-to-learn and easy-to-use integrations tools.
Enabling IoT-related integration projects
Even now, the architecture of most ESBs has low performance, and ESB has in general very poor horizontal scalability. This means that high-performance applications cannot take advantage of the integration capabilities provided by enterprise service bus.
But low performance and poor scalability not only make most ESBs be hardly suitable for connecting disparate real-time, high-performance applications. They are practically useless for connecting IoT services and devices to other systems and applications that process, evaluate and recycle IoT-provided data, in part due to parallel processing, for which high scalability with low latency is the key.
This and the fact that IoT-related applications and systems will most likely be external ones, make ESB a poor candidate for IoT projects, but bring iPaaS to the fore again. Especially, if such an iPaaS has microservices architecture, which by nature ensures the already mentioned necessary combination of high scalability with low latency as well as high performance.
iPaaS cannot replace ESB… but can perfectly complement it
Despite the whole long-going talk about iPaaS being the new enterprise service bus, or the recent discussion about microservices making the ESB concept redundant eventually, I don’t think that we’ll see the dawn of ESB anytime soon.
The thing is that the idea behind this model is as up-to-date as it has ever been; it is the technology that sometimes cannot keep up. But I am sure that it will eventually. Let me just repeat one small example: 10 or maybe even 5 years ago no one in their right mind would even imagine that enterprise service bus can reach out to cloud applications — and now it can, one way or another.
So, I think it is more important to see ESB and iPaaS not as rivals, but as two architecture models that perfectly complement each other and can be equally successfully used within one and the same organization to help IT professionals drive innovation and excel in their work.
