Tuesday

Trying to evaluate ESBs- Starting points

After messing out with lot of integration issues, and trying to find out a "magical" from the easy-going and stable perspective and furthermore the architects dilemma that i was faced up: named "to SOA or not to SOA", the need for evaluating ESBs was emerging.

IBM's developerworks was and is a good resource place. But IBMs ESB approach was cost oriented (3 different ESB products with the associated tools for developing and managing) and in my cases the cost was more than forbitting, espesially in a world that client didnt know and care about SOAs : "Job done" was a common approach and furthermore in lowest cost....

The Enterprise Service Bus (ESB)- which can be defined as middleware that brings together both integration technologies and runtime services to make business services widely available for reuse - offers the best solution for meeting today's enterprise application integration challenges by providing a software infrastructure that enables SOA. However, there are currently a number of different vendors that provide ESB solutions, some of which focus purely on SOAP/HTTP and others who provide multi-protocol capabilities. Because these vendors span the horizon from big enterprise generalists (app servers), to mid-tier enterprise integration providers, all the way to smaller, ESB/integration specific-providers; there doesn't seem to be an established consensus regarding the key requirements for an ESB. As application architects, we have often thought about what requirements would define an ESB designed specifically to cater to the needs of an agile, enterprise integration model.

Considering the ESB as the place were integration can take place, with cost effective (programable and human-hour based) and moreover as a nice tool to start building SOAs, with all the services in a common infra, open source solution was in focus. I found out from the Apache's ServiceMix solution a nice atricle defining in high level (well not for informing the clients but for developers and mainly architects point of view) on the how-to-evaluate-an-ESB.


Firstly, the Business Requirements.
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.

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 the extra integration points and mashups that business need to be developed and used
  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.

Then, of coarce Functional Requirements

As any good practice states, once the business goal of the software project is understood, then move on to the functional requirements. These emerge from the integration and interoperabilty needs that Business Reqs qualify for. What are these needs and how is the best way at hand to accomplish them?

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.

now, the emerged 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, but you will also have your criteria for evaluating ESBs.

and finally, the 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.

This is the first step for the "personalisation" of the solution, which in the SOA approaches is exactly the case : INFRASTRUCTURE FOR ME - MY NEEDS -MY SERVICES


full window
full window
full window

1 comment:

Robert Morschel said...

Some thoughts here on building a business case for an ESB:
http://soaprobe.blogspot.co.uk/2012/10/enterprise-service-bus-esb-building.html

Robert