Enterprise Service Buses [ESBs] have been around for some time. They are toolkits to help an enterprise integrate between System A and System B and Systems CDEF as needed.... What we have seen over the years is that with every evolution in the underlying technology stack, there is a new set of ESBs that enter the market. Back in the day, we had TIBCO and Sonic, and now Mulesoft and Talend on the Java/Web2.0 Stack; current integration as a service vendors have hosted “ESB” like platforms such as what SnapLogic and Jitterbit offer with their claims for “easy integration” with minimal development. The evolution of ESBs, in general, helps companies scale and solve their integration problem in a linear manner - and so far, this has worked really well.
Now, however, we are seeing business processes that were once embodied by a FEW large enterprise solutions glued together with ESBs, turn into HUNDREDS of business processes - many of them overlapping. And it’s only going to get worse. We are going to see an explosion of microservices with significant overlap in specific business processes. It is going to be difficult if not expensive for a team with an ESB toolkit to address this explosion of integration needs. ESBs were designed for a different time, with a different technology stack, a different perspective and different approach to integration.
Faced with this situation, you can see that a developer who has to integrate to multiple business processes that overlap, moves to create an abstraction layer. Integrating once to the abstraction layer minimizes the effort for the integrating application. There is work that has to be done to make the abstraction layer effective as more and more implementations are added to the abstraction, but that effort pays off over time by reducing future development costs.
Cloud Elements has created at its core a multi-tenant abstraction layer that does just this. We abstract the resources, the actions, and the workflow. We are solving the problem for the developer with an integrate one, get many approach.
For example, if I am a mobile app developer at a large enterprise, and I need to access information from my CRM systems, how do I do that? In the larger organizations, there are MANY CRM systems - whereas in the past, there were fewer. Today, I might consider an ESB and I would write an integration and mapping to x number of CRM systems that I have - in the ESB toolkit - I would have to do this OUTSIDE of the context of my mobile app experience.
Then, after I had “connected” and “configured” the CRMs to get the data in sync with the ESB, I would have to create a way to abstract my CRM integrations in the ESB by creating another layer to insulate my mobile app from the details of each CRM implementation. In addition, I have to build in the management capability for the security/authentication tokens, mapping of fields and the ongoing changes there. Not to mention the normalization of speeds and feeds to each CRM endpoint, errors that come back, eventing normalization, etc - all so that my mobile application sees a consistent “CRM” experience.
In this situation, Cloud Elements offers a Hub concept in our RESTful, API-first, integration platform. Now, the mobile app developer need only integrate once into our CRM Hub, and they get the benefit of all of the point integrations we have already provided to each of the different CRM endpoints. And if there is a custom built CRM endpoint, the developer can use our API publishing tool to include that CRM endpoint into the Cloud Elements Hub as well. In the end, we have saved the developer a ton of time, and have provided a bunch of integrations services that are much easier for them to experience than what is generally done today with the ESB.
To be clear - we are not a replacement for an ESB. Often, the ESBs expose their integrations as interfaces that can be consumed by the Cloud Elements platform, at which point our APIs add to and make the ESB endpoints more able to leverage other parts of our platform.