Most organizations have accepted the commercial benefits of using enterprise service bus-based integration products in their software projects. However, the industry expectations for an ESB product are ever increasing. This article will explain how vendors are trying to cope with the demand.
Most organizations implementing a service-oriented architecture have acknowledged the usefulness of the enterprise service bus, or ESB—a middleware integration technology. However, the demand for more capabilities from an ESB product keeps on increasing. This has posed several new challenges and opportunities for ESB vendors.
In my last article, I discussed the value of tools vendors employing an ESB-based ALM integration platform. In this article, I will explain the industry expectations from today’s ESB-based integration products and the vendor responsibilties.
Following are the two major indications as evidenced by the vendors in this context.
Integration with the Cloud
Cloud computing has seen many changes in the business forefront. Developers and IT managers who handled information silos in on-premise enterprise application integration in the past find difficulty doing the same with the cloud.
Non-IT professionals from sales and marketing departments often face data sharing, security, and integration issues while using cloud-based services. The problem arises not only for the organizations looking to integrate complex applications in the cloud, but also for the software as a service vendors and cloud service providers. Thus, with more and more businesses opting for the software as a service model for their development project, the surge is definitely toward a cloud-based application integration solution.
Therefore, the challenge and opportunity for enterprise application integration vendors is to provide an integration solution that is low-cost, easily configurable, intuitive, user-friendly, and open to any tools customers choose.
The goal is to create a unified, integrated tool ecosystem that allows information to flow freely in real time and across stakeholders, geographical boundaries, tool silos, and tool vendors. Though the majority of vendors have already progressed a lot in offering a web-based integration solution, the solution itself needs to be flexible, faster, and available on demand.
Better API Management Capabilities
The beauty of the ESB lies in its platform-agnostic nature and the ability to integrate with anything of any condition. With all that is happening in the integration forefront, technology needs to address overlapping API management capabilities and aim at cultivating niches such as software as a service integration. Although customers expect ESB products to be stable, there are often challenges that need to be addressed by vendors.
"I've seen a lot of evolution in the ESB marketplace," said Paul Fremantle, cofounder and CTO at WS02, in a CIO article. He predicted that the ESB and API management functions will come together. This is because today’s ESBs have undertaken certain functions that are typical of API gateways, such as quality of service, usage throttling, and access control roles.
Similarly, API management vendors have also added a number of ESB capabilities to their existing line of products. This clearly shows how the technologies are complementary to each other. In fact, publishing, managing, securing and marketing APIs takes the lion’s share of the market in enterprise integration solutions today.
Many new customers are adopting ESB and API management components to integrate in-house applications as they see fit. The popularity lies in the fact that it connects end points beyond the environment of the firewall-cloud platform and software as a service system. In fact, the leading ESB vendors have already started providing API connectivity to many software as a service and on-premise applications. As more and more projects tend to span across multiple channels and involve teams, customers, and systems from different locations, better interface management will become more important in implementing service-oriented architecture. API development and API management are going to be the next big thing, as expected.
Conclusion
While almost every vendor is trying to build pluggable components to connect one tool with another through an ESB model, not many are able to do this in the best possible way. James Governor, principal analyst at Redmonk, said of service-oriented architecture initiatives, “Without solid architecture and governance in place SOA is basically a waste of time.”
Organizations that use a service-oriented architecture to synchronize distributed applications need better control of governance, configuration, version control, data management, service-level monitoring, interoperability, process flow, and reporting. They should spend more time and effort designing software architecture and finding better ways to govern data flow across integrated tools. The concept of “connect, view, and monitor anything to anything in any way and from anywhere” in application lifecycle management integration works—when there is a robust architecture supporting it.
Because organizational needs are customer-focused and service-based, it is not just about integrating data from one tool with another that will drive the future of ESB-based vendors. It is about creating an integration solution that is agnostic to protocols, platforms, operating systems, and APIs that leverages stakeholders to use real-time metrics across tools and helps in predictive analysis.
With software quality, cost, and delivery time so crucial in any service-level agreement-driven project, the challenge will always drive vendors to add more values to their existing ESB-based integration offerings.
