policyvsmechanism

Policy vs Mechanism

by M Sravan

Introduction

We often come across the terms 'policy' and 'mechanism.' Although definitions of these terms are pretty straightforward, the difference between these terms is subtle and it has a wide range of applications in systems design. Let us first understand definitions of these terms. A quick search in a popular dictionary gave these results:

Policy: a set of ideas or a plan of what to do.

Mechanism: a process, technique, or system for achieving a result.

A mechanism is more about 'how' a particular task (possibly a policy) is done where as a policy is more about 'what' needs to be done. Once we understand this fact, we can clearly distinguish the usage of these terms. For example, consider an office with several employees. The office may have a policy like "All the employees need to be authenticated before they enter the office." As you can see, the policy just describes what needs to be done with out delving much on how it can be achieved. This policy can be enforced by one or more of the below given mechanisms:

1. Each employee needs to swipe his/her identity card on an RFID reader. The door will be unlocked only when a valid identity card is swiped.

2. Using a retina/fingerprint scanner, a biosensor will authenticate every employee entering the office.

Of course, each of the above mechanisms have pros and cons and we will not discuss them here.

Now that we know the distinction between mechanism and policy, we will look at a design principle - Separation of mechanism and policy.

Separation of mechanism and policy

This design principle states that mechanisms should not dictate(or overly restrict) the policies. Decoupling the mechanism implementations from the policy specifications makes it possible for different applications to use the same mechanism implementations with different policies. This means that those mechanisms are likely to better meet the needs of a wider range of users, for a longer period of time [wiki]. Also, hardwiring policy and mechanism together has two bad effects: 1. It makes policy rigid and harder to change in response to user requirements. 2. Trying to change policy has a strong tendency to destabilize the mechanisms. On the other hand, by separating mechanism and policy, it is possible to experiment with new policies without breaking mechanisms. We can also test the mechanism independently and thoroughly [AUP].

If we look at the 'office' example mentioned in the preceding section, the mechanism (RFID reader or fingerprint scanner) does not impose any limitations on the access policy (which employee needs to get access to which office area). The access decisions are made by a centralized server. This way, we can easily support new policies such as "Employees working in group A should have access to area X only between 9 AM and 5 PM." All we need to do is to update the access rules in the centralized server.

Another (and more popular) example is the X Window System. The designers of X made a basic decision to implement “mechanism, not policy" - to make X a generic graphics engine and leave decisions about user-interface style to toolkits and other levels of the system. Fashions in the look and feel of GUI toolkits may come and go, but raster operations and compositing are forever [AUP].

In practice, it might be difficult to have a strict separation of mechanism and policy like the one in our 'office' example. One difficulty in doing so is that a given mechanism needs to be generic enough in order to meet the requirements of various policies. However, decoupling the policy logic from the underlying mechanisms will certainly improve the system's

- flexibility (addition and modification of policies can be easily supported)

- reusability (existing mechanisms can be reused for implementing new policies)

- stability (adding a new policy doesn't necessarily destabilize the system since the existing mechanisms, which were thoroughly tested, can be reused to implement the policy)

References

[wiki] - Separation of mechanism and policy

http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy

[AUP] - The Art of Unix Programming

http://www.faqs.org/docs/artu/index.html