You could make the argument that policy enforcement at run-time is
part of SOA management, and certainly that's what most of the SOA
Management platforms do (e.g. SLA enforcement), although it's not
surprising that these products are all now calling themselves SOA
Governance products. I don't get a lot of heartburn over that, and
the term run-time governance has received enough marketing traction
that it would a mistake to not include it.
Independent of the run-time world and a technology centric view of
governance, the one thing that everyone thinks of when they hear the
word governance is enforcement, so it seems a bit absurd to me to
exclude it. Everyone envisions the review board of people taking a
look at work products and either rejecting or accepting it. That's
enforcement, plain and simple. Another analogy comes back to
municipal government. What are the services that nearly all
governments provide? They establish laws, they provide and
educational system, and they provide law enforcement. It would be
great if all of them also had measurement and feedback, but sadly
there are governments whose sole purpose is to retain power and don't
care whether the laws, education, and processes are actually leading
to a better life for the constituents.
-tb
On Sep 27, 2008, at 3:10 AM, Michael Poulin wrote:
Here is a very short comment to Todd:
the Public Review Draft 1 of OASIS SOA Reference Architecture
excludes *Enforcement* from the SOA Governance realm and places it
into the SOA Management.
I do not represent the SOA RA opinion in this post but this
separation looks logical to me. In particular, the activities of
enforcement may exist w/o Governance; the results of the enforcement
are directed not to the Governance at first but to the Management,
which later on can influence Governance with a feedback of policy
effectiveness.
Even in your post: "If education is poor, enforcement will likely
need to be more heavy-handed. Where possible,
automated testing and reporting can certainly make the processes
more efficient and cost-effective." That is, both heavy-handed
enforcement, testing, and reporting can and exist when Governance is
absent (OK, call it an intuitive Governance). It is not simple to
distinguish between Governance and QoS or even SDLC if we put
Enforcement into the Governance.
So, the process you mention is, probably, a bit more complex than
described. :-(
- Michael
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, September 26, 2008 5:38:27 PM
Subject: [service-orientated-architecture] Todd on SOA Governance
<<During my soapbox derby discussion at the SOA Consortium meeting, I
chose to discuss SOA Governance, and I thought that one of the
messages I delivered would be another appropriate post to highlight
some of the content in my upcoming book.
As I've said in this blog, SOA governance is the combination of
people, policies, and processes that an organization uses to achieve
the desired behavior associated with SOA adoption. This post, not
surprisingly , will focus on the process component. Previously, I had
a post explaining that governance does not imply command and control.
Those two words only bring to mind one of the four processes:
enforcement. There are three additional processes that your governance
effort must also implement. The four processes are:
* Policy definition
* Education and communication
* Enforcement
* Measurement and feedback
Policy definition is concerned with establishing the policies that the
governance team feels will result in the desired behavior if they are
followed. Without policy, the rest of the organization must either
guess what the correct decisions are to get to the desired outcome, or
involve someone from the governance team on every single project. The
first option is unlikely to lead to success, and the second option has
both scalability issues as well as being prone to variation based upon
the "tribal knowledge" of the particular person from the governance
team involved. Defining and documenting the policies is step one
toward gaining consistency in the outcome.
Education and communication is the next step, not enforcement. Just
because the governance team has reached agreement and documented the
policies doesn't mean they're going to be followed, or even known for
that matter. A formal, planned communication effort to educate the
organization on why you're adopting SOA, the desired behavior you hope
to achieve, and the policies that are being put in place to achieve
them is required. It's not a one time presentation to all of IT, but
rather a series of targeted communications for the various roles in
the organization, large group presentations, small team presentations,
blogs, wikis, and appropriate surveys and followups to ensure that the
communication is effective.
Enforcement is the third step. Even if your communication efforts are
incredibly successful, you still need to put processes in place to
ensure the policies are being followed. What you will find, however,
is the better job you can do on communication and education, the
easier your enforcement processes can be. If education is poor,
enforcement will likely need to be more heavy-handed. Where possible,
automated testing and reporting can certainly make the processes more
efficient and cost-effective.
Finally, the governance group must have measurement and feedback
processes to ensure that progress is being made toward the desired
behavior. If the desired behavior is not reached, something needs to
be changed, and it could easily be the policies, the processes, or the
people involved with governance. Accountability is lost if the team
puts policies and processes in place, but then does nothing to verify
that all that effort actually paid off.>>
You can find Todd's blog at: http://www.biske. com/blog/ ?p=506
Thanks to José Carlos for pointing this out on fb.
Gervas
