Jeff over at Service Oriented Enterprise is grumpy about the approval of the SOA-RM specification by OASIS.

He says it's only really useful for a very specialised audience - the implication, I think, is that the ideas are so abstract that they're not of any practical use to real practitioners.

Now I'll admit that the spec is not the most accessible read in the world - it's kind of dry and abstract - but then it's a specification of sorts! And it's a heck of a lot more readable than many I've come across. Moreover I personally feel that it offers some really interesting ideas that have a lot of value to anyone still grappling with SOA; or to anyone who suspects that the majority (and over-simplified, instant-gratification) view of SOA that focuses on application development is bogus.

Specifically the document makes the following sensible observations/assertions (in no particular order):
- SOA is particularly suited to situations where multiple domains of control are at work and the solution needs to cross those domains
- you don't need to be using Web Services to pursue SOA
- services are distinct from capabilities and you need to understand this difference
- SOA thinking has to move beyond a focus on services, to a focus on facilitating interactions between services
- contracts and policies govern the conditions under which service interactions take place; but they play distinct roles and the differences are important.

If I've got one grouch of my own it's that the document doesn't, for me, call out explicitly enough the fact that what it means to deliver a service is the outcome of operational considerations, as much as it is about design and development. In short, a service is something you experience, not something you build. To really "get" SOA, you have to think about all the phases of IT value delivery - from design and development, through deployment and operation to change management and back around again.