I wrote that I left open the possibility that in some scenarios. I am suggesting that smaller applications do not need an ESB just because they are using a few web services. However, it makes sense for a larger enterprise like Google to use an ESB.

The point that I did not cover directly is that if you choose to integrate using an ESB, it does not have to be BizTalk in a .NET environment. There are alternatives that will not break your budget and may even fit better anyway. My main point is that development teams that are moving toward an SOA architecture should not get excited about all these new buzzwords, like ESB. SOA has been charged enough as it is. IBM goes around selling SOA like it is something you can just install on all of your computers. The concept is being distorted and exploited by companies that make money on selling products that nobody understands.

If you choose to use an ESB approach, you should be informed about what is available and make sure you know what features you really need.

You are really wrong about your take on ESB. The ESB concept is about 100 years old, starting with the telephone switch board operators connecting all those service requests.

I worked for Google for 3 years and the whole thing is one giant ESB. Serious, without it, there would be no Google.