Subject: Re: [soa-rm-ra] SOA Governance Discussion Strawman per the last F2F
I wanted to put together a synopsis/strawman of the governance discussion that we had at the last face to face. At the same time, we had also discussed at the F2F that we needed to get wider community participation and input into this work. To that end, I put that strawman into a public blog entry (Just as a point of order, I requested and was granted permission to blog about the work by Frank at the F2F); Oh yes, this was also an excuse to use my casual writing style - I'll defer the formal writings to Ken and Jeff :-)
Here are the relevant bits:
SOA & GOVERNANCE
The starting point of the discussion was the definition of SOA as defined in the SOA-RM which states that "Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains."
But when we speak of traditional IT governance, it usually means governance applied within the Enterprise; within a single ownership domain if you will. But in the case of a SOA implementation it needs to be applied across ownership domains, across Enterprises. And that requires a different set of carrots and sticks, perhaps something much more contractual in nature rather than something direct. And that in turn brings to light the fact that what one organization considers governance will be completely different from what another organization considers governance.
At this point, I proposed a definition of governance that is consistent with the above and has resonated very well with me. Requiring no original thought on my part, I quoted Anne Thomas Manes of the Burton Group who has said “Governance refers to the processes that an enterprise puts in place to ensure that things are done right, where "right" means in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern
adoption andimplementation of SOA.” With the exception of adoption bit, the committee members agreed that this was a good working definition. This also tied in very nicely with an earlier comment by a colleague, Ken Laskey of MITRE, that "Governance for SOA [...] is likely to parallel governance for traditional commerce", and that "There will be a range of governance depending on the perceived needs of the participants."
One of the items on my to-do list is to research the governance practices of large enterprises, especially ones in which the business units have a great deal of autonomy, to distill some lessons on what works and what does not work. At this point in time, I personally have not seen examples of SOA implementations that span Enterprises. Or rather Enterprises that are equivalent in authority/power/influence. Any examples you can share would be very appreciated.
As we progressed along this path, one of the items that became much clearer is that governance by its very nature implies the authority to govern. That authority can be formal or informal and could be codified in an explicit manner or implied. But in all cases, there is the concept of authority. Given this, implementing SOA governance requires:
- Formulation of polices that are appropriate to the domain
- The ability to enforce the policies
- The ability to obtain metrics on what is working and what is not
- Implementing feedback processes that can adjust the existing policies as needed
- Speaking for myself, and not for the committee at large, one of the items that we need to keep in mind regarding governance is that it should not just be the big hammer. It should also be the mechanism for providing motivators to moving to and doing the right things in a SOA. Not just the de-motivators. And the reality as regards to SOA governance is that it should be an extension of your existing IT governance where you add the SOA specific bits. I think the challenge here will be figuring out what that amorphous line is. It does not make sense in the SOA RA to document IT governance components, but there is definitely overlap and mutual support. Just as with EA and SOA.
- Above all, I think we need to realize that when we speak of formulating SOA polices, we are dealing with people and behavior and culture and not just technology. Which means it is messy and imprecise. As the old saying goes "Technology is easy, People? That's Hard!".
You can find the complete entry @
:- Anil John
:- Johns Hopkins University - APL
:- (240) 228-0612
:- E-Mail Response Time: 24 hrs