Level: Introductory David Kaminsky (dlk@us.ibm.com), Software Architect, IBM
22 Mar 2005 Policy has been described as "a set of considerations designed to guide decisions of courses of action." In an IT setting, policies are used to guide decisions relating to the management of the IT infrastructure. This article introduces the concept of policy-based management, talks briefly about key standards, and discusses how policies can be structured.
Introduction
Long ago, my sister had a coffee mug that said, "life is too short to dance with ugly guys." The mug stated a policy that influenced her behavior: when she went to a club, she would rebuff the guys she considered ugly.
Here's another: "Neither a borrower, nor a lender be; for a loan oft loses both itself and friend, and borrowing dulls the edge of husbandry." In Hamlet, Shakespeare is stating a policy regarding borrowing.
For a more formal definition, I am partial to one from Calo, et al., "a policy is a set of considerations designed to guide decisions of courses of action." (M. J. Masullo and S. B. Calo, Policy Management: An Architecture and Approach, Proceedings of the IEEE First International Workshop on Systems Management, Los Angeles, CA, April 14-16, 1993) One important aspect of this definition is that it states that policies are "considerations" that "guide decision;"
they are not absolutes.
Imagine you, like Shakespeare, had a policy against loaning money, but your brother owed a large gambling debt, and the consequences of not paying it were, well, unpleasant. While your policy guides you not to loan the money, you might have a contravening policy that says a
broken brother is worse, and you hand over the money, perhaps attached to a lecture about gambling. I'll return the topic of priority later.
Perhaps my favorite policy came from the movie Star Wars when C3PO, upon receiving caution from Hans Solo, tells R2D2 to "let the wookie win." Apparently Chewbacca (the wookie in question) had a habit of detaching an opponent's arm upon losing. It is important to note that R2D2 had another implicit policy that said when he's competing, he should try to win, and this policy directly conflicted with Solo's sage advice. In the end, R2D2 let the Wookie have the game, valuing his arm over the victory.
IT policies
The policies used to operate an IT system aren't all that different from the policies listed above. The operations staff designs a set of considerations that govern how the environment is managed: what can happen when; who can access what; what must be achieved when; the value of accomplishing various tasks; and so on. While such policies seldom result in lost appendages, they can result in unhappy customers. In extreme cases, violating policy can result in imprisonment.
Here are some exemplary IT policies:
- "The customer database must be backed up nightly between 1 a.m. and 3 a.m."
- "Gold customers are to receive no worse than 1-second average response time on all purchase transactions."
- "Only management and the HR staff can access personnel records."
- "The number of connections requested by the Web application server cannot exceed the number of connections supported by the associated database."
These examples suggest an important observation: there are many policy types. The first policy governs an action that must be taken by the operations staff, backing up the database; the second talks about a quality of service to be maintained for important customers; the third
talks about access control; and the forth governs configuration.
While many taxonomies exist, I typically classify policies based on their outcome:
- Action policies define an operation to be performed.
- Goal policies define a state that must be achieved and maintained, but do not specify how that is to be accomplished.
- Result policies define a value or set of values.
- Configuration policies define an intended configuration.
The four examples above, as listed in the same order as their type:
- defines an operation, specifically a backup
- defines a state: the response time measured over the relevant time period must not exceed 1 second
- defines a TRUE/FALSE value indicating whether the user can access a class of data
- governs the configuration of a database and application server
In many systems, and all systems that are even minimally complex, these policies co-exist. The four policies listed above are just a small sample of those that might exist for even a simple online merchant. Understanding the various types can help identify which member of an operations staff would be responsible for implementing the policies. (Of course, in smaller businesses, the operating staff might consist of a single employee.)
At times, policies will conflict. As noted above, R2D2 had to choose between winning and keeping his arm. Valuing his arm over a fleeting victory, R2D2 lost. It's not just R2D2 that must choose among conflicting policies. Consider these:
- If it has been over 24 hours since the server last backup, back up the server. This is an Action policy.
- During business hours, disable the backup function. This is a configuration policy.
In most cases, the system runs its backup overnight, so the two policies are not always in conflict. Then Murphy's Law strikes: something goes wrong with the backup system, and the backup cannot be completed overnight. One policy will be honored; the other ignored.
There are many approaches to solving policy conflicts. One common approach is to assign priority to each policy, often as simple as an integer, and when conflict arises, the policy with the highest priority is honored.
In more complex systems, the priority is expressed as a formula. For example, if policies are derived from service-level agreements, and the agreements have monetary value attached, the policy-management system can attempt to maximize the total value.
In yet another approach, meta-policies are employed. Returning to two of the original examples:
- "The customer database must be backed up nightly between 1 a.m. and 3 a.m."
- "Gold customers are to receive no worse than 1-second average response time on all purchase transactions."
A business might have a meta-policy that states that "backup polices take precedence over response time policies." If, for some reason, these policies came into conflict, the system would favor policy 1 over policy 2.
Standards
For many of the policy types described above, corresponding standards exist. Below, I chose some of the more prevalent efforts, and for each, give a brief description and references that provide further detail. The list below is neither a comprehensive compilation of standards efforts nor a comprehensive treatment of the efforts mentioned.
Perhaps the most prominent standard for Action policies is the DMTF PCIM standard, variations of which have been adopted by the IETF and SNIA. In the latest version of that standard, PolicyConditions and PolicyActions combine to form a PolicyRule. A PolicyRole defines the subject of the policy, and is attached to a PolicyRule, as the priority of the rule. PCIM has been adopted fairly widely by networking vendors, among others. I should note that the DMTF defines a model (expressed as UML) for policies, but does not define a language such an XML schema. See Resources for more information.
OASIS eXtensible Access Control Markup Language (XACML) defines a language for expressing access control policies. In XACML, conditions and effects (results) are combined into rules, and rules are combined into policies. In typical cases, the result of an XACML policy is permit or deny access to the resource specified by the policy (scope in our terminology). XACML also includes the notion of obligations, which defines a requirement associated with the policy. For example, "members of the accounting staff are permitted to access tax records, but all such accesses much be logged." Logging is the obligating associated with permitting the accounting staff access. See Resources for more information on XACML.
Web Services Agreement Specification (WS-Agreement) defines a format for agreement. Each agreement defines a service level objective, along with the agreement terms, such as which parties are involved in the agreement. The service level objectives define an objective to be met and the conditions under which the objective is to be met. For example, in exchange for monetary compensation, one party might agree to provide a 2-second average response time to another party for a period of 30 days. This is a classic example of a goal policy, where the goal is a 2-second average response time. See Resources for more information on WS-Agreement.
The Web Services Policy Framework (WS-Policy) is another policy-related standard. Unlike the other approaches listed above, WS-Policy defines a wrapper that is designed to hold domain-specific policy assertions. The wrapper itself has limited semantics, leaving the details to the assertions. For example, WS-SecurityPolicy defines semantics for security policies that are embedded within the WS-Policy wrapper. Because WS-Policy defines a wrapper rather than a policy type, it is associated with all policy types. See Resources for more information on WS-Policy.
Anatomy of a Policy
IBM® identified four common elements when studying the various policy standards:
- Scope: what is or is not the subject of the policy
- Condition: when a policy is to be applied
- Business value: express the relative priority of a policy and allows a system to make economic tradeoffs
- Decision: describes the observable behavior or desired outcome of a policy
Consider a brokerage with an online presence that chooses to provide differentiated levels of service for clients depending on the size of the client's account. A policy might be rendered as:
- Scope: purchase transactions in the trading application
- Condition: if the client's account has over one million dollars in assets
- Business value: 100
- Decision: maintain 1.5-second maximum response time
The scope defines the subject of the policy, in this case, purchase transactions. The condition differentiates customers, in this case, selecting high-value accounts for special treatment. The business value in this case is a simple integral priority. The decision defines a goal: a 1.5-second maximum response time.
Now consider a second, related policy:
- Scope: purchase transactions in the trading application
- Condition: if the client's account has $250,000 to one million dollars (exclusive) in assets
- Business value: 90
- Decision: maintain 4-second maximum response time
This policy applies to the same situation, purchases, but defines a less-critical customer set: those with slightly lower asset levels, as indicated in the condition. As you would expect, such customers get don't get quite the same level of service, being guaranteed a 4-second maximum response time, compared to the 1.5-second response time guaranteed to the best customers.
It is important to note that the business value of the second policy is lower than the business value of the first. This indicates that when the policies are in conflict, that is, the system must choose between providing 1.5-second response time to the best customers and providing 4-second response time to the second-best customers, the system should ensure that the best customers are satisfied first. In general, this is the expected behavior.
Consider a more complex business value:
-
Policy 1: 30 "value units" per request satisfied
-
Policy 2: 10 "value units" per request satisfied
Unlike the prior example where simple priority wins, in this case, the system is trying to maximize overall value. If the system has a choice of satisfying policy 1 once and policy 2 once, then the system would be expected to prefer policy 1. If, on the other hand, the system could satisfy policy 1 once and policy 2 four times, then the system would be expected to prefer policy 2.
Such situations often arise when penalties are involved. The business values above might be rewritten as:
- Policy 1: $30 penalty for each transaction that takes longer than 1.5 seconds.
- Policy 2: $10 penalty for each transaction that takes longer than 4 seconds.
In this example, it is immediately clear as to why the system would prefer violating policy 1 once over violating policy 2 four times.
I should also note that policies can include information that does not fit any of the four categories. For example, a policy might have a name, a text description, and indication of who authored the policy, change history, and so on. I simply lump this all together as metadata (not to be confused with meta-policies) because it describes the policy, but does not influence how the policy is used.
To keep the examples succinct, earlier portions of this article focused only on condition and decision, but it is important to note that, in many cases, a policy is not complete without all four elements, and any robust policy language will support all four.
You might have also noticed that the four decision types correspond to the four policy types identified above. While other taxonomies exist, I find this delineation particularly useful when discussing autonomic systems.
Policy Management for Autonomic Computing
While I won't discuss it in detail here, I should note that Policy Management for Autonomic Computing supports three of the policy types: Actions, Configuration profiles, and Results. (The details of Policy Management for Autonomic Computing will likely be described in more detail in a subsequent article.) See Resources for more information on Policy Management for Autonomic Computing.
The developers chose to support these policy types because: (1) automated configuration management is quite important to autonomic systems, and (2) Action and Result policies are quite similar to one aspect of configuration policies, so after configuration management is implemented, Actions and Results are fairly straightforward.
The developers chose not to support goals because goals are hard. Just kidding. While Actions and Configurations can be supported in a generic way, the same is not true for goal policies.
Consider the goal policy:
- Scope: Company A's on-line ordering system
- Condition: During business hours
- Business value: 100
- Goal Decision: 2-second average response time
You could create a generic autonomic manager to monitor the online ordering system and determine whether the goal was being achieved. This simply requires watching data coming from the online ordering system and comparing the average response time to the 2-second goal.
Attaining the goal is substantially more complex. The autonomic manager must know how to adjust the configuration of the resource under the manager to maintain compliance with the goal. This requires custom code that is tailored to the type of goal (in this case, response time), and in many cases, code that is also tailored to the resource being managed; generic code simply won't suffice. Of course, goal-attaining autonomic managers exist, the IBM Enterprise Workload Manager manages response time and other goals, and Tivoli® Intelligent Orchestrator manages resource allocation goals. In the future, I expect a broad range of goal-attaining autonomic managers to hit the market.
Conclusion
Policy is much too large a topic to cover in a single article, and numerous books have been written on the topic. Together with the obligatory Star Wars and Shakespeare quotes, this article attempts to introduce some of the basic topics such as policy type, common elements of a policy, the basics of conflict resolution, and some prominent standards work. I encourage you to read the developerWorks tutorial by Dakshi Agrawal (see Resources) and download and test drive Policy Management for Autonomic Computing.
Resources
About the author  | 
| | David Kaminsky is a Software Architect in the IBM autonomic computing group, where he focuses on policy-based management systems. Before working on autonomic computing, David worked on storage systems, portals, pervasive computing, and Java technology. David is an IBM Master Inventor, and has a Ph.D. in Computer Science from Yale University, where he studied parallel and distributed computing. Two commercial products resulting from his work are still sold today. |
Rate this page
| 
