It’s rare to be in conversation about SOA without someone mentioning ESB (Enterprise Service Bus) or similar (message bus, service bus, etc.). Certainly there is nothing wrong with this if the discussion is focused on the implementation of a ESB. Unfortunately, rarely is this the case. Why should this matter?
Let’s say I am talking to a co-worker about some of the beautiful national parks in the United States. When we start talking about visiting them I immediately tell him he needs to rent an RV. I tell him this without knowing if he is married, has kids, pets, or anything about his vacation habits (requirements). I don’t know if he prefers to fly or drive or even if he has a drivers license. The fact is, I don’t know enough about his needs, likes nor constraints to recommend anything to him.
Similarly, it is not a good idea to talk about ESBs (or similar) when talking about SOA designs. ESBs (like RVs) do vary greatly, but they both have stereotypical traits, which could lead to confusion and ultimately a poor vacation implementation. Instead, we recommend using the term intermediaries. ESBs are to intermediaries as vehicles are to transportation. That is, an intermediary represents a class of solutions that assist in realizing an SOA. A vehicle provides transportation to a destination. More specifically, we define intermediaries as such:
Any physical entity that intercepts a message, performs a value-added function(s) and then forwards the message to the intended target.
So unlike the term ESB, an intermediary can refer to not only message/service bus, but workflow engine, router, accelerator, or an appliance. This may not seem like a big deal, but stop and think about the confusions that could occur. True, this may seem like a very subtle point, but as our experience has proven to us, does make a BIG difference.
Why give an answer before you fully understand the question?
Back in 2004 we learned this lesson rather quickly. We were evangelizing our SOA conceptual design to a company. When we started talking about ESBs we could see some feathers being ruffled. After this happened several times we realized that some individuals had preconceived notions on ESBs. Or simply had unwavering alignments with some specific ESB vendors. True, the ESB market has come a long ways in the last four years, but that does not change the fact that there are many use cases that do not require an ESB yet have a very mature SOA design.
Bottom line: we found it much less contentious to speak in generic terms, which really makes sense when talking about conceptual architectures (versus physical or implementation architectures). This has really helped us in our SOA efforts with clients, so feel it is important to share with the community.
Furthermore, SOA can be over-used, over-hyped and misapplied. And in some cases, SOA should be deferred until other enterprise problems can be solved. But I will leave that topic for Bill to cover next.
Print This Post
Good points and I couldn’t agree more. I have seen many companies start “SOA” projects by first buying an ESB and then trying to figure out what to do with it. Resulting in missed project deadlines, disenfranchised employees and ultimately resulting in not using their ESB or the complete cancellation of their “SOA” initiatives.
Allen,
Given your response I think tomorrow’s post should speak to you.
So is that what we did wrong?
It was only one of many factors in that situation. Politics (much more challenging than technology) and a camp of folks that already had an answer before knowing the question were two key factors IMO.