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.