Overview

Search

Documentation

Community

Developers

Components list

Related Projects

How to Evaluate an ESB

When faced with the need for integration middleware, it's a natural progression to consider the adoption of an ESB. In doing any software evaluation, it's important to approach things in manner that utilizes your requirements as a central instrument in the process. There are commonly two levels of evaluation that need to take place when considering the adoption of any software including your business requirements and the feature set of the software; your business requirements and the ESB feature set. There are many topics in these two levels of consideration and they will be reviewed here.

Your Business Requirements

It's important that you begin with your business requirements. Without a solid understanding of your business requirements for a given application, you're spinning your wheels and the effectiveness of the project diminishes immediately. You don't necessarily need all the requirements up front, but you need a starting point even if you're using agile methods to develop your software. This is where a knowledge of your business purpose is important even for the software developers.

Your Business Purpose

Don't say that your business purpose is SOA. That is the how, not the what. SOA is nothing more than a way of thinking to design software. Your business purpose is the goal you are trying to achieve for the business through the use of the software you are developing. Here is an example:

Our business goal might be to combine weather data with mapping data to provide customers with instant weather predictions for destinations when they make travel arrangements via our travel portal. This improves not only our customers' trip planning but also allows our advertising system to target customers with more appropriate advertising. This will improve not only the customer experience but will also match the most relevant ads with our customers' travel planning in an attempt to improve ad click-through rates.

Notice that the business purpose focuses on the goal of the software from the business point of view. The purpose is to:

  1. Improve the customer experience through the use of weather and mapping
  2. Improve the click-through rates of the ads on the website

Understanding your business purpose puts you in better control of driving the functional requirements to meet the goal.

Your Functional Requirements

Once the business goal of the software project is understood, then move on to the functional requirements. Below are some examples of functional requirements for the business purpose listed above:

  • Provide access to weather data
    • This requires integration via a socket to pull the data
    • The data is binary so we'll need to parse it properly and effectively
  • Provide access to map data
    • Google offers the Google Maps API for programmatic access to map data
  • Create a new layer for Google Maps to overlay the weather on the map for the customers' destination city
  • Using the destination and its weather forecast for the trip, send hints to the ad delivery system to target the ads to the trip
  • If the customer clicks through an ad, save information about this ad in the database and link it to the customer profile
    • This will allow us to improve our predictions about what this customer might like to purchase in the future

The functional requirements improve dramatically when the business purpose is identified and clearly communicated to all stakeholders in the software development projects. Such requirements are going to drive the architectural decisions in the systems and the software.

Your Architectural Decisions

Before you begin speaking to any vendors, its also important to establish some architectural decisions about the software being developed. These are not written in stone but are definitely subject to change. Architectural decisions include what will be used to achieve the goals and requirements of the project. This includes designing the system in a service oriented manner, use of specific software packages and maybe even the hardware and software necessary for developing and testing the software project. You may have even made some of these decisions implicitly throughout the earlier exercises. If so, it's important to identify and communicate these decisions explicitly to the necessary stakeholders so that there is an appropriate level of clarity amongst the group.

By working through these exercises, you should now have not only a set of artifacts to share with all stakeholders via your wiki, but you will also have your criteria for evaluating ESBs.

Your Criteria for Evaluating ESBs

Any appropriate software evaluation requires knowledge of items discussed above. Without a good grasp of these topics, it's difficult to equate use of the software with meeting specific goals.

It's also important that a software evaluation is not based on checkbox marketing (i.e., comparing feature sets side by side). This style of evaluation doesn't provide a picture into the actual use of the software. Feature-based comparisons are meaningless without hands-on experience. For example:

  • What if software package A claims to provide secure access to resource X but it's a bear to use the API?
  • What if software package B advertises features 1, 2 and 3 but its performance is awful?

Hands-on experience with a given software package in your environment is a high priority. When you're talking about ESBs this is even more critical because ESBs handle system integration and no two system integration scenarios are ever the same. Using an ESB in your environment to solve one or two of your problems via a proof-of-concept will provide you with a much more informed and realistic set of expectations than will any feature comparison.

ESB-oriented architecture: The wrong approach to adopting SOA

When considering the data you already have created through the steps above for evaluating an ESB, you should also be aware that an ESB-oriented architecture is the wrong approach to adopting SOA. In this article, Bobby Woolf makes a case that it's not a good idea to adopt an ESB without a plan to identify and construct the services that are the core of an SOA. This is an ESB-specific instance of a general IT problem about which much has been written: You should not adopt any technology without first considering the value that technology will produce.

The ESB Feature Set

Now that you have your criteria for evaluating an ESB, let's move on to answering the question, Is ServiceMix the Right ESB for Me?