Businesses have been learning to communicate better with each other since Mesopotamian times, and while we now might be far past stone tablets and carrier pigeons, the question remains: how can we make sure the right information is delivered to the right parties, at the right time?
Of course, the modern solution comes in the form of integration between systems, people, and processes and this requires some sort of technological solution.
In this post, we’ll review the benefits and limitations of two competing integration methodologies: the legacy ESB (Enterprise Service Bus) solution and the emergent delivery model for performing integrations: the "Integration as a Service" solution.
This article is part of our series on choosing an integration solution. See other articles in the series:
- Point-to-point integrations vs. Integration as a Service
- iPaaS vs. Integration as a Service
- ITSM Portals vs. Integration as a Service
Alternatively, all of these integration methods are covered in our Integration as a Service Playbook.
We’ll compare ESB and integration as a service across a few key areas:
- Time to integration
- Integration approach
- Ability to align and coordinate stakeholders
- Amount of resources required
- Scalability
- Cost
What is an Enterprise Service Bus (ESB)?
The complex IT infrastructure of most companies is a result of the continual addition of new products, systems, and services.
At its core, an Enterprise Service Bus (ESB) is an architectural framework that consists of a set of principles and guidelines for integrating various applications over a bus-like infrastructure. An ESB acts as a central hub to which all applications connect, providing a common language for them to communicate.
ESB products allow users to build this architecture, but they differ in their capabilities and methods. The central idea behind an ESB is to enable the integration of disparate applications by placing a communication bus between them and allowing each application to communicate with the bus. This approach decouples systems from each other, allowing them to communicate independently without knowledge of or dependence on other systems on the bus.
The concept of an ESB originated in the early 2000s as a solution to the problems of traditional point-to-point integration. At the time, businesses were integrating systems using point-to-point connections (spoiler alert: they still are), which were costly and time-consuming to maintain. The ESB was designed as a more efficient and cost-effective way of connecting systems and applications in a time where APIs didn’t exist in the way they do today.
Since ESBs were introduced, the market has begun to move on and while many enterprise companies use legacy ESBs in their day-to-day operations, it is a declining sector of the integration scene.
Regardless, ESB products are still available to purchase, and we’d be doing our audience a disservice if we didn’t give them a fair and honest review. So without further ado, let’s talk about the ins and outs of the Enterprise Service Bus.
Time to integration - Slow
If we consider the time to integration as the time between deciding to go down the Enterprise Service Bus road and fully functional integrations running on the bus, the steps between include:
- Define your integration requirements:
Before setting up an ESB, you must clearly define your integration requirements, such as the applications and systems that need to be integrated, the data formats and protocols to be used, and the security and compliance requirements.
- Choose an ESB platform:
Select an ESB platform that best fits your needs. Popular ESB platforms include MuleSoft, Apache Camel, and IBM Integration Bus.
- Install and configure the ESB platform:
Install and configure the ESB platform on a server or cluster of servers. This typically involves setting up the underlying infrastructure, such as databases, messaging systems, and other software components.
- Design and implement integrations:
Create integrations between the various systems and applications using the ESB platform. This involves defining the data mapping, transformation, and routing rules that are necessary to move data between systems.
- Test and deploy:
Test the integrations to ensure that they are working correctly, and then deploy the integrations into production.
- Monitor and maintain:
Monitor the ESB platform and integrations to ensure that they are running smoothly, and make any necessary changes or updates to the system to optimize performance and reliability.
So, if it isn’t clear: it’s not a quick process.
Integration approach - Low-code
Since an ESB is an architectural framework that manages the delivery of messages between systems, and not a software product itself, ESBs are technically low-code — even if they require a great deal of technical expertise to get up and running and maintain.
Ability to align and coordinate stakeholders - Medium
When considering the interplay between technical and business stakeholders, it's important to consider how easy it is to align and coordinate the two.
Generally, when the solution requires more coding and deep technical know-how, it's harder to align and coordinate, and you need more people in the mix. When it is less code (and more configuration work) then it can mean that coordination is easier to handle.
In the case of an Enterprise Service Bus, both deep technical know-how and configuration work needs to happen, as well as the development of integration use cases from different business units.
Amount of resources required - High technical competence with dedicated staff
For an organization to successfully run an ESB, there is generally a need for a full team of dedicated specialists, whose job it is to maintain the ESB, add new connections, modify existing connections, and keep the bus running.
Of course, the resource needs only increase as the company grows, and more and more integration use cases are added to the ESB.
Scalability - Medium
In ESB architecture, applications are indirectly connected to each other through the ESB. Compared to manual, point-to-point integrations, this method improves the scalability of an organization’s integration capabilities.
The trouble comes, however, when an organization needs to integrate with an external party’s system or application — like a supplier, vendor or customer. The ESB has historically been a suitable solution for handling internal integration and message handling, but for business-to-business integration? Not so much.
Cost - High
The cost of implementing an ESB can vary depending on the scope and complexity of the integration. There are two main types of ESBs: open-source and commercial.
Open-source ESBs
Open-source ESBs, such as Apache ServiceMix, are free to use, but they may require more technical expertise to set up and maintain — so at the end of the day, it’s not a free solution, and may wind up costing more in resources (and headache) than the commercial option.
Commercial ESBs
Commercial ESBs, such as MuleSoft and TIBCO, come with a licensing fee but often offer more user-friendly interfaces and support services. The cost of licensing a commercial ESB can range from a few thousand dollars to hundreds of thousands of dollars, depending on the size of the organization and the required features.
This means that when assessing the investment you already make in an ESB, or would make if you chose it as an integration solution, it’s important to take into account the total cost — including technical personnel and server/infrastructure costs. Not to mention, of course, the cost of running a legacy technology in the future.
What is integration as a service?
The average enterprise uses hundreds of SaaS products and cloud services every day, and as that number continues to grow, so does the need to ensure effective information flow and communication between them. It’s where the initial need for integration came from, and it’s only becoming more complex as businesses and markets mature.
Enter: integration as a service
Integration as a service is a service delivery model where customers—typically mature enterprises or IT service providers—outsource some or all of their integration needs to a service provider (an Integration Service Provider).
Integration Service Providers generally offer detailed integration design and implementation services that link application functionality and/or data with each other and incorporate this into the company’s existing IT ecosystem.
The integration as a service model allows businesses to outsource their entire integration operation, from planning to delivery to maintenance, as well as many of the associated risks. This means that businesses no longer need to develop and maintain their own integrations and can focus on their core business.
Benefits and limitations of integration as a service
Time to integration - Fast
Integration service providers often promise fast time to integration, and for good reason – it’s one of the core outcomes of the service they’re providing.
Integration approach - No need to code
Because all of the technical aspects of integration are handled by the integration service provider, there’s no need to have technical integration expertise in-house. Provided that the use cases and information needed to flow between systems are clearly defined, the customer generally doesn’t even need to interact with the technical side of the integrations.
Ability to align and coordinate stakeholders - High
Part of the service delivered by integration service providers is learning about the needs of different stakeholders and departments within the business, and also understanding the nature of the ecosystem of vendors, suppliers and contractors that need to be factored into an organization’s integration setup.
As integration experts, integration service providers are equipped with knowledge of even the most complex integration use cases, and can generally align and coordinate stakeholders with ease.
Amount of resources required - Very few internal resources, no technical competence needed
Outsourcing is synonymous with IT service management — whether it be an enterprise outsourcing some or all of their IT function, or a service provider outsourcing the non-core elements of their service to a specialised provider.
When working with an integration service provider, businesses often only need to have one continuous point of contact to manage the delivery of new integrations.
Scalability - Full scalability
Because integration service providers’ core business is to provide future-proof, high-quality integrations for their customers, it’s in their best interest to make sure their service is able to grow and scale with their customers.
Cost - Medium
Now, while we’ve classed this one as Medium, many integration as a service customers will realise the return-on-investment much faster than using an alternative integration method.
Currently, integration solutions typically come in packaged deals where pricing is generally influenced by:
- time to implementation
- staffing considerations
- the scope of the integration functionality
- tool and platform choice
- maintenance costs
The integration as a service model aims to bring a solution to market for a subscription fee, rather than a one-off cost. In practice, you’re purchasing the outcome, not the technology.
Granted, some integration service providers utilize their own (or others’) technology to reach those outcomes, but it’s more so the way the outcome is done, rather than being the product.
Why choose integration as a service?
The integration as a service model serves both enterprises with a sufficient need to integrate multiple services and IT service providers who recognize the difficulty in rolling out and scaling integration solutions to their client's systems.
These enterprises tend to be more mature businesses with many moving parts, multiple operating locations, and deeply-rooted legacy systems. Also, IT service providers with sophisticated ITSM practices often require a systematic method of delivering integrations to their clients—this use case in particular fits the integration as a service model.
The final verdict: ESB vs. Integration as a service
After presenting the evidence, the verdict is clear: if your choice today is between implementing a brand new ESB and adopting integration as a service, your business will likely benefit more from integration as a service in the long run.
If your organization already has an ESB set up and running tasks successfully, there’s no need to retire it — it can (and should) continue to do the things that it already does well, while being supported by the next generation of integrations.
