I figured I'd weigh in on this, since I wrote the article! I actually drafted the article almost 9 months ago now (well before Sonic came calling). While SOA and ESB are apples and oranges, the article was actually about "SOA infrastructure" software versus "ESB" software. I think something got lost in the editorial process. I did, however, intend for the article to be a bit controversial. That said, I appreciate everyone's feedback.
When I wrote the article, I certainly had my opinions about the infrastructure for SOA (which were rather similar to Anne's), and the Sonic team had theirs - each of our opinions were based on our past experience of what we thought was important. As I was once wisely told, "engineering is the art of compromise" -- you can't design a product which is perfect at everything, you need to focus on what you view as most important (that's the "art" part). It was interesting coming in to the discussions with Sonic late last year because it really opened up a new line of thinking for me (and the Sonic team). Each of our companies had products (Sonic ESB and Actional SOAPstation) which overlap on a feature checklist basis, but the design points were significantly different because we had different views of what was important. Neither approach was right or wrong, they were different -- and these differences appeal to different types of organizations. By avoiding the urge to do a one-size-fits-all strategy, what's nice is that this allows us (Sonic) to work with customers to understand what characteristics are most important to them, so that we can propose a solution which may utilize the ESB alone, SOAPstation alone, or both together (because they are actually complementary in many use cases). That said, we'll obviously be cross-pollinating technologies as well. So, when Anne said I didn't argue much with her about SOAPstation being able to do everything the ESB could, she's right -- I didn't. The reason is that it's not really about the feature list. While I don't think the article I wrote was entirely right or complete, it wasn't too far off-base from what I'm seeing now. The organizational structure, political power base, budgetary distribution model, "layers vs. slices", etc. all play a (if not the) major role which type of infrastructure is appropriate for an organization (in the case of this discussion, Sonic ESB, SOAPstation, or both). In the end, the hardest thing to change is not the technology -- it's the organization. You can't let purity of architecture (whatever that means for you :-) blind you to the reality of your enterprise. The road to IT nirvana is littered with initiatives that failed because the organization couldn't be adapted to them. It's better to succeed in achieving 90% of your goals, than focus on 100% and fail totally. Cheers - Dan --- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > I had a meeting with Dan and Gordon yesterday. Dan is now CTO of Sonic; > Gordon is now head of Sonic Software products (everything except sales and > services). Dan reports to Gordon. > > It was an interesting experience. They were presenting Sonic ESB 7.0 to me. > I kept asking him why I should use an ESB when I could get all the same > capabilities from SOAP Station, plus get much stronger security > functionality. Dan didn't argue very strongly with me on that point... > > Anne > > On 3/9/06, Todd Biske <[EMAIL PROTECTED]> wrote: > > > > 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 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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/
