OK, as I promised, it's SOA Governance Monday. OK, it's Sunday, but I bet you're reading this on Monday, if you're not on vacation this week. Let's begin with the fundamentals.
I received a call from a recruiter this week. He was looking for an "SOA governance specialist," somebody who could work on a government project team. After a bit of grilling by me, I found that he was actually looking for a person that had deep skills in a particular SOA governance tool -- the "knowledge of SOA governance was optional." Are you seeing the issue here?
The fact of the matter is that SOA governance, and governance in general, is really a people and process thing, with technology only coming into play to automate the processes and support the people. If you don't establish that, you're going to fail at SOA governance and thus fail at SOA, no matter how much technology you "invest" in.
No one has done a better job at explaining this than Todd Biske, in his recent blog post:
"Good governance is necessary for success, and open communication and collaboration is necessary for good governance. My recommendation is that if you are an in a position of authority (a policy setter and/or enforcer), you must keep the lines of communication open with your constituents and help them to set policies, change policies that are doing more harm than good, and understand the reasons behind policies. If you are a constituent, you need to participate in the process. If a policy is causing more harm than good in your opinion, make it known to the authorities. Sometimes that may result in a policy change. Sometimes it may result in you changing your expectations and seeing the reasons why compliance is necessary."
While many approach governance as defined in the realm of enterprise architecture, or governance as defined in the realm of SOA (I think they should be one in the same, but they are not in the real world), the winning strategy around governance is the education of the people who are the "enforcers," or set policies, and the people who are have to follow those policies. In other words, those that establish the rules/policies should know how to explain their value, and those that follow the rules should have the ability to push back. This back and forth will produce a good collaboration that will provide for healthy environment to produce and maintain good architecture.
The fact of the matter is that in many instances, governance, especially in the realm of enterprise architecture, becomes a position of authority, not a position of education. Thus, the rank-and-file feel that they are being pushed, not convinced, and the governance process become somewhat dysfunctional. The objective here is to create a set of well thought-out set of processes and a group of people around those processes that understand them and who are able to refine them going forward.
Once you get the people issues solved, the supporting technology is a cake walk in comparison. We'll talk about that next time.
Don't forget to follow me on Twitter.