« Eclipse: the quiet revolution | Main | An agenda for SOA in 2006 »

Network Computing recently published a pair of articles - a review of eight of the ESB products available and the results from an online poll with 530 respondents (I will talk about the survey and some other views on the state of the market in another blog item soon). Each throws out interesting results and both point a high level of diversity in terms of product features and customer views of what an ESB should do. As I have said elsewhere at greater length, I do not regard this diversity as undermining the ESB concept. If you accept that an ESB is an approach to implementing SOA, and SOA is clearly being used in a huge variety of settings, it is not surprising that ESBs also reflect that diversity. Overtime this diversity will probably converge as we better understand the reoccurring patterns that occur in many SOA implementations.

The review is an impressive piece of work that must have taken a huge amount of effort on the part of their reviewers and they should be thanked for helping peel back the marketing hype to allow the potential users to look at the underlying products. However, I would caution any reader that any lab test tends to oversimplify and be tidier than the integration challenges faced in the real world. This can favor the well-polished over the deep.

One finding that might have surprised readers was an absence of BPEL support in 5 out of the 8 products reviewed (the exceptions being Cape Clear, Fiorano and Oracle). BPEL is certainly a standard over sold by some – it is about process orchestration within a specific model and has lots of limitations – it doesn’t do the peer choreographies like CDL or human workflow and it ignores data manipulation. However, not using BPEL isn’t necessarily the solution as the rest of the vendors are either pushing a non-standard solution (clearly a major weakness for an ESB which is meant to be standards based above everything else) or simply have a major gap in the product functionality.

Unfortunately, I would have one major quibble with the marking scheme: the focus on raw license cost over project cost. To be fair it is a failing that most product comparisons share. However, I do not think it can be stressed enough that in most cases the cost of the licenses are but a small portion of the overall cost and therefore the raw license cost is not indicative of which product will cost most to use in the target project.

A better estimate of project cost is the combination of license cost and a measure of productivity which neatly brings us onto another interesting point: Three of the products (IBM, Sonic Software and Cape Clear) required coding to complete the lab test. While this may be just a quirk of the lab test, this is still a much more worrying point as code extensions to an integration product are typically much more costly than configuration of what comes out-of-the-box and if these products can’t solve the lab problem without code what will they be like with the real (and more complex) projects.

Posted by rbradley in Market trends |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/167