Lots of hate for the ESB lately.
Everything from Joe McKendrick’s E-s-Busted to Dave Linthicum’s ESB Hurting SOA, we are in the midst of a full-fledged backlash.
I’m certainly sympathetic to these views. The SOA “patient” is already pretty sick. Years of Tribal IT battles, “quick fix” technology solutions that dont interoperate and create more hassles than they fix, project funded IT driven by inconsistent objectives and just plain years of abuse. This after years of “waxy IT buildup” leaving the communications “arteries” of the company rigid and atherosclerotic. Business units are demanding solutions to Business Process problems and quick fixes that existing IT infrastructure can’t support.
Any “expensive cures” for this patient steals valuable money from proven technologies that might have a chance to save the patient. So if some vendors have exploited the pain of this sick patient, I can see why there’s so much anger in the blogosphere for this approach.
The big problem with ESB isnt that it’s of no use. as Lori MacVittie pointed out, ESB exists for good reasons.
The big lie:
The problem is that ESB by itself was sold as a “magic cure” for:
1) Silos, and
2) BPM (Business Process Management)
So along comes this “doctor” called Enterprise Service Bus. All you have to do is take the magic ESB treatment and years of architectural degeneration will be cured… right? Wrong! And the backlash against the ESB “quack doctor” begins.
The “Magic Cure for Silos” Enterprise Architects Rejoice!
Why are people so angry about this? Well, first of all, the ESB “doctor” is guilty of some amount of malpractice. The word “Enterprise” as applied to Enterprise Service Bus is really as descriptive as adding the word “Enterprise” to any piece of software that isnt Enterprise just to make it sound more serious. See, the problem is that this “Bus” wont take you downtown. It wont take you out to the suburbs. You have to change busses 10 times just to go down the street! Proponents of the ESB originally sold the “bus” as a single conduit that ran all the way across your enterprise. Frankly, this just never happened. Getting business units to “standardize” on a single vendor for ESB just hasnt been realistic. Why is this? Because every vendor has an “ESB” and some vendors have 3 or more ESBs (!) So you have an ESB slabbed on top of your Enterprise Apps from Oracle or SAP. You have an ESB from your app server vendor. You have ESBs from your integration vendor. So you end up with a half dozen different brands of ESB all over the place. So people are angry because the “Enterprise” in ESB never happened. This basically means that business unit silos are unaffected by ESB for the most part. All sales teams look for the “Enterprise License” for the products, so why not try to sell your product as a solution for an “Enterprise-wide problem”.
The “Magic Cure for BPM” Business analysts Rejoice!
The second expectation that really wigged people out was the concept of Business Processes orchestrated on top of an ESB. People had this great concept that you could take an ESB product to a business person and some standards based orchestration language like BPEL. BPEL was oversold, I think it must have been the “Business Process” in “Business Process Execution Language” that fooled people. Setting the expectation than an ESB by itself can solve the BPM problem is just naive. If you peel back the onion and look at “orchestration” flows within the ESB, you are looking at integration-logic, not the kind of logic that business people use to solve business problems.
So what’s the reality here? Reality is that you need to accept the fact that, while useful, the ESB was never designed to solve either of those problems. If you were conviced those problems would dissappear when you bought your ESB, sorry guy, you should have read the fine print. ESBs are actually pretty handy for solving integration problems. Should we throw out our ESB? No–just because an ESB is a poor environment inside of which to do BPM and a poor environment to eliminate Enterprise Silos, it happens to be a good environment within which to implement “Business Services”. Don’t think of an ESB as the thing ABOVE the services playing any kind of architectural role: think of the ESB as another kind of app server, and therefore a place inside of which you create and implement a service. Is BPEL a reasonable choice for implementing a service? It’s a little functionally limited, but sure, you could do it. So if you put the ESB in its proper place BELOW the business service interface, you can be made happy again. Leave the Enterprise Architecture and BPM to the other systems please.
So how do we go forward from here? Well, first of all give up on solving Enterprise Silo problems by either forcing a single brand of ESB across all silos or trying to program BPM in your ESB. There is no magic cure.
The (non magical) Solution
If you want to solve the problems of Enterprise Silos, you need a way to federate policy and enforce it across silos. This is what SOA Governance solutions ought to do. Get a SOA Governance solution. Is this enough? No! You also need Enterprise Architecture competency. You need a SOA Competency Center. You need to actually do the work.
If you want to solve the problem of BPM, get a BPMS. Will that please the business by itself? No! You also need to align processes with IT capabilities (services anyone?). You need to ensure that process models can be monitored with a Business Activity Monitoring (BAM) solution and you need to make adjustments (process optimization) over time. You need to do the work.
Sorry, like heart disease, you may need to make lifestyle changes. The shiny ESB you bought unfortunately wont get you all the way there. No wonder you’re mad.
My 2 cents,
Miko
