Re: [service-orientated-architecture] Todd on SOA Governance

[Todd Biske]

Well, OASIS can have their terminology and I can have mine.  :)  One  
way or another, there does need to be enforcement of the policies  
associated with the SOA effort, whether we call it enforcement of  
policy as part of governance, or enforcement of governance policy.  As  
long as it happens and contributes positively to the success of the  
SOA adoption effort, I'm not one to get hung up on terms.

-tb
On Sep 28, 2008, at 1:13 PM, Michael Poulin wrote:


Well, "Governance enforcement" means an enforcement of Governance in  
English, am I wrong? (not an enforcement as a part of Governance)
Yes, we are close in understanding of Governance. I  only pointed in  
my initial post that OASIS SOA honors all your Governance processes  
except Enforcement. This is it.

- Michael

----- Original Message ----
From: Todd Biske <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Sunday, September 28, 2008 4:30:12 AM
Subject: Re: [service-orientated-architecture] Todd on SOA Governance

I'm confused by your response.  You said that the OASIS Reference  
Architecture does not include enforcement as part of governance, yet  
in your response, you refer to Governance enforcement.  The only way  
that sentence makes sense is if OASIS is equating governance with  
policies and nothing more.  If that's the case, I simply don't agree  
with that limited of a view.  Policies alone won't get you there.


I agree with the statement regarding review boards, that their  
primary responsibility is to enforce existing policy, not to create  
new policy.  That being said, someone needs to have decision  
authority when there are competing policies, as there always are.

I don't think we're really differing on the role of governance here,  
I just question the exclusion of enforcement from the list of  
processes associated with governance.  Adherence to policy is a  
responsibility of everyone, and I think adherence is different than  
active enforcement.  A speed limit sign doesn't enforce the speed  
limit, it only educates.  Individuals can choose to adhere or not  
adhere as part of their normal driving.  Enforcement of the speed  
limit is the responsibility of the police with jurisdiction on the  
particular road, which is part of governance, in my opinion.  A  
device in the car that could detect the posted limit and prevent the  
car from going faster than that speed would also be an enforcement  
mechanism, which again would be part of governance, in my opinion.

The only other terms that get used are audit and compliance, but  
these imply a more passive, after the fact approach, so I don't  
think they suitably characterize the processes.

-tb

P.S.  I think you misinterpreted my statement regarding traditional  
government.  The government provides law enforcement by establishing  
police forces that are paid for out of public dollars.  Those police  
forces do not establish law, they enforce it, so there is a clear  
separation of power as you suggest.

On Sep 27, 2008, at 3:44 PM, Michael Poulin wrote:


Standards not necessary have to follow common misunderstanding or  
misuse of things. We have many examples of such "moving with the  
flow". For example, an inaccurate use of word "service" in the  
standards for Web Services unfortunately locked service orientation  
concept inside IT for a couple of extra years (Web Service is not a  
services but just an interface and it may be bound even not to the  
Web protocol, i.e. HTTP).

OASIS recognises development and run-time Governances that are  
expressed via Policies. Absence or misuse of knowledge is not an  
excuse; Review Boards should be nothing more than an implementation  
of Governance enforcement, they may not perform any activities,  
including decisions, that are not permitted by governing policies.

May be it is only American position but "They establish laws, they  
provide and educational system, and they provide law enforcement"  
is the violation of separation and balance of the power: those who  
enforce the law should not be able to create it. IT harvests misuse  
of Governance in full: Management dictates the policies instead of  
following them. As a result, the IT does things how it can do it  
instead of how it should be done. The same relates to the business  
in many cases.

For example, if SOA development policy requires testing new  
services end-to-end while development team performs only SOAP/ 
interface testing, the project may not be released to production w/ 
o special review and exception granting. In this case, those who  
did not provided for testing share the same responsibility for  
future production bugs with those who granted the exception. As the  
result, the developer will not be the last one in the line and the  
first one for blaming; management has to admit its failure first  
because it violated or ordered to violate the policy.

This is not a bureaucracy, this is just an order, which guarantees  
concrete quality in the technology production process.

- Michael



----- Original Message ----
From: Todd Biske <[EMAIL PROTECTED] com>
To: service-orientated- architecture@ yahoogroups. com
Sent: Saturday, September 27, 2008 3:58:18 PM
Subject: Re: [service-orientated -architecture] Todd on SOA  
Governance

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 <gervas.douglas@ gmail.com>
To: service-orientated- architecture@ yahoogroups. com
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