Your Policy Isn't Big Enough

As we continue to mature the SOA Governance space, the Policy area appears to be the one that is the most immature.

Vendors that are focused on Policy have a big, big job ahead of them. In fact, we believe that the Registry/Repository area and the Testing area of governance will have a lot to do with policy definition and enforcement in addition to those tools that are called governance policy products.

The reason is because policy is a VBT (Very Big Thing). In fact, I think 3 years from now governance will really just be defined by policies and in so doing it will take all three aspects of governance to make policy work.

A simple example -- today’s Policy typically sounds like:

• “Interoperability checks”
• “ws-security verification”
• “Hit testing on XML documents (for you bit twisters like me)”

Pretty granular stuff. That’s not a very big policy.

In fact, the business won’t want to mandate policy that has much to do with things in XML and what standards you’re using. Of course they want standards to get the reuse and interoperability, but their version of policy will be:

• “I really need functional integrity on this particular transaction activity of the system”
• “I really need customer credit checks to always be accurate to within 30 minutes of the customer’s activity.”
• “I can’t allow stale data to be reported as customer’s current activity.”

All of these kinds of things – that’s Policy.

When the business talks about policy, they are not going to read standards definitions from OASIS. They are going to talk about what their business functions are and what kind of expectations they want to put on the systems that are implementing those policies. That is Policy – that is a Very Big Thing.

So, short and sweet, if you are talking to a vendor who has got a so-called complete SOA Governance Policy Management System -- I haven’t yet seen that thing. Their definition of Policy is way too small.

You’re going to have to sign off on the much bigger problem of Policy at the business level, which is what SOA should be all about. Remember, we are aligning IT to the business, but not if we force-feed a definition of Policy to business. Business will take on a "free-market definition" of SOA Policy, whatever the consortiums try to dictate.

When the definition of policy is business-aligned it’s going to require very rigorous, here’s the bad word, “TESTING” -- on a continuous basis of the functional integrity of the system as it is running. Of course, things like IT guidelines are good policy, Performance Expectations are good policy, Down Time and Notification and all of those other things, very good policy. But if it isn’t also heavily involved in the way the business wants to set up expected behaviors, it’s not big enough.

-- John Michelsen, Founder and Chief Architect, iTKO