Given, the industry is incapable of delivering a consistent definition for SOA.
Given, practitioners diverge greatly in their skills and degree of understanding of SOA.
Given, the overloaded term “service” allows implementations that are not SOA to be labeled SOA.
Given, the number of SOA failures exceeds the number of SOA success stories.

Why then should we expend so much time and effort on something that seemingly has indications of leading away from the goal of building systems with less effort in shorter time?

There are few pockets of intelligence surrounding SOA out there that truly illustrates a body of architectural guidance that is unique and different then anything we currently have. However, most of what we hear about SOA today is just a re-packaging of distributed computing capabilities with better tools.

From this evidence, it would seem we would be best served to avoid buying into the SOA tagline and focus on what works. For example, non-binary marshalling techniques, such as XML and JSON, reflective programming languages, interface negotiation standards and standard Internet protocols.

After all the ‘A’ in SOA stands for architecture not asinine. The architectural guidance was supposed to lead to composable systems delivered out of configurable software components, which allowed for interchangeablity of the service providers. In essence, nothing has been created around SOA that is solely focused on development of systems without incorporating some recognition of future implementation.

And, while I’m on the topic, what’s all the hoopla around REST vs. SOAP Web Services? We’re arguing over an invocation protocol. Why don’t you just argue IIOP vs. RMI all over again? Then again, we can do SOAP over REST and fix the issue the way Sun did back in the 90’s.

I once again fall back to my “rats in the sewer” analogy that I used at a past XML on Wall St. panel. The community that focuses on developing distributed applications are like rats in a sewer. They are primarily focused on their simple life below the street running back and forth through the system of pipes. They’re very good at negotiating things at the transport level, but really don’t innovate. Occassionally, a smart rat evolves and decides to move to the street level and have a more fulfilling and intelligent life. However, soon that rat will be run over by the complexity of cars and people and the other rats will look at him and say, “see, we’re better off staying here below the streets and focusing on life in the sewer.”

It’s time to stop living in the sewer and really focus on the hard stuff, like enabling real composable applications that don’t require coding to wire the application together. There have been some great strides in this area, but primarily with wiring together user interfaces based on existing HTML-based applications. We have some great technologies available to us today that can really help us to deliver applications quickly to a very broad audience and that scale well. Let’s focus on building software services where they make sense as a means of sharing data and capability and not get lost in terminology we can’t even agree on.