In 2009, MuleSoft founder Ross Mason shocked his IT audience with a blog post entitled “To ESB or not to ESB.” The premise: not everyone should deploy an enterprise service bus (ESB). In particular, he offered that applications with minimal protocol and transportation requirements might be better off by skipping the use of an ESB.
When developing the integration platform for its’ ConnectALL ALM Router, Go2Group embraced the market-leading Mule ESB, even with Go2Group’s minimal protocol and transportation requirements. In fact, Go2Group felt MuleSoft’s ESB was the only way to go for ConnectALL. Doug Bass, Go2Group’s chief architect, explained why in a speech at the recent MuleSoft CONNECT 2015 event. Here are some of Mason’s “ESB selection checklist” criteria along with Bass’ analysis.
1. Are you integrating three or more applications/services?
Between 10 and 20 years ago, the job of the CIO was to consolidate systems to reduce the number of applications used within the company with the goal of decreasing license and training costs. Unfortunately, this often proved unsuccessful as users need role-specific applications to do their jobs. And enterprises often purchase smaller companies, adding even more applications to the mix. When eliminating applications is impossible, the solution is to integrate them, allowing users to continue using their domain- and role-specific tools while adding the benefits of collaboration.
2. Do you need message-routing capabilities, such as forking and aggregating message flows?
Any non-trivial (read: enterprise) application requires message-routing, exception-handling, and multi-processing functions, along with complex business integration.
3. Do you really need the scalability of an ESB?
Scalability is usually not a factor when designing an application for integrating a small number of applications (or for a small number of users). However, as organic growth occurs, the application must also be able to scale in order to support the additional load, disaster recovery, and high availability requirements.
4. Do you need to publish services for consumption by other applications?
Many times, the initial vision of an integration product does not include consumption. As the system grows organically and API management becomes a key component of the enterprise, however, the consumption of the newly available information allows expansion into other previously unknown areas of application integration and productivity.
5. Do you need more than one type of communication protocol?
It’s quite possible that the integration of applications will require more than one protocol. Ideally, all applications offer a high-level web services interface that accurately represents the component models pre-existing in the application. Often, however, only low-level (data-only) interfaces are available or primitive interfaces (e.g., DLLs or ETL mechanisms) are available.
Conclusion
Though many enterprise integrations initially appear to not require the sophistication of an ESB platform, as the integration grows and connects more systems and becomes an enterprise critical application, an ESB-like platform is certainly useful especially if the features of an ESB solution are being developed within the custom integration.
