The Four Processes of 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.
8 Responses to “The Four Processes of SOA Governance”
Leave a Reply
Excellent summary. An effective teaser for your book!
I know “SOA” is the hot topic and is one of the primary topics of your blog, but…
Why isn’t this post, and your book, “Architecture Governance?” Don’t each of the 4 processes outlined here apply regardless of architectural style?
I’m sure there are topics in the book related to service management that only make sense for an SO style, but I imagine there are topics that are sytle-agnostic as well.
Is it time for a broader focus, something beyond just services? Anyone out there have a pure, services-only environment?
I’m glad you picked up on that Rob, as I could have named this post “The four processes of governance.” The difference between what you’re governing will be evident in the policies, which I’ll post about next week. That’s really why it is an SOA Governance book as a good number of the policies are really specific to service interactions. It wouldn’t take much to expand it to an Architecture Governance discussion, though.
Incredibly amazing, thank you for such an article. I have been reading about (Governance) for a while. I found out that there are many processes for SOA Governance, and at the end, it is the Architect decision.
Would you please accept my comment when I tell you – I do not like the idea of “enforcement”. It is not about the idea, because unfortunately, at some point there must be enforcement. All I am recommending you is to pick another name that does not imply (enforcement).
By the way, Good Luck with the Book. Can not wait to buy it 🙂
Hope it will talk a lot about Governance.
May I ask you another Question; if you don’t mind:
“I am currently studying for Ph.D. and my supervisor insists on a title that starts with (Optimizing a SOA based System”. My question is about (Optimizing) part. I kept telling him I could not find anything about Optimizing an architecture, but he insisted on the name.
The question is: Do you think the name is Ok?
Please consider replying me if you can.
—
Thank You
Thanks for your comments. You’re not alone in the feelings invoked by the term enforcement. Unfortunately, synonyms for it are likely to result in the same emotions. The key is to make the path of compliance also the most desirable path, so that active enforcement can be minimized, with any non-compliant scenarios being caught through automated auditing techniques. But, alas, as long as the tools are there for someone to do something different, it will happen. The point of enforcement is to catch the situation and raise it to the attention of the people that can make the appropriate decision given the context, which sometimes means granting an exception and sometimes doesn’t. Too often, that decision never gets escalated, which serves to breed resentment. Thanks again for your comments.
As for the title, it depends on whether you’re optimizing the architecture, or optimizing the system. Optimizing the system certainly makes sense, which is what your title implies. Optimizing an architecture is debatable, since the optimization is usually about the instantiation of the architecture, but I’ve seen plenty of people use the term architecture in a more concrete sense, as well, so it doesn’t bother me.
Thank you Todd for the relief you have given me. You are absolutely right that I am optimizing a system, not an architecture. However, my supervisor forces me towards the title I told you about. Still, You have no idea how much relief you have given me. As long as you have seen people using it the way my supervisor does, and as long as it doesn’t bother you – that means I can take it (even if I am not convinced).
May I ask you one more time about Optimizing a SOA based system?
I looked for (optimizing SOA) but of course with no results. I am thinking about (Governance) as a way to assure quality measures. Do you agree with me?
Well, one last request: Do you have time to be my supervisor in my Ph.D. ???
😉 Would be my honor of course. I really appreciate your time. Thanks in advance.
[…] Biske – The Four Processes of SOA Governance Todd Hoff – Is your cloud as scalable as you think it is? Comment […]
[…] will lead to the desired behavior, and by not forgetting the fourth process of governance (see my four processes of governance post), measurement and feedback. If you just establish policies and then focus on enforcement, but […]
[…] this blog, Jim Kobelius calls out the need for an “online presidential scorecard.” The fourth process of governance that I define is “measure and feedback,” so I think a scorecard makes great sense, […]