Peeling the Policy Onion
By Bob Rhubart-Oracle on Nov 14, 2007
Part of the SOA Governance@Work series
In our last episode we took a look at how policies relate to various aspects of SOA. In this episode we'll peel the policy onion a bit more to look at what policies are and what they do.
The Wikipedia definition for the word "policy" includes this concise nugget:
"[A] deliberate plan of action to guide decisions and achieve rational outcome(s)."
The rational outcome for SOA is, of course, an infrastructure that supports seamless business/IT integration and greater enterprise agility. The enterprise that achieves that outcome is better prepared to compete over the long haul in a global business environment that evolves at speed even faster than that of the revolving door at a Malibu rehab clinic.
An SOA policy is a declarative specification of service characteristics that is applied to a service and enforced in order to insure that the use of that service contributes to the desired SOA outcome. In order to accomplish that, various categories of SOA policies provide specific standards and parameters that govern the design, development, testing, validation, deployment, consumption, (pause here to breathe), security, performance, behavior, and QoS (quality-of-service) of services in the SOA. Each category plays a critical governance role in insuring the SOA's ongoing viability and business value.
SOA policies offer a more agile alternative to hard-coding behavioral or other characteristics directly into services or applications. As fellow blogger Dain Hansen explains:
Systems are made more adaptive by specifying more of their behavior as policy (rather than procedural code) because policies are more concise, easier to understand and verify, and much simpler to change than code.
No static at all
SOA policies aren't static documents to be studied and memorized by architects, developers, or any other SOA stakeholders. While SOA policies generally have a basis in such documents, an SOA governance program that consists solely of static policy documents will be as effective as a Malibu rehab clinic. Polices in the form of static documents can only be applied and enforced through the direct action of a human being -- a process that doesn't do much for that person's popularity. In order to be effective, the management, application, and enforcement of SOA policies must be just as dynamic as the SOA environment itself.
SOA polices, like the services they apply to, are reusable software assets, and must be treated as full citizens in the SOA environment. As a reusable asset, a policy can be applied to multiple services. And like other SOA assets, policies have their own life cycle, and must evolve in order to accommodate changes in the business environment. This makes it important to be able see and understand the relationships that connect a policy to services and other elements in the SOA ecosystem in order to understand the impact of changes to the policy. (This relates directly to the visibility and traceability issues discussed in the first post in this series.)
This policy-as-asset idea is important also because SOA policies live in a distributed environment, involving not only multiple services, but also multiple governance participants -- the various tools involved in the SOA governance process. Different tools are used in the creation, application, management, and enforcement of different policies.
An SOA policy is comprised of a collection of assertion statements. Each assertion represents some specific aspect of what a service is, what it's supposed to do, or how it does what it does.
To illustrate that point, let's consider a hypothetical service we'll call Britney. Now let's apply a policy to that service. We'll call this policy Rebuild Career. The Rebuild Career policy includes the following policy assertions:
- Show up for your court-ordered drug tests
- Make sure you're COMPLETELY dressed before going out
- When driving, watch where you're going
Compliance with the Rebuild Career policy is based on Britney's pass/fail status for each of the assertions. The Britney service must pass each of the Rebuild Career assertions in order to be in compliance with Rebuild Career -- two out of three doesn't count.
And since Rebuild Career is a reusable asset, it can be applied to other services, like Lindsay.
Apply, Enforce, Manage
Policies are clearly an essential element in any SOA governance effort, but just having policies doesn't constitute governance. It's important to have well-defined policies covering all aspects of the services in the SOA. But even the most perfectly crafted SOA policy is worth exactly zip if it isn't effectively applied to the appropriate services, solidly and consistently enforced, and efficiently managed throughout the policy life cycle. Getting that job done requires more than a guy with a clipboard and a checklist. Without the right tools to create, apply, enforce, and manage your SOA policies, those policies might was well be printed up on company stationery, spiral bound, and tossed into the incinerator. Fun, but ultimately not cost effective.
We'll peel away more of the policy onion in future posts. In the meantime...
For more on SOA policies:
Web Services Policy 1.2 - Framework (WS-Policy) from the World Wide Web Consortium (W3C)
Other posts in the SOA Governance@Work series:
- Security: SOA's Velvet Rope
- SOA Governance is a matter of balance
- Survey Says... SOA Governance is Happening
- The SOA Governance Prescription
- Wielding the Carrot and the Stick
- Peeling the Policy Onion
- Policies: The Nuts and Bolts of SOA Governance
- SOA Visibility: Keeping the Wheels On