Ø
Implementing
feedback processes that can adjust the existing policies as needed
I am
working under the assumption that adjudication is implicit in the above.
Regards,
- Anil
:-
:- Anil
John
:- Johns
Hopkins University - APL
:- http://www.jhuapl.edu
:- (240)
228-0612
:-
:- E-Mail
Response Time: 24 hrs
:-
From: Michael Stiefel
[mailto:development@reliablesoftware.com]
Sent: Wednesday, January 03, 2007 10:24 AM
To: John, Anil; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] SOA Governance Discussion Strawman per the last
F2F
One of things that I think is missing from your list of
implementing SOA governance is the ability to adjudicate differences between
organizations or domains. You listed the corresponding items that correspond to
the executive and legislative parts of governance, but not the judicial.
Michael
At 10:55 PM 1/2/2007, John, Anil wrote:
All,
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 and implementation 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
<personal comments>
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!".
</personal comments>
You can find the complete
entry @
http://www.aniltj.com/blog/2007/01/03/OASISSOARAAStartingPointForGovernance.aspx
Regards,
- Anil
:-
:- Anil John
:- Johns Hopkins University - APL
:- http://www.jhuapl.edu
:- (240) 228-0612
:-
:- E-Mail Response Time: 24 hrs
:-