ESB for an Orphan

Few years ago a SOA Guru employed by one of the vendors paid a visit to my country and discussed SOA issues with a group of local architects.

His reaction to my comment that a major goal of SOA is Business and IT alignment was that Business and IT alignment is only a buzzword. Real SOA is ESB based implementations.

I could find at least 4 or 5 Enterprise Service Bus (ESB) products which are superior to his company's solutions (and I am not the only one: Gartner Magic Quadrant and Forrester Wave at that time agreed with my opinion).

The limitation of that vendor's ESB solution is not the point. The point is expressed extremely in Burton Group's analyst Anne Thomas-Manes famous post SOA is dead Long Live Services:

In many cases we (IT experts) implemented SOA wrongly due to lack of Business alignment .

Another important point was discussed by ex-ZapThink's analyst David Linthicum in a Zapflash titled: Avoid Vendor Driven Architecture (VDA)!  

Many Enterprises begin their SOA initiatives based on a vendor's approach and architecture. As described in the beginning of this post, a vendor's approach is based usually on purchasing products (especially ESB products) as the first step of the SOA journey.

The following story or joke may illustrate the problem. A man entered a clothes shop and asked for a suit for an orphan.

A suit for an orphan is similar to an ESB for an orphan or an ESB for an Enterprise: a lot of relevant information is missing, and therefore the One Size Fits All is a wrong approach.

We have to know the orphan size: Is he tall or small? Fat or slim? – Is it a large enterprise, Medium size enterprise or Small Enterprise?

The orphan's age also matters: Is it reasonable to buy a suit for the next 5 years for a 13 years old orphan? No, he will grow up and the suit will be too small.

Is it reasonable to buy a suit for the next 5 years for a 22 years old orphan? Yes, probably he will not grow significantly.

An Enterprise growth rate could be a significant factor. An ESB product with limited Scalability could not be the right ESB for a high rate growing enterprise.

Is the orphan rich or poor? A poor orphan can not afford to buy an expensive good quality suit. A rich orphan should decide if he is buying a good and expensive suit or a cheap suit - Can the company afford buying an expensive ESB tool? (A question many companies may ask in a recession time like 2009), Even if it can afford, what is the Value proposition? Do they need a Strategic product for Long Term or a cheaper Tactical product for experimenting or Short Term?

And do not forget a key question: the suit usage. Will the orphan keep the suit in a cupboard without using it for few years? Will he wear it when he is playing football or basketball? Should he wear it daily or in special events?

Is the Enterprise Maturity Level high enough so the ESB product will be used adequately? Will it be wrongly implemented or not implemented at all?

My Take

I am not advocating an approach of SOA without SOA infrastructure products.

Advocating approach of that kind is another One Size Fits All approach.

SOA implementation strategy varies: some enterprises could implement a product as one of the first steps towards SOA. Other may defer products selection and implementation.

ESB implementation as a beginning of a SOA initiative is attractive:

• ESB implementation is a straightforward SOA integration solution. Many enterprises are using SOA for integration.

• An ESB implementation costs significantly less than EAI implementation

• It is standard based therefore easier to implement and skills availability is often high.

• An IT Infrastructure group is able to select and install it without Business or Applications teams involvement

• The current dominant vendor or vendors usually recommend implementing it in the beginning

Due to the reasons described above, many SOA implementations starts with ESB implementation. However, there is no free lunch (especially in 2009) and those implementing ESB should avoid of pitfalls such as:

• ESB is SOA – The SOA initiative is replaced by a Service Bus only implementation. SOA. The context is changed from a Business and IT context, Architectural context and Application and Infrastructure context to a limited technical context. The result of that context change could be lack of most of SOA benefits.

• Services are not SOA Services or Business Services – The so called Services are not services but other ill defined components or systems. If the Business people and the applications teams are not taking part in the ESB implementation process, the probability of falling into this pitfall is high.

• ESB implementation is an EAI implementation in disguise

Hybrid ESB products, which were evolved from EAI brokers supports non- standard based integration as well as standard based integration. It is easy to design and implement a traditional EAI based integration using an ESB tool. However, in that case EAI's difficulties and disadvantages will be part of the integration project.