5.6 Properties of Metapolicies

Metapolicies require the greatest expressive ability in a policy-based management system. They combine the properties of normal policies with the concept of self-referencing and thus self-management. A policy controlling one or more regular policies is a metapolicy. A policy controlling some state in the policy life cycle or some supporting processes is also a metapolicy. Therefore, metapolicies are used for managing regular policies and their supporting processes.

It is also possible that metapolicies are only used to govern special areas of interest as presented in section . In case it becomes necessary to expand the application area of metapolicies, they are powerful enough to express the needed concerns, if the management system provides them with the needed API. Another possibility would be to support only passive metapolicies at first and active policies (where the API is needed) at a later stage or vice versa. This shows that the support for metapolicies can scale.

With the support and application of metapolicies critical situations can arise. These are the consequence of the dual roles of the management system and its self-management. For example, it is very easy to lock up the management system with a metapolicy: A metapolicy states that a component must wait for the reception of an event before it begins work. But the component which must send the event is also affected by this metapolicy. As a consequence the system is deadlocked and the metapolicy has created a conflict. This is a result of the dual roles of the management system where the target and subject can be the same object. As a consequence a subjects-targets-overlap [MoSl 93a] can happen.

If metapolicies are needed for normal management, either some constraints have been left out during the normal policy refinement process or the environment has changed. In both cases the policy must be reviewed and changed, rather than using metapolicies as a `quick and dirty' fix. For example, policy A governs a Unix domain, but from a certain moment on only Linux systems in the Unix domain must be governed by policy A. Deleting the non-Linux members from the Unix domain is not a good idea, because other policies may apply to them. A metapolicy can solve the problem: policy A is only applied to the Linux systems of the Unix domain. As mentioned in the `Exception' criteria, through this mechanism the fix is explicit and will not be forgotten for any reason. This supports the aim of management and creates no additional problems, because IT management in general is a supporting process and must be as clear and concise as possible.

Metapolicies have the property of self-application, because of their definition. An example is the setting of the responsibility for metapolicies. This is useful, but this is also an argument for restricting the authority to use metapolicies more than for normal policies.

Metapolicies are policies. For this reason, they inherit the same properties and the same life cycle. However, differences exist. These differences are not structural but have to do with the quality of the processes. Examination of examples has shown that the refinement process is less complex, because metapolicies do not have to deal with so diverse an environment as normal policies. A top level metapolicy could be: ``All policies must be signed off by an officer with authority.'' The refinement would be: ``Security policies must be signed off by a security expert. Availability by the customer support manager, performance by the system manager'', etc. These are implementable metapolicies, even though they seem to be very abstract. But with `security policies' it is clear who must sign them off, because at this level `security policies' is a class of objects, which can be instantiated, so no further refinement is necessary.

The development of metapolicies is, in some cases, parallel to normal policies, as it can be seen from the `Integration' criteria. Is a constraint been noticed in the refinement process (e.g., concerning the activation), a metapolicy will be stated in the policy's refinement process.

As with policies, the metapolicies need an appropriate information and system model. This models all the aspects of the managed objects and provides the basis for processing information. The metapolicies inherit this model from normal policies, as they sometimes have to directly address the system resources, as seen in the `Exception' criteria. Additionally, a model for the policy life cycle, the related support processes and its management must exist. Only with this model, the management system can manage itself using the same technique as for normal policies.