SOA and ESB's - cue backlash

In a pretty funny article titled "ESB-oriented architecture: The wrong approach to adopting SOA", Bobby Woolf of IBM points out, rather sanely, that if you think that an ESB is some magic wand you can wave at your project Harry Potter style, mumble a SOA incantation and expect a fully formed SOA architecture to emerge then you deserve everything that is coming to you. I couldn't agree more. An ESB is a useful tool, but it isn't magic. If you think you merely have to deploy an ESB to SOA-ify your project, then you are putting the cart before the horse.

Repeat after me "There are no Silver Bullets".

SOA is an architectural approach, you need to concentrate on building services, services that align with business needs. The promise of SOA is business agility. It may be that an ESB will help you realise your vision quicker, since they are fundamentally useful, but you need to have the vision first. Then you can choose the right tool for the right job.

This is much the same message being put forward by Jim Webber on Guerilla SOA. Define what is it that you want to do and choose the right tool for the right job. It may be that you need an ESB, it may not. Definition will at the very least help you choose between ESB products.

This is also the message coming from Cape Clear: The End of Big SOA. Over the last years we have seen increasingly bloated and complex products and perhaps more disturbingly increasingly bloated RFI's. I've lost count of the number of RFI's that specify requirements for technologies I know that customers don't understand and more importantly will never, ever use. So good riddance to this trend. Part of the attraction of SOA was a move to simplicity. And the industry is now re-asserting this message.

Also the refocusing on SOA and not on the ESB, will hopefully shift the focus back to producing services. ESB's mix a couple of features:

• connectivity (email, HTTP, FTP, File, JMS etc, etc).
• mediation (transformation, routing, micro-flow).
• service-creation
• service-orchestration
  

Message-Oriented Middleware (MOM) typically refers to message-queue systems such a JMS. However, ESB's do enable a superset of MOM, which can accept messages in any format,from any transport and route and transform them. This is related to Jim Webber's MEST acronym which stands for Message Transfer. This is supposed to be a message analogy to REST. Wouldn't MT have been a more appropriate acronym (but then it wouldn't rhyme with REST I suppose).
These are the connectivity and mediation parts of the ESB (the bus parts). They are a generally useful tool. You can use them to:

• build an MO-system
• mechanism for versioning services.
• mediate different clients of services.

However, many people when they think of an ESB, focus only on these features rather than service-creation and service-orchestration. This is wrong. SOA is about creating services, the connectivity and routing part is important but should be considered secondary to services. Or put another way, routing / mediation is important, but you need something to route / mediate to.

So clarify your vision, define your business process, define your services, identify your clients and data formats. Then choose the right tool for the job. Most of the time you'll choose an ESB to help you implement the project, but this is not ESB-first. That would be like saying "I want to create a Real-time Flight Simulator! Step 1: I need a Java compiler" - you will most likely, but Step 1, is define the problem to be solved.

Powered by ScribeFire.