iPaaS vs. ESB: Which integration approach is best for your organisation?

Until about 10 years ago, the lion’s share of business integration work involved integrating on-premises systems. A number of integration approaches emerged to solve this task, of which ESB (Enterprise Service Bus) was the best known. However, in the last few years, cloud integration has been gaining in prominence. iPaaS (Integration Platform as a Service) – a new modern integration approach – has been becoming particularly popular. And with good reason.

ESB: an integration approach from the 90s

As stated above, ESB stands for Enterprise Service Bus, and the Latin translation of the third word says it all: omnibus means ʽfor everyoneʼ. An ESB therefore forms the centre of a network architecture in which a business’ applications are not directly connected to each other, rather all interactions take place via this central bus. An ESB may consist of technical components, but also of non-technical components such as integration rules and principles. The goal of an ESB is to provide architecture which enables all applications used in a company to easily integrate with each other. Two other terms often used in this context are batch processing and mass data.

The Enterprise Service Bus was conceived in response to the challenges of a growing number of point-to-point connected applications. Point-to-point integration involves connecting each application individually to every other application, which naturally involved a huge amount of work and tended to lead to huge tangles of spaghetti architecture. This is not only very prone to errors, but is also not scalable.

The ESB plays a coordinating role in consolidating and providing data within a company. Furthermore, an ESB is an important component in the service-orientated architecture (SOA) popular in the 90s. However, this type of architecture does not lend itself well to web and cloud-based applications.

iPaaS: an integration approach for the cloud era

By contrast, iPaaS (Integration Platform as a Service) is an answer to the challenges posed by cloud computing. An iPaaS has a far higher scope, which goes far beyond the classic, asynchronous integration processes in an organisation which an ESB was designed for. The primary scope of iPaaS is synchronous integration and scalability between applications and processes – both within and beyond the company. iPaaS complements traditional asynchronous integration with real-time synchronous integration, even liaising between these two worlds.

Specifically, iPaaS enables consistent, clear and seamless connection between cloud applications, as well as with on-premises or legacy applications. The iPaaS approach is part of the new web-orientated architecture (WOA), which is taking over from SOA in the cloud era.

iPaaS or ESB: Where iPaaS scores in the cloud era

6 reasons to go for an iPaaS:

Firstly, iPaaS enables you to use contemporary web-based APIs (Application Programming Interfaces) such as REST or JSON, which have been conceived especially for modern, cloud-based data exchange between cloud applications. By contrast, an ESB’s strengths are in the use of asynchronous protocols and file-based formats such as XML, which lend themselves less well to data exchange with cloud applications. However, iPaaS also has a solution for these older protocols and formats by converting them into modern, cloud-compatible versions.

Secondly, iPaaS enables data to be transferred in real time, or near-real time. For a growing number of companies, being able to update data quickly is crucial to their success. An example may be for running an online shop. ESB, on the other hand, only supports data transfer from cloud-based systems and applications to an extremely limited extent, if at all.

Thirdly, an iPaaS can be used to keep legacy systems going for longer. That could be an economically interesting option for your business continuity management, particularly these days as applications are increasingly becoming cloud-based and legacy systems are quickly becoming burdensome. An iPaaS could enable you to hide your legacy systems behind a facade of APIs. Integrating these legacy systems over APIs would enable you to make their data accessible to the outside world and made available to mobile applications and the like.

Fourthly, iPaaS is scalable with a multi-client capability. This means that you don’t need to set up a separate physical environment for each client or organisational unit. As a consequence, the technical and human resources required to set up and maintain a physical environment for several organisational units are not significantly higher than for a single unit. Once set up, an iPaaS can be used by several different organisational units, be these departments, global branches or subsidiaries, or even business partners. Conversely, even a well set-up ESB could only enable a very limited multi-client capability within an organisation. Essentially, this would only be inter-departmental, at best.

Fifthly, iPaaS is much better suited to a modern software procurement strategy, which requires speed and ease of integration. This would enable those in business areas to take a leading role in choosing software and even to carry out simpler integration projects independently through citizen integrators in the departments. If using an ESB, this would require a lot more coordination between business and IT departments, as well as specially trained staff.

It’s also worth remembering that if you are lacking the internal resources you need for a certain task, professional help can often be non-bureaucratically offered by your iPaaS provider. An ESB-based approach would require in-house specialists, and acquiring people with these specialist skills can be a long, expensive process which could even cause the integration project to fail.

Sixthly, iPaaS fosters collaboration between business and IT departments with contemporary cloud integration. Your in-house IT department is therefore encouraged to work with modern integration approaches. Those on the commercial side have more autonomy and responsibility in selecting the best software to support the business. They are involved in the selection process from the offset and gain knowledge along the way. Furthermore, the IT and the commercial sides learn to work with each other and gain insights into the other’s needs, way of working and limits. And that is crucial for an agile organisation.

Where ESB still scores …

One argument for using an ESB, even today, is legislation or other stipulations requiring data stay on premises for security or other reasons. An enterprise service bus can be the solution to these stipulations, albeit with the limitations detailed above.

In addition, as an iPaaS has a particularly strong focus on cloud and SaaS integration, many iPaaS providers have a fundamental weakness in integrating individual on-premises or legacy systems with each other. These are often better connected with an ESB. However, once these on-premises or legacy systems need to be connected to the cloud – a requirement in most business models these days – iPaaS once again comes into its own.

In conclusion

• If the primary integration need in your organisation is to connect cloud-based applications, with only a few, if any complex on-premises or legacy solutions to connect, then generally, an iPaaS is the right choice for you.
• If, however, your main integration goal is to integrate on-premises or legacy systems, then an ESB or similar approach could be the right choice for you.
• However, these days there’s barely a company which doesn’t need some degree of cloud integration. The ability to work off-premises, to connect quickly and reliably to your international partners and to have your own services available 24/7 are now often non-negotiables. In such cases, therefore, it’s worth considering running an ESB and an iPaaS in parallel. Or you could look for an iPaaS provider who has expertise in integrating on-premises or legacy systems. Interestingly, these tend not to be the larger providers, rather those who are more geared towards medium-sized companies.

iPaaS & legacy system integration: A medium-sized iPaaS provider’s strength

Generally speaking, the large iPaaS providers prefer to scale across their extensive customer base and resources with largely standardised services and processes. That often means that their expertise is in high-volume integration of mainstream cloud applications. More customised integration projects requiring complex integration of on-premises or legacy systems to the cloud are, from a financial point of view, less appealing to them.

Medium-sized iPaaS providers, however, tend to occupy niches and segments which give them an edge over their larger competitors, and tend to make less economic sense for the large iPaaS providers. Some iPaaS providers specialise in high expertise in both cloud and on-premises/legacy system integration.

The advantage to you as a customer is that these medium-sized iPaaS providers can bridge both worlds for you. In many cases, they can match the performance of an ESB system or seamlessly connect an in-house ESB-based integration approach to a cloud environment. This makes a legacy system scalable and can play an active role in your modern, corporate cloud strategy by, for example, providing you with data for new business models.

SEEBURGER is such a medium-sized iPaaS provider with proven experience in integrating on-premises and legacy systems. A particular strength is deep API integration. All our services form part of our Business Integration Suite (BIS), the technical platform for SEEBURGER’s iPaaS offering, optimally coordinated and available. Therefore, you only need to learn how to use the platform once, which involves much less time and effort than drawing an iPaaS and API management and integration solutions from different providers.