ESB Evaluation

ESB Evaluation: Tackling the Devil in the Details and Treading the Path to Success

There is a notion catching up in the business circuit lately. Understood as a generational change fueled by Digital Transformation, it’s hugely conjectured that APIs and Microservices are usurping ESBs (Enterprise Service Buses) and marking an end of an era. In other words, API Gateways are gradually gliding into prominence for integration, routing, and orchestration of the services, leaving ESBs in the past.
 
At this maturity level of the industry, we can challenge this conception!

‘ESBs are obsolete.’ This isn’t a certainty for all the clients since most of the enterprises still have a significant on-premise footprint with a number of legacy IT systems. There is a continuous need to build a lot of real-time, asynchronous, and adapter-based point-to-point, and publish & subscribe-based enterprise application integrations. These messaging-based/adapter-based connections are efficient and effective in handling large volume batch operations, handling transaction boundaries, implementing eventual guaranteed delivery across distributed systems, and above all supporting legacy applications that still are at the core of many businesses today.

As of late, we are receiving several inquiries from our clients, who are strong players in their corresponding industries and are seeking help for evaluation of their integration strategies and tools. We have addressed at least five such inquiries in 2018.
 
From our on-ground experience at client sites, we have noticed that the vendors conduct evaluations of their ESBs at a very high-level and go on to make observations and recommendations. However, before they could plan forward with their strategic initiatives, we warn – there is a catch! 

Acting on their ignorance, these enterprises make decisions that are later repented. 

ESB Evaluation Process: Validating the Right Path Forward

The market is awash with integration tools from various vendors, and every tool has its pros and cons. Factoring in our vast experience in business application integrations, we believe that it’s essential to explore the tools to understand the nitty-gritty and derive meaningful, reliable recommendations that deliver. 

As part of our ESB evaluation, we have closely determined the positive and negative impacts of the integration tools on IT landscapes and their aftereffects. Below is our ESB evaluation approach that we recommend for determining the strategic and tactical impact of the software. 

  1. Study the Environment

Learning ins and outs of clients across the landscape is a crucial part of the evaluation process. A lot of aspects need to be examined methodically, including the integration strategy journey of the client, their future goals, real-time and batch-processing needs, the pain points of the existing platform, governance policies, areas that need workarounds, and much more. Our experts usually follow a nuanced approach of understanding the three key benefits that the client might want to experience from their new platform and help them realize quickly.

 2. Define Evaluation Criteria

Assessing the ESB environment is succeeded by designing a dynamic evaluation criterion, tailored to the specific needs of the client. It would also make great sense to interview the experts from the development and operations teams, enterprise architects, and integration strategists to hit the right ramp on the evaluation journey. If the middleware modernization/re-tooling is driven as part of a larger business initiative, understanding these business drivers from the business sponsors and the executive teams themselves will cut through the clutter and help in demonstrating the right proof of business value from each product under evaluation.

 3. Methodology

Below is an illustration of a real-time case study of Kellton Tech’s recent ESB evaluation process, which was executed as per the pulse of our client:

  • In this case, we knew the ins and outs of our client since we have been engaged in their business for more than a decade, a key factor that helped us know their detailed environment in entirety.
  •  The evaluation process was divided into three stages:

a.  As-Is         

  1.  Identify the existing integration patterns from the production environment.
  2.  Install the required software in the virtual machines procured for the evaluation purposes. In the cloud computing era, procuring an AWS EC2 instance or similar would be ideal for the duration of the evaluation.
  3.  Perform proof of concepts for the list of integration patterns identified.
  4.  Ensure application security.

b.  Support for Advanced Features and Future Integration Strategy

  1. Identify the use cases and future strategic goals, such as Continuous Integration (CI), Continuous Deployment (CD),    Application Programming Interfaces (APIs), Containerization, Microservices Architecture, Hybrid Integration, iPaaS, and  more
  2. Kellton Tech helped with the labs and procured necessary evaluation licenses on behalf of the client to execute these use cases since the environment for these components may or may not be licensed for every customer already.

c.    Operational Governance

  1.  Ease of administration
  2.  Ease of troubleshooting
  3.  Ease of maintenance
  • The above aspects were quantified with respect to the below factors and reported accordingly, in terms of: 

a.    level of effort 
b.    complexity
c.    developer comfort
d.    time-to-market 
e.    criticality and impact

  • Licensing models and vendor support/responsiveness to product-related issues and fixes were also evaluated and reported to the client.

The Key to Successful ESB Evaluation

Any evaluation that’s generic in nature, as published by the market research companies, will be useful to have a baseline, but not enough to map the product capabilities against specific client-specific use cases. Some clients may prefer better features over price while some may prefer security and governance over other advanced features. 
Essentially, the key to ESB Evaluation success depends on how well a vendor understands the clients’ present and future needs, along with the tooling in use.