SOA, ESB and Microsoft's refusal to blindly adopt nefarious terminology
In his article, Joe McKendrick comments on "Microsoft's fuzzy (but oh-so typical) ESB stance". Joe discusses how Microsoft is not jumping onto the bandwagon and naming something/everything that we ship as an ESB. He goes on to comment on Paul Kirill's analysis stating that Microsoft is positioning BizTalk and WCF as substantively equivalent to what other vendors are selling as an ESB.
Interestingly, Joe opted to make no comment on the statement by ZapThink's Jason Bloomburg that "Fundamentally, what Microsoft is putting together is much better than an ESB", but let's let that slide for now.
A few things on this:
- I am really glad that Joe noticed our determined position not to jump on the IT industry buzzwagon. This is a very deliberate stance because, as even Joe states, "What the heck is a traditional ESB?"
- Much the same can be said of "SOA". We have a fantastic platform upon which customers can build a Service Oriented system, but we don't sell or market "a SOA". We cleanly separate the purely abstract notions of Service Orientation from the industry overloading and overhyping of the term "SOA" and provide a clear map between the concepts of SO and the approaches one can take to build Service Oriented systems. Again, this is entirely deliberate.
Every time the IT industry coins a new term customers get confused and concerned that they've been doing things wrong in the past. All too often, vendors define these new terms as brand new ways of approaching/solving a given problem. These new terms rarely actually describe something new as such - they're usually just a refinement of what we've been doing/using in the past. The coining of these terms and the inevitable initiatives that follow are often just thinly veiled attempts by product vendors to make their current-technology.vnext seem more interesting, up-to-date, exciting and enticing, whilst promising improved productivity, return on investment, standards compliance, etc. Take IBM's ESB for example. The first characteristic that they mandate for an ESB is that it must be standards based. What is their message broker based on? MQSeries? Is MQ standards based? No - it's entirely proprietary! So how do they claim it's standards based? They've added a SOAP gateway to MQSeries and called it Message Broker! Boy, that must have stretched the guys at Hursley Park.
THIS is why (today's) Microsoft goes to considerable length not to jump onto any given bandwagon - to avoid further mudding an already opaque quagmire of poorly defined and loosely supported terminology. We'd much rather work to help understand a custmer's requirements and objectives and help the customer implement a solution that satisfies all the requirements rather than try to confuse them to the point that they give up and resignedly hire a legion of consultants to do for them what they could do for themselves.
I urge everyone to add a New Year's resolution to their lists to "Reject all unnecessary hype and to carefully examine any claims that ______________ will solve all my problems". I know I certainly will! [:D]
