My experience with ESB adoption.

Background
I work in a medium sized company which has several silos of applications. Seeing the popularity of ESB and its relavance to our setup, our architects decided to implement it in our company. It was believed that our existing enterprise architecture was a good candidate for ESB. In short, we had different web applications (implementing different products) and behind that were several services (it was a mixture of socket based, restful and soap based services). The web application depended on the services for data and services.

After evaluations it was decided to go with Apache Service mix ESB. The plan was to create biding components as a proxy to the backend services and database and then build workflows in ESB which utilze the internal ESB service endpoints. The web applications were still there but common workflow logic was shifted to ESB layer. So now our architecture looked something like this.

Services (Socket, Restful, SOAP)
---------
Apache Service mix (providing SOAP interface to web applications)
--------
Web applications


The advantage we saw was building new applications were easier for two reasons primarirly -
1. Most of the common business logic used by different applications were moved to ESB layer. So new applications can just reuse the required services in ESB layer.
2. The web applications can just use SOAP interface to invoke the services (as opposed to invoking different types of interfaces previously).


Problems
In production enviornment we had two ESB nodes one primary and the other one as a backup. After implementation things looked fine initially. Then we encountered a problem. We deployed this new Service engine in ESB which reads message from a queue and processes it and provides a SOAP interface expose the data. This Service Engine component had a memory leak issue which was uncovered a day after production deployment. Now due to malfunctioning of this particular Service Engine all other services on the ESB were impacted. Which means some other critical Web applications dependent on the ESB services were impacted too. Eventhough no changes were done on those services.
Ultimately we had to undeploy this particular SE to make things normal.Traditionally when we had silos of Web application each implementing its own business logic and when we had such issues with one of the Web application only that particular application was impacted during the release. Other applications are generally not impacted.

In hub and spoke model we say that hub represents single point of failure. So isn't the enterprise bus also a single point of failure in case of ESB. I know there are several other advantages but this was one of the problems that still remains and we are yet to find a solution for this. Since there were two ESB nodes the situation was brought to normallacy after flipping to the backup node.
Previously the level of testing done for various products depends on its business value. Now in this setup since the ESB may host some less critical (business wise) components we are now made to test these all these components irrespective of its business value. This is another overhead that I noticed.