Policy Design


Designing policies becomes more complicated as you move from the elements to the services they support. Several infrastructures might be involved and the decisions made by the policy system must reflect more conditions, each of which must be tested and analyzed.

One important tool for assessing policy robustness as policies are designed is called Failure Modes and Effects Analysis (FMEA). It is commonly found in structured process and design methods, such as Six Sigma.

Using a spreadsheet or table with yellow stickies on a whiteboard, FMEA accounts for the following:

  • A description where a policy must be applied (failure mode)

  • A description of the impact (effect) of the failure mode

  • The severity of the failure mode, rated on a scale of 110

  • The causes of the failure mode

  • The frequency of the failure mode, rated on a scale of 110

  • The likelihood that the failure mode will be detected, rated on a scale of 110

  • A weighted Risk Priority Number (RPN), which is obtained by multiplying the three ratings: severity, frequency, and likelihood of detection

The power of the FMEA method rests on two foundations. First, it makes explicit the catalog of policy inputs required to make the policy successful, and it helps make explicit how a policy has to deal with them. Second, and more importantly, FMEA provides a discussion framework for collaboration by experts from multiple domains. These domains include applications, networks, servers, electricity, and so forth. If a policy can be thoroughly accounted for in an FMEA, it's a good candidate for automation; if not, the policy will likely not succeed.

Further discussion in this section is divided into the following subsections:

  • Policy hierarchy

  • Policy attributes

  • Policy auditing

  • Policy closure criteria

  • Policy testing

Policy Hierarchy

Policies can be organized into hierarchical structures that give advantages to providers and customers. Customers can have an overall policy that applies to all their users. They can assign additional constraints to different business units, for example, by allowing them finer-grained control.

One example would have a customer policy forbidding certain applications from running during normal business hours. Each business unit must conform to that organizational policy, but they can add more constraints that do not violate it. One business unit may add additional times when those applications are forbidden, for instance.

Hierarchy enables constraints to be organized and applied while still preserving the flexibility of lower-level policies that do not violate the basic constraints.

Policy Attributes

Policy attributes are important to consider as well. The attributes differ according to the needs of each policy.

Policies can be based on the initiating user. As an example, user A can use a particular service only at night and only at the bronze level. On the other hand, User B can use the same service anytime at a platinum level. This provides a great deal of granularity and customization.

The time of day will have a strong impact on many policies because it controls when certain services are available, or it changes the constraints on service quality. Thus, time can be an important attribute because certain activities can be scheduled for, and restricted to, times when they do not interfere with more critical service flows. Policy violations also identify those users who are trying to violate the policy or who do not understand it.

Policies can come into conflict with each other, just as they do in other work areas. Assigning each policy a precedence value helps resolve conflicts, with the highest precedence being the operative policy at that moment. Using precedence is a good practice because it forces administrators to evaluate the relative priorities of the policies they create and manage.

Policies might also need a lifetime to help with their administration and management. There will be situations where an administrator creates a policy for special situations. It is easy to define its lifetime and automatically deactivate it when the time expires. This saves administrative effort to track policies and prevents old policies from being used without oversight. Some policies can have a lifetime value of forever. They will exist until an administrator takes specific action to delete them.

Policy Auditing

Policy systems need auditing functions. I have worked with several organizations, for example, that had created large numbers of policies and then found that only a small percentage of them were actually used. Knowing which policies are heavily used also focuses time and energy for optimizing those that give the higher pay-off.

Policy Closure Criteria

Every policy must have clearly defined closure criteria. With the criteria, the enforcement mechanism understands when the policy has completed successfully or when it cannot proceed further. Closure might involve, for example, contacting a staff member as the last step.

Policy Testing

Many policy systems lack strong testing capabilities. Administrators must have confidence that the policies they are using will work properly in the operating range the policy was designed to handle. Policies can be tested in development laboratories or by hand by running through a set of possible scenarios.




Practical Service Level Management. Delivering High-Quality Web-Based Services
Practical Service Level Management: Delivering High-Quality Web-Based Services
ISBN: 158705079X
EAN: 2147483647
Year: 2003
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net