July 05, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
Neil Macehiter and Neil Ward-Dutton
Software Infrastructure for Business Value
Neil Macehiter and Neil Ward-Dutton of Macehiter Ward-Dutton offer their perspective on key software infrastructure issues, IT-business alignment and related things.

« The value of Agile: its all in the delivery | Main | Cyber-Ark and Courion partner »

October 06, 2006
OASIS' SOA Reference Model: not just for propellerheads

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.

Posted by neilwarddutton in Architecture |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/762

Comments Post a comment




Remember Me?

(you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code:



Most Recent ebizQ Blog Entries
ADVERTISEMENT
Subscribe
Blogroll
Disclaimer:The opinions expressed in this blog are solely representative of the blog's authors, and not of ebizQ


Subscribe to our Newsletters
ebizQ Weekly Gold Club Update
Live Webinar Updates
Updates from ebizQ Partners
ebizQ SOA Update
ebizQ BPM Update
ebizQ Security Update
ebizQ BI Update
ebizQ Open Source Software Update
Virtual Show Newsletter
ebizQ Web 2.0 and the Enterprise
Your E-mail Address:
Changing Tires on a Moving Car
Case studies and solutions for governing the continuous evolution of complex SOA systems

Date: Jul 15, 2008
Time: 12:00 PM ET
(16:00 GMT)

REGISTER TODAY!
Roundtable Discussion: MDM's Role as a Critical Enabler for SOA
Date: Jul 16, 2008
Time: 12:00 PM ET
(16:00 GMT)

REGISTER TODAY!
Archived Webinars | Upcoming Webinars

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map

Live Chat