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]> To: [email protected] 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
