<<As someone who has been steeped in Service-Oriented Architecture (SOA) for years, I freely admit to thinking, only occasionally, of course, "Why would anyone want an Enterprise Service Bus (ESB)?" On the other hand, there's no lack of quotes and articles written by ESB infrastructure vendors claiming there's no need for dedicated SOA infrastructure, since ESB infrastructure does everything a company could possibly need and more. Of course, I know I'm rightjust as the ESB vendors know they are right. As someone with no vested interest in either, I imagine you're both confused and amusedbut mostly confused.
For just a moment, let's forget about which vendor touts which marketing message with which feature set. A core reason for both SOA and ESB is to leverage and integrate systems more effectively. There's significant functional overlap in the infrastructure. If you're looking to update your IT architecture, are ESB and SOA interchangeable? The answer is no. The two are actually very different and the difference has nothing to do with technology; it's about philosophy, ownership and control. Historically, IT has been organized into horizontal layers such as database, application logic, middleware, and presentation, each requiring significantly different skillsets that warranted a dedicated team. Ask any IT representative on one of these teams to break down IT and you'll usually hear about these layers (with their layer, naturally, described as the most critical). In contrast, if you ask a business executive to break down IT, he will probably talk about vertical slices through the IT infrastructure: ordering, billing, procurement, etc. These executives tend to think of IT in terms of business processes, not the arbitrary technology layers underneath. No wonder IT is often seen as out of alignment with the business. In the past, integration occurred as a natural part of "vertical slice" projects ones that were solving business problems. If an application needed information from another application, the project team built the integration themselves. The advantage was that this tied the integration need to a meaningful business context. The disadvantage was that these one-off, point-to-point integrations led to a brittle spaghetti of interconnected systems. EAI was born to address this spaghetti problem by forming another IT layer, the integration layer, providing one uniform technology to be used for all integrations. In some organizations, this became a new layer; other times it became a new responsibility of the middleware layer. In either case, by making integration the responsibility of one of the layers, it can be well-controlled to avoid the spaghetti of the past. The diversity of the technologies needed to integrate caused integration tools to be complex technology stacks with involved special-purpose tools only a trained integration specialist knew how to use. This was an acceptable reason to form another layer. So, whenever a project needs integration, the team that owns the project requests the integration team evaluate the project and allocate resources to it. As is only natural, many project teams go to great lengths to avoid having to involve other, separately controlled teams in their projects because the extra bureaucracy and conflicting interests create risk and complexity, with the usual result of pushing delivery timeframes out.>> You can read this article in full at: <http://www.bijonline.com/index.cfm?section=article&aid=232> Gervas Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
