Blogger: Anne Thomas Manes
My friends over at ZapThink recently posted an interesting ZapFlash newsletter that has sparked another heated debate (i.e., permathread) on the Yahoo! Groups service-orientated-architecture discussion list.
Ron Schmelzer's missive last month was entitled "Why Service Consumers and Service Providers Should Never Directly Communicate". The article is directed specifically at "integration-centric techies" and (once again) attempts to explain the fundamental difference between SOA and integration. (Ron, Jason, and I have been beating this drum for a long time.) As Ron says, "to correct your misunderstanding, I need to speak your language: the language of integration technology."
Ron characterizes the typical integration-centric approach to SOA as EAI 2.0. It's a better form of EAI than in the past, but it's still fundamentally focused on integrating application silos (EAI) rather than dismantling the silos (SOA). Ron also does a nice job positioning the role of an ESB in EAI 2.0 vs SOA.
Nonetheless, I come away from this article with a sense that the technology discussion is irrelevant. (The article got a similar response from the SOA discussion list, also. I especially liked Stu Charton's initial response where he pigeon-holed the discussion as one related to "technical services architecture" and then went on to say, "Technical services architecture helps enable business agility to the same degree that Enterprise JavaBeans did.")
Don't get me wrong -- I concur with Ron's recommendation to use virtualized proxies and dynamic bindings between service consumers and service providers. (I don't recommend using a registry at invocation time every time to locate the proxy, though -- that should be a fall-back mechanism to be used only when you can no longer find the proxy.)
But Ron implies that the only way to achieve SOA is to use an advanced WS-* infrastructure that relies on WS-Addressing. As far as I'm concerned, a SOA infrastructure needs to be middleware-independent, not just vendor-independent. The virtualized proxy and dynamic binding mechanisms should work with any middleware -- not just with WS-*.
But let me get back to my point -- this technology discussion is irrelevant. As Chris Haddad mentioned in this blog last month, we're conducting an extensive research project using a methodology we developed based on the Contextual Design process. And I think I've become a bit jaded from the interviews I've conducted thus far. It has become clear to me that SOA is not working in most organizations.
I've talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They've deployed the best technology the industry has to offer -- including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can't sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.
More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration--which is the fundamental cultural shift required for SOA to succeed. The pervasive attitude is "What's in it for me?" As one of my interviewees said, "Altruism is not an enterprise strategy".
Thus far I have interviewed only one company that I would classify as a SOA success story. This company reorganized IT around functional capabilities (rather than business units) and established strong positive and negative incentives that encourage people to adopt a better attitude toward sharing. I'm beginning to think that this is the only path to SOA success.
I'd really like to find other success stories. If you have a successful story to tell, please contact Chris or me.