What’s Wrong with the ESB: Five Questions to Uncover False Cloud Integration

What’s Wrong with the ESB: Five Questions to Uncover False Cloud Integration

Salesforce chief Marc Benioff has been warning people about the “false cloud” for several years now. Rather than leveling diffuse criticism, he specifically called out the “false cloud” for not being efficient, democratic, economical, environmental, or open. That’s a long list of faults, but a strong case for a cloud that you don’t have to install, provision, power, or secure yourself.

In the integration space, there’s a strong parallel to be made between the “false cloud” and the old enterprise service bus (ESB) approach to integration. Just as a system is not truly “cloud” if it requires you to buy, install, and maintain proprietary hardware, it’s not true cloud integration if it requires you to buy, install, and maintain an on-premise ESB. Integration vendors who make the claim to be “cloud” but then require you to install and maintain a large on-premise footprint put the timeframe, return on investment, and value of your integration projects in jeopardy.

In ten years of enterprise integration experience, we’ve found that many integration solutions that sell themselves as cloud-based actually require an ESB. This increases your on-premise footprint, requires professional staff to monitor and maintain, and in general significantly amplifies the complexity of an integration project without providing related benefits.

Given the complexities of on-premise installations, it’s no surprise that Nucleus Research has found cloud integration projects to be significantly faster to deploy, more cost effective, and less maintenance-intensive than on-premise integration solutions. In fact, these massive advantages mean that cloud integration delivers 1.7 times greater ROI than on-premise.

Cloud not only delivers superior return on investment, but also keeps your organization agile enough to accommodate the latest technologies. Just like huge on-premise server rooms have gone the way of the Walkman for most companies, ESB technology was truly made in and for a different era. Designed a decade ago before social, cloud, and mobile became mainstream, the ESB is a relic from another time that isn’t built for quickly connecting new cloud apps with ease.

Given the drawbacks of the on-premise ESB, we recommend asking these five key questions to ferret out false cloud integrations:

  • How big of a on-premise footprint is required?

  • What’s the average implementation time for customers?

  • Is IT or developer involvement required to install and maintain the system? (If the claimed is no, try a follow-up: How many of their customers actually self-implement?)

  • Do you need to write code to create and manage connections?

  • Are multiple products, designers, or servers required to achieve hybrid integration or API management?

If the on-premise footprint is large, implementation time is long, and the other questions are answered with a “Yes,” beware – you’ve got a false cloud integration solution in your hands (or at your feet, as the case may be).

Instead of an ESB, we recommend you opt for true cloud architecture that enables you to connect any application without being required to install anything on-premise. Jitterbit’s cloud architecture even features cloud agents that can run behind your firewall without any installation effort on your part, meeting stringent data security requirements while maintaining a small footprint.

In an increasingly cloud-based world, an on-premise ESB can seriously hinder your ability to quickly connect with the latest technologies and enable your business to stay fully digital. So, when evaluating integration solutions, keep an eye out for false cloud solutions that roll in like the fog and cover up the previously bright outlook for your integration project.

Try true cloud integration with Jitterbit