This was quite interesting, not so much for the content, but the fact that it came across (at least to me) as anti-ESB. Not blatantly, as I think Dan was trying to be somewhat neutral about the whole thing, but it sure felt like things were leaning that way. What makes it interesting is that after the Actional acquisition, at least according to the Actional 6.0 press release, Dan is now CTO of Sonic Software (although the Sonic management page doesn't reflect this). Perhaps this article was written before the acquisition?
As for the article itself, I wish he hadn't compared SOA to ESB. He actually makes some very good points on different ways of viewing IT, but then always tries to come back to this comparison which simply doesn't make sense. SOA is not an infrastructure product, so how can it possibly be compared to one? He speaks as if you have to choose one or the other. That's too bad, because if you look at his text around horizontal layers versus vertical slices, there's a lot of good content. -tb On Mar 9, 2006, at 3:21 PM, Gervas Douglas wrote: > <<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 right—just as the > ESB vendors know they are right. As someone with no vested interest in > either, I imagine you're both confused and amused—but 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 > > > > > > 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/
