Information Technology Reference
In-Depth Information
Just then, the ight was called. \Just wait," Alex said, as he picked up
his bag, \you will be hearing a lot more about policies in the conference, I'm
sure."
10.1 Why Do We Need Policies?
Often, when working on a design, decisions need to be taken where the
designer is aware that the best answer will change as things develop. This may
be because of changes in the organizational goals, the supporting technology,
or the environment in which the activity is to take place. The designer can
insure against any of these changes by saying that the parts of the specification
that are likely to change involve policies. This is a warning that the system
should be constructed so as to make changes easy to incorporate, and lets the
designer make it clear how much freedom should be allowed when planning
subsequent changes.
A system's properties do not generally change steadily throughout its life-
time. Rather, there are periods of stability punctuated by events in which the
rules governing system behaviour are modified. The ODP Reference Model
defines an epoch as being a period of time when something, be it an object, a
component or a system, has a particular kind of behaviour or obeys a partic-
ular set of rules. One example of an epoch is the period during which a policy
applies. Policy change events mark the boundaries between different epochs.
There can be many variations on this general picture. Occasional change
as part of the management of a running system is one, but similar considera-
tions apply when widely used components, such as beans or shrink-wrapped
packages, are deployed; the design envisages that the artefact produced may
be used in many different circumstances, and allows for a controlled degree
of tailoring as part of the deployment process when it is brought into use.
The adopter of such reusable components must define and install a set of
deployment policies. A typical system life history is outlined in figure 10.1.
Some of the things a system is expected to do are determined by broadly
based decisions about how the organization it serves is to operate. Thus, for
example, most organizations have some form of pervasive security policy de-
termining what level of control is to be applied in handling different kinds
of information, and who is to be trusted with what. The team that delivers
a major system that is unable to track changes in these access control rules
quickly and accurately as situations change will generally have a miserable
time, so tailorable security policies are almost, but sadly not completely, uni-
versal. There are many other examples, such as transaction approval policies,
discounting policies or delegation policies.
Another reason for introducing policies is to allow a system design to be
exploited in a number of different jurisdictions, or to respond to changes in
