The Real SOA Governance Dos and Don’ts
Dave Linthicum had a recent post called SOA Governance Dos and Don’ts which should have been titled, “SOA Governance Technology Selection Dos and Don’ts.” If you use that as the subject, then there’s some good advice. But once again, I have to point out that technology selection is not the first step.
My definition of governance is that it is the people, policies, and processes that ensure desired behavior. SOA governance, therefore, is the people, policies, and processes the ensure desired behavior in your SOA efforts. So what are the dos and don’ts?
Do: Define what your desired behavior is. It must be measurable. You need to know whether you’re achieving the behavior or not. It also should also be more than one statement. It should address both behavior of your development staff as well as the run-time behavior of the services (e.g. we don’t one any one consumer to be able to starve out other consumers).
- Don’t: Skip that step.
- Do: Ensure that you have people involved with governance who can turn those behaviors into policies.
- Don’t: Expect that one set of people can set all policies. As you go deep in different areas, bring in appropriate domain experts to assist in policy definition.
- Do: Document your policies.
- Don’t: Rely on the people to be the policies. Your staff has to know what the policies are ahead of time. If they have to guess what some reviewer wants to see, odds are they’ll guess wrong, or the reviewer may be more concerned about flaunting authority rather than achieving desired behavior.
- Do: Focus on education on the desired behavior and the policies that make it possible.
- Don’t: Rely solely on a police force to ensure compliance with policies.
- Do: Make compliance the path of least resistance.
- Don’t: Expect technologies to define your desired behavior or policies that represent it.
- Do: Use technology where it can improve the efficiency of your governance practices.
There’s my take on it.