Policies (session summary)

Abstract

The session on policies was led by Mark Dowson as keynoter. A more detailed description of this session was phrased as “Discussion of experience with domains in actual models — the semantic concerns of process models. What are lessons to be learned about model specific semantics? Model independent semantics?”. In his presentation Mark Dowson focused on the term policies. Policies were described as constraints that facilitate coordinated performance of process steps by multiple agents. Different kinds of policies exist, and there are different forms of policies. Issues regarding the relationship between policies and processes were raised, and ways of applying policies were discussed. Formal and informal as well as automated and manual policies and processes involving humans both at the organizational level and at the level of individuals were considered. The discussion generated by the presentation was lively. Examples of processes and policies in a variety of domains including non-software engineering domains were presented. A spectrum of terms were used for the notion of policy ranging from laws and standards to procedures and methods. In the following the reader will find a capsule summary of the findings. This summary does not reflect the flow of the discussions, nor does it include all the examples mentioned. Instead, the summary attempts to present the essence of the messages communicated by the participants by abstracting out some of the characteristics of policies. Policies can be described as constraints with respect to certain processes. They are statements either in terms of the notation describing the process, or in terms of a notation whose interpretation establishes a mapping to the process. There are different degrees of compliance to these constraints and there are a number of ways this compliance can be achieved. In different domains people have identified constraints with certain characteristics and given them special labels. This was evident in the discussion by the usage of terms such as advice, culture, guideline, goal, law, method, objective, order, policy, practice, preference, procedure, rule, standard, strategy, etc. Some of these terms imply particular degrees of compliance and forms of enforcement, while others imply that the constraints apply to certain types of processes and that the constraints may be in terms of the process, in terms of an abstraction of the process, or in terms the process of managing the execution of a process — the latter two requiring interpretation to establish a mapping between the constraint and the process. In the remainder of this discussion we will use the term policy to mean a constraint. Processes and policies can be characterized according to whether they have an explicit or implicit representation, whether their representation is formal or informal, whether the process and the policies are described in the same of different representations, and whether they are interpreted manually or automatically. Processes may not have an explicit representation. This is the case with processes that are performed by humans, have evolved and are part of their culture, but have not been documented. Similarly, policies may not have an explicit representation. They may be part of undocumented cultural guidelines. They may not be explicitly represented themselves, but may be embedded in a process that has an explicit representation. The representation used to describe processes and policies may have different degrees of formality ranging from a natural language and stylized natural language to formal notations with well-defined semantics based on a formal theory. Informal representations require interpretation by humans, while formal descriptions can be interpreted both by humans and by automation tools. The interpretation of a formal representation by an automation tool can be for the purpose of validating the static description, or is the enactment of a process program. Processes and policies can be combined in several ways. The first way is process construction through a human. Policies, described informally or formally, are examined by the human and reflected in the process definition. In the second way, process definitions and policy definitions exist as formal but separate notations. They are supplied to a process driven environment. This environment enacts the process and interprets the policies to check for their compliance. In the third arrangement, both process and policy definitions are described using the same notation and interpreted by a process-driven environment. One way of visualizing the enactment in such an environment is that both processes and policies are being executed as cooperating processes. Certain execution events are passed to the policy process. Synchronous verification of execution events corresponds to enforcement of policies, while asynchronous monitoring of events corresponds to checking for compliance. In the fourth way, process descriptions are refined from process templates. Policies are examined to make sure that the refinements are not in violation. In this case checking of policy compliance is attempted statically. The final way is a process construction process similar to the first way. The difference is that policies are formally expressed and the generation of process definitions is performed automatically. Several of the above methods embed policies in the process and by enforcing the enactment of the process enforce the compliance of the policy. Such an approach allows for the certification of a process to satisfy certain policies. The certification is dependent on the compliant enactment of the process. Other methods, especially ones involving interpretation of either policies or processes by humans, have a scale of compliance. Different degrees of compliance effectively provide different degrees of flexibility. Flexibility is necessary to handle exceptions, especially in processes involving humans. Compliance of a policy is always relative to the process it is applied to. For example, there may be a policy for always having a testing step done. This policy may be fully complied to. However, this policy does not specify anything regarding the quality of the tests to be applied. Compliance to policies is only meaningful if there is accountability to penalty for non-compliance. If there is no penalty to non-compliance, then there is no forcing function for satisfying a policy, and no purpose for the policy. In general, policies can be interpreted two ways. policies can either be viewed as restrictions, a mechanism for controlling the process. Or they can be viewed as a facility for specifying the scope of autonomy — allowing for authority and freedom by specifying the policies at the appropriate level of abstraction and by separating concerns. Processes may be constrained by an number of policies. Policies may be in conflict with each other. Such conflicts must be recognizable. In informal policies it is often left to the person interpreting the policies to determine how to resolve the conflict if and when it is detected. In many systems being modelled by processes and policies, priorities are assigned to policies specifying a precedence ordering regarding their compliance. Basically, the penalties for non-compliance of different policies are weighed against each other. Some systems allow for policies and processes to be changed. In such circumstances, processes and policies can be adapted to avoid conflicts between policies or between policies and processes. For example, in business organizations there is a hierarchy of policies. At the top level there are corporate policies. At the divisional level there are policies referred to as practices. Finally, these get refined into operational policies called procedures. A change to a corporate policy can cause conflict with other corporate policies, which can be resolved before it goes into effect. The new corporate policy also affects practices. Possible conflicts can be resolved by adapting the practices to the new policy, and by recommendation for adjustment of the corporate policy for otherwise unresolvable conflicts. The application of a policy to a process is a process itself. As discussed above this process can take on many forms. Note, however, being a process it can be governed by policies. The result is that we have policies on (the application of) policies. To be more exact these policies divide into policies on the creation of policies, policies on the evolution, i.e., change, of policies, and policies on applying and verifying compliance of policies. This leads to a model of an organization as a growing organism. Legislation is a basis for evolution of an organization. This is considered a deep issue. In an organization there are processes for producing products. These processes are managed. Management is a collection of processes itself. Some processes are concerned with monitoring and improving the production processes. Other processes are concerned with resource allocation across parts of the organization. The management processes are under scrutiny of other management processes. Those are the processes that have delegated responsibility for the execution of the particular process, and processes responsible for monitoring and improving management processes. In effect an organization can be viewed as the bootstrapping and on-the-fly evolution of a system of processes and policies. During the discussions a number of properties for policies and for commitment to policies were collected. Properties of policies included genesis, scope, binding, change, responsibility, interpretation, enaction, consistency analysis, validation. Properties of commitment included commitment to whom, commitment by whom, commitment known by whom, conditions of commitment, monitoring and reporting of compliance to commitment, and credibility of commitment. In summary, a number of other disci