Tuesday, February 28, 2006

Service Oriented

How much of a key to Service Oriented Architecture's success as an enterprise buzzword is due to that first part- "service oriented"? I think for non-IT types that are tired of getting told what they can and can't do by the IT crowd. Having something focused on service seems to put the IT guys back in their place.

You then add into the mix Fowler's absolutely correct assertion that "SOA has turned into a semantics-free concept", and you have a recipe for entertainment in the enterprise. It's a great label to stick on whatever pet project you've been pushing for months, years, except now it comes with an extra helping of buzzword compliance which is sure to get it funded.

Sadly, it also applies to my pet project which is making applications respond to applications in addition to responding to humans. Unfortunately, it's a little difficult to get that one funded, it's more something that I want to fund across hundreds of projects.

From Fowler's site, here is the definition I am most strongly opposed to:
"For some SOA implies an architecture where applications disappear. Instead you have core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide."

That sounds like it's going to be hell for users. Sorry, you don't get an application, you get an aggregated UI. The thing that really makes that version of SOA completely evil, is that in order to produce an aggregated UI, your "service" has to present a portlet (or equivalent) version of itself.

On the other hand, the concept that you should achieve code reuse by introducing dependencies on other occaisonally running, provisionally funded systems might even be worse than what the above would do to users. Maybe we should just rename it dependency oriented architecture- the acronym seems much more appropriate.