On SOA governance: for SOA, read CPOA?
A couple of weeks ago I was the happy recipient of a review copy of the excellent Todd Biske's
SOA Governance book. Todd's "
Outside the Box" blog is one of those rarities where every post is worth reading twice - so I was very interested to see whether his writing ability might stretch to something the length of a book! Todd's clearly established himself as someone who has a lot of insight on the topic of SOA Governance, so I was pretty sure I wouldn't be disappointed.
A number of other bloggers have posted detailed reviews of Todd's book, so I'm not going to do exactly the same here. Take a look at the
Amazon comments if you'd like to see what they said.
For me, I'll be brief: SOA Governance is a very good book indeed, in that it does something that so many technology and business management books fail to do: it breaks a complex and hype-laden subject down into very manageable chunks, and walks through the topic clearly and at a steady pace - but it still manages to move quickly enough to prevent the reader getting bored. It's not a perfect(*) book, but then nothing is - and if it had been, I would have been too jealous to write this. We need more technology/business management books like this, and we needed just such a book on SOA Governance. Well done Todd!
I knew this was a good book because it made me revisit some conclusions I'd already had washing around in my own head for a couple of years.
One of the things that I still find as I travel around is that when I get into discussions about SOA, there's way too much focus on the "S" and not enough focus on the "A". It's almost as if we've been blinded by technologies and standards which have "service" somewhere in their names, and aren't able to look at the bigger picture.
What Todd's book reminded me is that if you want to get real value out of service orientation, then it's the "A"rchitecture that really makes things happen. Todd's narrative keeps coming back to his definition of Governance, which revolves around People, Policies and Processes. And it also talks a lot about the concept of "contracts" in the context of analysing how service providers and consumers should work together in order to interact. Without People, Policies and Processes in place to guide your organisation down the right path, and without the concept of "Contract" to focus on the responsibilities that need to be described and assigned when service consumers and providers interact, such an architecture effort will likely lead nowhere. You'll end up with "just a bunch of services".
So - and this was the thought that occurred to me after reading Todd's book - perhaps we shouldn't really be thinking about "service" oriented "architecture" at all. It seems to me that what architects might find more productive to focus on is policies and contracts, not "services". Maybe "service" is better thought of as a concept that describes the outcome of this kind of architecture approach. And so maybe it's the case that there are two things in play here, and we're getting them mixed up: contract- and policy-oriented architecture (CPOA ;-) and service-oriented IT delivery?
What do you think?
(*) one thing I found rather strange was that despite a word at the front to reassure readers that they didn't need to know any technology detail in order to read the book, at a number of points you're suddenly confronted, out of nowhere, by XML fragments which (as far as I could tell) didn't really add any value. That's a tiny niggle though.
Labels: contracts, governance, policy, SOA, toddbiske
Policy interoperability - a step in the right direction
At the end of last week a webMethods'
press release popped into my inbox highlighting a recent demonstration of interoperability between the company's UDDI-based registry (
acquired with Infravio), HP's
Systinet registry and one of Layer 7 Technologies'
SecureSpan XML appliances. In a nutshell, the three companies showed how policies attached to services in a UDDI registry (using the Web Services Policy 1.5 Framework and Attachment candidate standard specification) can be exchanged with Layer 7's appliance for policy enforcement.
Prasad Yendluri of the Office of the CTO at webMethods had this to say:
greatly enhance[
s]
the interoperability of all of the components used to achieve policy-based governance
a point which was reinforced by Toufic Boubez, CTO of Layer 7 who claimed such interoperability provides:
a powerful standards-based solution for overall SOA management and governanceHere at MWD we certainly agree that a policy-based approach is essential for effective management of the service lifecycle. Policies should capture and enforce the obligations and expectations of service providers and consumers represented in service contracts to maximise the quality of the service experience. Interoperability of policies is also essential, given the variety of
service infrastructure technologies required to support any significant SOA initiative. However, as I pointed out
over a year ago:
WS-Policy does not deal with semantics: it provides a framework within which those semantics can be defined. Support for WS-Policy provides no guarantee that the way one vendor defines a particular policy can be interpreted and enforced effectively by another. That will require agreement on semantics.For these reasons, I doubt that the three participants simply installed the products, created some services and policies and then demonstrated policy enforcement: they first had to agree how the policies would be represented in WS-Policy.
Don't get me wrong: I think this is a positive step in the right direction. However, it's important for those involved in SOA initiatives to recognise, as I pointed out last year, that a number of significant steps still have to be taken to reach the semantic interoperability goal that's required:
It's not going to be easy! It will require the participation and cooperation of vendors of all shapes and sizes. Vendors, moreover, who are going to have to relinquish the control that ownership of policy definition can provide.
Labels: governance, HP, Layer7, policy, SOA, UDDI, webMethods
