Service Oriented Architecture (or is it?)

This old (2003) article on xml.com about SOA (What Is Service-Oriented Architecture) is one of the more sensible descriptions of the term that I have come across - except that I don't see the value in a comparison of SOA and OOP (Object Oriented Programming - not to be confused with the fictional piece of software named OOP built by the team in Microserfs...)

To me SOA is mostly standard common sense of system interoperability and work distribution (using distribution as a non-technical term here). The whole business of building "SOA enabling software" to me totally misses the point. There is no SOA stack. Using SOA principles in designing some systems will dictate the use of some sort of messaging server or similar, but I don't quite understand how using millions of dollars worth of software from Fujitsu or the like is going to enable me to "do SOA". Remember that the "A" is for Architecture - it's a way of designing something, not a thing in itself.

I like the article's description of Loose Coupling but the failed CD OOP analogy is yet another example of letting a new buzzword get away from you. The whole SOA concept is a nice encapsulation of some common sense ideas, and it is also a good thing that this buzz is encouraging vendors to open up internal functionality to allow better code and logic reuse. But the reality is that the reason noone has been doing that consistantly is because it appears (on the surface) to be good for business to isolate your systems from everyone else. These days you only do that if you want to cop some stick from the EU.

Ah - rambling this is. Thus I have diluted the comprehesibility of the term SOA a little bit more!

Check out this little doozy in the Wikipedia page for SOA:

One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business.