SOA and ESB Are More Than Different Answers to the Same Problem

Computerworld - As someone who for years has been steeped in the technologies that today are referred to as service-oriented architectures (SOA), I freely admit to thinking on occasion, Why would anyone want an enterprise service bus? On the other side of the coin, there's no lack of ESB infrastructure vendors that claim that there's no need for dedicated SOA infrastructure because ESB infrastructure does everything a company could possibly need. If you're a neutral third party with no vested interest in either, I'm sure it's a strange and confusing sight to behold.
For just a moment, let's forget about the ever-changing vendor positioning and product feature sets. A core reason for both SOA and ESB is to leverage and integrate systems more effectively. As such, there is significant functional overlap in the infrastructure. If you're looking to update your IT architecture, can you consider ESB and SOA interchangeably? Unfortunately, the two are radically different -- and the difference has nothing to do with technology. It's about philosophy. It's about ownership. It's about control.
Historically, IT has been organized into horizontal layers such as database, application logic, middleware and presentation. Because of the significantly different skill sets involved, it made sense that each of these layers had a dedicated team responsible for it. Ask any IT individual on one of these teams to give a breakdown of IT, and you will usually hear about these layers (with his layer, naturally, described as the most critical).
In contrast, if you ask business executives to break down IT, they will talk about vertical slices through the IT infrastructure: ordering, fulfillment, billing, etc. Executives tend to think of IT in terms of the business processes it supports, not in terms of the arbitrary technology layers underneath. No wonder IT is so often described as being out of sync with business.
In the deep dark past, integration was done as a natural part of projects that were solving business problems (addressing "vertical slices"). If one application needed information from another, the project team just built the integration themselves. Although this tied the need to a meaningful business context, these one-off, point-to-point integrations led to uncontrolled spaghetti of interconnected systems.
Out of this spaghetti was born enterprise application integration. The goal of EAI was to eliminate the spaghetti by forming another layer in IT -- the integration layer. In some organizations, this became a new layer, and in others, it became a new responsibility for the middleware layer. In either case, with integration the responsibility of one