This is one of many aspects of the SOA RM that I disagree with. The term should be "policy enforcement" rather than "governance enforcement". Policy enforcement is part of a governance program.
Anne On Sun, Sep 28, 2008 at 2:13 PM, Michael Poulin <[EMAIL PROTECTED]> 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: [email protected] > 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 > > > > > > > > >
