![](bg2.png)
different types of CIs. Different lifecycles may have
little in common: hardware assets may be specified,
purchased, configured, deployed and
decommissioned; software may be designed,
developed, tested and installed; contracts may be
negotiated, approved and fulfilled. Certain
transitions from state to state within a particular
lifecycle may require supporting approvals, but an
otherwise identical transition in an otherwise
identical lifecycle in a CI with a similar type may
require different handling.
Transitioning a CI from one lifecycle state to
another is itself a type of change that can impact the
IT environment. At minimum, state changes in one
CI often require changes in the containment
hierarchy rooted at that CI: e.g., decommissioning a
hardware asset normally makes software installed on
that asset unusable. A challenge, then, is to provide a
systematic way to propagate CI lifecycle state
changes across CMDB relationships given
heterogeneous CI lifecycles.
Although successful implementation of a CMDB
requires management of CI lifecycles, the same sort
of lifecycle management can be applied to objects
that are not typically thought of as configuration
items. For example, service processes themselves
have lifecycles but are too ephemeral for a CMDB,
and documents created on-line have lifecycles but do
not represent anything in the IT environment.
While a substantial amount of work has been
done in such areas as product lifecycle management
(see for example Stark, 2005), telecommunications
networks, and knowledge management (see for
example Siemeniuch, 1999); it hasn’t been
addressed considerably within IT service process
management. This paper describes a method for
managing CI lifecycles satisfying the following
requirements:
• CI types form one or more hierarchies (with the
degenerate case that the CI types form no
structure at all). CI lifecycles are associated
with CI types. CI types inherit the lifecycle of
their parent in the hierarchy by default.
• Lifecycles for different CI types may differ in
all qualities.
• Lifecycles may be altered dynamically (i.e.,
without removing the CMDB from service).
• Rules for propagating lifecycle changes across
relationships between CIs may be created
dynamically.
• Rules for requiring supporting approvals for
CIs entering or leaving certain states may be
created dynamically.
• Rules for requiring supporting approvals for
changes to any CI attribute when the CI is in a
particular state, may be created dynamically.
Figure 1: An example lifecycle with states of Not Ready,
Decommission, Production, Under IM, On Hold. The
Production state is protected.
This paper will then go on to describe one of
possible implementations of CI lifecycle
management and implementation involving both CI
lifecycles and lifecycles of non-CI objects such as
recovery plans.
2 METHOD
2.1 Lifecycle Representation
A lifecycle, as shown in figure 1, may be understood
as a directed graph comprised of labelled states,
together with the transitions between the states. The
states represent the legal states for a particular
category of item; the transitions represent operations
on the items (e.g., approval, placed into service, etc.)
that change the state of an item. States in a lifecycle
may be flagged to associate the states with particular
policies that restrict requirements that must be
satisfied to enter or leave the state.
In figure 1, the Not Ready state is flagged as the
initial state for the lifecycle and the Production state
is flagged as a “protected” state requiring an
approved request for change to enter or leave.
More completely, a lifecycle is comprised of a
lifecycle description, lifecycle states, state
transitions, and assignments as detailed in figure 2.
The lifecycle description contains a label for the
lifecycle; a flag marking whether the lifecycle is the
“default” lifecycle, to be used in the absence of
assignments and which lifecycle state is the default
state of the lifecycle; and a marker indicating which
ICEIS 2008 - International Conference on Enterprise Information Systems
156