Question: How Do You Manage Your Policies?

Answer: Hopefully better than the NYC Department of Traffic.

Before you laugh at them, think very carefully about your model of SOA Governance.

Gartner analyst Frank Kenny uses a slide that shows SOA Governance containing four key governable elements:

1. Service Governance
2. Process Governance
3. Policy Governance
4. Profile Governance

I agree with Frank's model and think that it's really important to be able to fully decouple policies from the SOA infrastructure so that they can be properly governed. Proper governance enables policies to have have their own lifecycle, and even to be owned by a team separate from the service owner.

SOA What? Why is this important? Well, governance drives policies. Governance doesn't dictate "on your next release, you must..." Rather, governance demands compliance by a certain date or in a certain time period. These policies therefore have a life of their own - a life that needs to be managed. Also, often the "policy expertise" (think security or corporate governance) is often not in the development team. In fact, distributing "policy expertise" to the development often leads to problems of interpretation... developers are left to do their best interpreting policies as they implement their services. Again, security is a good example. Not all developers are security experts. And, it's easier (and cheaper!) to have security trained staff write a good policy, than train every developer on security policy interpretation.

Fully decoupling policy has other advantages as well if the product that implements the policy has the right abstractions built in to enable dynamic policy-service coupling. For example, a policy can be written for all "external customers" -- and automatically inherited by any new external customer as they are discovered (configuration implies a prior knowledge of the customer... don't get me started on how little we actually know about what our systems are really doing). Another great example, is Actional's ability to evaluate policy once, closest to the customer, as a way of: (1) optimizing policy calculation and overhead, and (2) driving policy to relate directly to meaningful customer/business experience, rather than "arbitrary" technical statistics like CPU load or response time.

Now that you've had time to think about the policies that govern your mission critical applications, I bet you can relate a little bit more to those guys at the NYC Department of Traffic. Scary, huh?