Information Technology Reference
In-Depth Information
E
11
D
1
E
23
P
22
P
23
E
21
E
22
D
2
P
21
P
32
E
31
E
32
D
3
P
31
P
34
E
34
E
33
P
33
time
This figure shows the way behaviour derived from a specification evolves. Here one specifi-
cation is instantiated three times, giving three distinct systems.
D
i
is the deployment of systemi, with establishment of an initial set of policies for it.
E
ij
is thej
th
epoch of systemi; it is drawn as a straight line because the behaviour specified
by the policy is constant.
P
ij
is the j
th
policy setting event for system i; the change in direction of the system's
trace indicates that the system's behaviour has changed at these points, but remains
constant throughout the following epoch.
FIGURE 10.1: Epochs and points where policies are asserted.
regulation aecting the system's behaviour. Thus, for example, a nancial
system may need to be tuned to satisfy a particular national tax law, or a set of
audit requirements. The original designer will be aware that there are certain
key points in a business process where tax is due and must be calculated, but
the details depend on the locale, and may be changed by legislation that was
not even drafted when the system was first created.
Policy is a general concept, applicable to any of the viewpoints. However,
as these examples have shown, it is particularly heavily used in the enterprise
language, where there is a need to satisfy requirements both for agile business
processes and for stable and reliable provision of IT systems.
Policies, then, are a vital tool to let an organization make changes to the
behaviour of a system or subsystem in a controlled way, and, by so doing, to
let it respond to changing requirements and challenges.
10.2 What Is a Policy?
Loosely speaking, a policy is any point of potential variation in a spec-
ification that has been identified by the designer or the other stakeholders
