The question is not "to ESB or not to ESB", but how to adapt

When a friend forwarded me Joe's excellent ESB vitriol post analyzing the current round of "ESB-hate" -- sparked by a Dave Linthicum post -- my first thought was to respond on Dave's ESB technology point.  Not from a product point-of-view.  Rather, a technology architecture point-of-view.  Then, the question is not "to ESB, or not to ESB", but what infrastructure services does your organization require to be successful with SOA. Then, and only then, determine the most appropriate products to provide those services.  And don’t forget to look at what you already have in-house.   Boringly, I've been singing this tune since I wrote my "Networked Integration Environment" and related SOA and ESB series for PSG in 2005.

But then, I saw a link for Neil Ward-Dutton's post flow by on Twitter (yes, I tweet), and knew what I should really do was amplify Neil's words on the architectural purity aspect:

"As any experienced IT staffer who's been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don't act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it's the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses."

In the words of American poet Charles Olson, "What does not change is the will to change". So, what are doing to inject adaptation into your architecture?

Comments

[Mark Griffin]

"businesses don't act like machines that EAs can simply steer"

I thought that was a good statement. The first image that popped into my head was an architect standing on the deck of an aircraft carrier with a canoe paddle.

It is in the end all about adaptation as you pointed out. The dynamics of business is wide open all the time. I not sure how all the ESB bashing started but it is highly misplaced in my view. Singling out a particular type of technology as an issue for SOA doesn't make a lot of sense.

[surekha]

I do agree with EA being the change facilitators and change agents. This definition of the EA charter would need to include both Business Architecture and Technical Architecture as part of its' realm.

In order to be effective EA needs to be able to define a clear link or be able to demonstrate that a steel thread exists between business strategy, business needs, enterprise architecture tenets and finally the technical capabilities that need to be pulled together to deliver to the business. I would think that being able to show that EA is able to help with the shaping and execution of a business strategy would allow EA to be recognized as true change agents. IMHO, without being engaged in actively executing to the startegy EA would be unable to show that it has a positive impact and would not be able to win the respect of either the business or IT.

Now to comment on the ESB and its' role. It is as part of the mapping of business need to the technical capabilities and in keeping the interactions models flexible and yet monitorable that ESB would enter the conversation. It has a role but only in the context of meeting a business need and in delivering a business capability.

Here is a link to some related blogs of mine on the subject of "services", "service orientation" and "ESBs".

http://entarch.blogspot.com/2008/06/key-best-practices-what-is-service.html
http://entarch.blogspot.com/2008/02/separation-of-service-interface-from.html
http://entarch.blogspot.com/2008/05/enterprise-service-bus-vs-service.html

Best Regards.
surekha -