ESB, Does My Project Need it?

A key component of the Service Oriented Architecture (SOA) is Enterprise
Service Bus (ESB). Most often ESB is used as a silver bullet to clean up the enterprise integration spaghetti.

I came across quite an interesting perspective after a brief session with Jim Webber, an advocate of Guerrilla-SOA.
The following are some of the key reasons for using an ESB, as I have gathered from my past experience.

1. ESB Cleans up the Integration Spaghetti

A typical diagram of ESB based transformation is shown above. In reality, all the spaghetti gets into the ESB itself and remains concealed by it. Any issues with the complex wiring inside the ESB demands involvement of expensive ESB experts.
Subsequent to the ESB based solution implementation, enterprises would have to set up teams to manage the ESB and deal with the governance around the ESB usage.
Eventually, there is a possibility of the spaghetti outgrowing the ESB and spilling over, taking the integration back to where it started. The only difference this time is that the ESB will be part of the spaghetti.

2. ESB is Good for Business Process Orchestration

This is one of the major features that attract people to ESB. As a result, the business process gets into the ESB. The ESB now contains the critical business logic of the enterprise, apart from being just an integration backbone. This makes the whole system extra complex with business logic spread all over.

3. Other ESB Vices

Generally, the use of ESB results in a vendor lock-in. Business processes are almost always wired-in, using vendor specific languages and products.
Performance is another area where more dollars are spent.
l Performance hit with ESB is significant and requires considerable amount of money to scale. Sometimes, simple transformations that can be done easily with a programming language get implemented as an XSLT transformation.
l Some of the ESB products do provide good performance numbers. But more money is spent on scaling the infrastructure, without even a thought about the acceptable performance limit. In general, it’s acceptable for domain processes to start running in minutes or even hours. However, with the advent of ESB in the system, the tolerance for the process execution time by enterprise CIOs gets reduced to milliseconds and seconds.
ESB does come with pre-packaged adapters or transformers that may or may not be useful in the project. Hence, occasionally, there is a need for development of custom adapters or data-transformers to be used with ESB, which is an additional effort or learning curve for the development team that is already burdened with strict timelines.
Further, if most of the out-of-box adapters are not useful to the project, the licensing cost for these adapters is an unwanted expense.

Is ESB Useless?

No, it’s not; but ESB is not a silver bullet.
It assists the project in meeting the data transformation and communication requirements. It is a good candidate for dealing with disparate protocols (FTP, IIOP, and SOAP) between the interacting systems.
Most of the times it is preferred to have text based protocols (SOAP or HTTP) between services, which makes the system more manageable.

How do I Deal with my Integration Mess?
Business Chaos Modeling

As I understand, Guerrilla SOA advocates modeling the SOA integration based on the real world business processes. This is an interesting perspective.
As we all know, traditional software that models the business domain is the one that best meets the business requirements. Why can’t we extend this to SOA?
Just model the business interactions between services. If that is spaghetti, so be it. The business itself is running with so many interactions.
If a clean up is required, then the change should originate from the business domain. This business domain change will percolate down and would warrant a change in the SOA model.
I feel that this idea of modeling the business chaos among the services is very much in line with the philosophy of SOA, which promotes the alignment of software systems to the business needs.
ESB cannot definitely clean up the so-called chaos that originates in the business domain.

Business Process Orchestration

Business process is just business logic; why treat the process as a special entity? Implement the process like any other business logic. Such an implementation would ensure that the entire business logic remains as a single unit and is better manageable.

Managing Chaos

Manageability of the solution or system post-implementation is critical to any client. Although we model the business domain spaghetti in our system, it is critical that the spaghetti be manageable.
Monitoring and control interfaces to manage the complex interactions are essential.
Sometimes this needs a single point of control, and management necessitates the use of an ESB rather than the need to integrate various services.
Summary
A manageable business integration (SOA) with a thoughtful ESB usage, would definitely make the client happy and align the implementation with the business needs.

Hmm...! Quite a change of ideas in me after getting to know about Guerrilla SOA.