From:
Subject: What is Configuration Management
Date: Wed, 18 Jul 2001 17:28:08 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_NextPart_000_0107_01C10FAF.03271170";
type="text/html"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
This is a multi-part message in MIME format.
------=_NextPart_000_0107_01C10FAF.03271170
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.dis.port.ac.uk/~allangw/papers/pub97a.htm
What is Configuration Management
What is Configuration Management? Allan,G.W. (1997) Logistics=20
Spectrum,Vol. 31 No. 1: pp. 15-18, ISSN =
0024-5852
George Allan Department of Information Systems, =
University of=20
Portsmouth, Buckingham Building Lion Terrace=20
Portsmouth Hampshire PO1 3HE
The main purpose of this paper is to put forward a model for =
successful=20
Configuration Management by introducing the RAC Model. This paper=20
clarifies some popular misconceptions about Configuration =
Management and=20
Change Control and then goes forward to establish definitions of=20
Configuration, Configuration Management, Configuration Object and=20
Configuration Object Type. The RAC model takes account of the =
concept of a=20
Registry as well as Identity Control, Document Control and Default =
Reporting. The model is then extended to cater for Change Control =
and=20
addresses problems such as the Objects of Change Control, =
Resistance to=20
Change, Manifestation of Need for Change, Types of Change to =
hardware,=20
software, Networks and Communications. It introduces methods, =
procedures,=20
working practices leading to the eventual acceptance of Change. It =
further=20
addresses Causes of Change, the Outward Appearance of Change, and=20
Managerial Issues of Change. Finally, the paper profiles the costs =
of=20
Configuration management ,and highlights those often hidden costs =
of the=20
upgrade process with surprising results.=20
Most people concerned with the technicalities of computer =
departments,=20
the writing of software, or the configuring of hardware will agree =
that=20
there is a need for =93Configuration Management=94.=20
The vast majority of right-thinking people will realise that =
all but=20
the simplest of computer systems need to be managed so as to give =
a timely=20
and reliable output to the work, effort and data input. With the =
ever=20
increasing amount of software on the market and ever changing =
performances=20
in hardware standards it is often difficult to keep up with all =
the=20
products that are available; and even with the emphatic moves =
towards open=20
systems the compatibility of available products with your own =
current=20
system is often a worry. Many is the tale of long hours spent by =
the=20
technical department trying to get two pieces of software to =
communicate.=20
This is often as a result of trying to fit a square peg into a =
round hole=20
because some new application has come onto the market with very =
attractive=20
sales literature and been recommended for purchase without due =
regard to=20
whether it would fit into the present working environment.=20
There are other incidences where companies have subsequently =
found that=20
they have purchased the same product many times over by =
independent=20
internal departments who had no knowledge of what was already =
available=20
within the company. This has led to wasted licence fees.=20
There is also much confusion between Change Control and =
Configuration=20
Management. The panacea for all these ills is often sought in=20
=93Configuration Management=94 (CM). This paper aims to dispel the =
myths=20
around CM and outline a model for Change Control (CC) within =
Configuration=20
Management (CM).=20
There is a great belief that CM adds enormous quantities of =
paperwork=20
to the documentation of a computer system. Alternatively, some =
people=20
firmly believe that CM is a documentation system for keeping =
records to=20
show which software applications are on whose hard disc. Others =
consider=20
CM to apply only to software while it is being developed; others =
think=20
that CM really is the same as Change Control or Version Control. =
So let us=20
start with some popular attempts at sensible definitions and =
establish=20
from these a common base line for the progress of this paper.=20
=93Configuration management involves the collection and =
maintenance of=20
data concerning the hardware and software of computer systems that =
are=20
being used.=94 [SIMON & DENNIS - Ref 1]=20
=93CM embodies a set of techniques used to help define, =
communicate and=20
control the evolution of a product or system through its concept,=20
development, implementation and maintenance phases.=94 [SWEETMAN - =
Ref 2]=20
=93CM, a key concept in the Information Age, is a set of =
systematic=20
controls to keep information up to date and accurate.=94 [MORRIS - =
Ref 3]=20
=93CM identifies in detail the total configuration (i.e. =
hardware,=20
firmware, software, services and supplies) current at any time in =
the life=20
cycle of each system to which it is applied, together with any =
changes or=20
enhancements that are proposed or are in course of being =
implemented. It=20
provides traceability of changes through the lifecycle of each =
system and=20
across associated systems or groups of systems. It therefore =
permits the=20
retrospective reconstruction of a system whenever necessary.=94=20
This last quotation comes from BS 6488 the British Standard =
Code of=20
Practice for Configuration Management of computer based systems. =
[BS 6488=20
- Ref 4]=20
The British Standard BS 6488 : 1984 goes on to define the =
following=20
terms:=20
configuration management; configuration; system life cycle;=20
configuration baseline; configuration item and configuration =
status=20
accounting. While it would be foolish to ignore or deliberately =
contravene=20
these definitions, I shall draw on them and my own practical =
experience in=20
the following text and formulate what I hope will be an acceptable =
set of=20
terms and their definitions.=20
Let me first emphasise that by the use of the term =
CONFIGURATION I am=20
referring to all parts of a computer system which includes =
Hardware;=20
Software Application Packages; Bespoke Software; Operating =
System(s)=20
Software; In-house developed and maintained Software; =
Documentation in=20
Manuals and On-Screen Help Files; Communication Interfaces; LANs, =
WANs and=20
all peripherals; Working Practices.=20
As an illustration consider a reasonable model of a distributed =
computer system.=20
Figure 1: The Spatial Model
This diagram represents the hardware and some of the people . =
The=20
software is implied. What such a diagram does not show is the=20
documentation and the working practices that constitute the =
configuration.=20
The end product of an effective CM system is an awareness of =
the status=20
of all components at any given instance in time. Any computer =
system=20
supporting a real commercial concern or business will be =
undergoing change=20
almost continually to keep that commercial business viable and=20
competitive.=20
Therefore there will be an almost certain call for existing =
hardware to=20
be upgraded, new hardware to be purchased, obsolete hardware to be =
replaced, modern communications equipment to be installed, =
networks to be=20
developed, new software packages to be added, existing software to =
be=20
upgraded, etc. etc. etc.=20
Without careful planning and consideration many mistakes could =
be made=20
- resulting in money and time being wasted. The support staff =
should be=20
able to give a =93snap shot=94 of the individual components of the =
whole=20
configuration and advise on whether certain purchases or changes =
are=20
advisable, possible with proper care or even impossible to cope =
with. In=20
many systems the technical staff operate on a knife edge of =
nervous=20
tension caused by a lack of confidence in whether changes will =
work or=20
cause disaster.=20
Hardware is something that most us of can identify. We also =
understand=20
that each item of hardware will need some sort of software; we =
further=20
usually appreciate that each item of hardware and its associated =
software=20
deserves an operating manual (usually to be consulted if all else =
fails);=20
and that when many items of hardware and software are combined to =
form a=20
system then each individual user should observe set procedures for =
getting=20
jobs done. We are now beginning to get into the parts of the =
system that=20
often get ignored (or deliberately forgotten) when considering the =
CONFIGURATION as a whole.=20
Over the last 15 =
years or so=20
CM has evolved to include:=20
Identification Method=20
Control Mechanism=20
Audit Procedures=20
Configuration Status Reporting
Definitions
The Configuration
That group of all the configuration objects that are linked =
together or=20
stand separately but together form the computer based system under =
consideration. When all objects are considered as a whole this =
constitutes=20
the configuration.
Examples
It is possible to consider a large and complex computer based =
system as=20
being made up of a number of smaller, easier to define =
configurations.=20
Thus a commercial company may run a LAN configuration for office=20
management which interfaces to a MIS configuration for management=20
discussions and decisions, linked to Admin configuration for =
general=20
administration and payroll etc. These might in part be linked to =
external=20
configurations via remote links for the wider context of the =
commercial=20
aims of that company.
Any one configuration must not be allowed to get so large, =
complex or=20
cumbersome that it becomes unmanageable.
It should be noted that this configuration will never be =
static. There=20
is possibly more worth in considering =93the system=94 as a =
generic descriptor=20
of the entire computer based system if it is ever found necessary =
to have=20
such a descriptor.
Identification Method
Each item in the conputer configuration must be labelled =
somehow, so=20
that it can be uniquely identified later.
Examples
A PC processor identified by make, model and serial number.=20
A PC keyboard identified by make, mode and Identity Code.=20
A software Operating System identified by its name and =
version=20
number.=20
A training manual identified by its title and release =
number.=20
Control Mechanism
It is necessary to have some method to control changes to the =
hardware=20
and software and sometimes the other resources in the computer =
system.=20
Without any control over the component parts it is obvious that =
very soon=20
no-one would have much of an idea of currency of hardware and=20
compatibility issues would be a problem. Unfortunately, the =
control is=20
usually lacking in commercial/industrial systems and that is a =
main reason=20
why so many computer systems are difficult to manage.
Auditing
I now return to the function of the Audit process. With the =
popularity=20
of BS 5750 and the growth in Quality awareness the Audit has =
become part=20
of many commercial business practices. With my proposed model of =
CM the=20
audit procedure will cease to be annual, biennial or triennial=20
trial-by-fire. Since the information should all be to hand, albeit =
archived and therefore need to be recalled in time for a well =
planned=20
audit, the actual process of the audit will become little more =
than a=20
virtual reaffirmation by an independent body in the case of a 3rd =
party=20
audit, by an independent person in the case of a 2nd party audit, =
or by a=20
nominated person from an independent department in the case of a =
1st party=20
audit.
Status Reporting
Status Accounting has traditionally been the recording and =
reporting on=20
the configuration status and configuration change with the passage =
of=20
time.
This information was an historical record of the development of =
the=20
computer-based system and was occasionally used in management =
decisions.=20
In my proposed model this functionality will be subsumed into the =
domain=20
of the Registrar. All information pertaining to status of the=20
configuration (present and past) will be available within an =
efficient CM=20
registry. Most historic data will of necessity be archived and =
could be=20
recalled for management decisions. This is in line with good =
practice in=20
any well run computer system.
Some CM systems are little more than a list of all hardware =
items on an=20
inventory with a similar list of all software packages that have =
been=20
purchased and require licensing action. I propose that as far as =
possible=20
like-should-be-kept-with-like.
In its simplest form CM can be thought of as a list of all the =
named CM=20
objects with cross reference to linked objects.
Hardware
Software
Manuals
Codes of Practice
Work Station ID=1234
MS-DOS V6.0
User Manual no. D5
xyz/123
MS Works
User Manual no. W17
NIL
PC Model ALLANGW ID=5678
MS-DOS V6.0
In-house booklet abc
abc
MS Word for Windows
User Manual 123
345xyz
MS Office
User Manual 234
189 etc.
MS Project
User Manual 345
-
Corel Draw
User Manual 456 & Short Notes 789
-
Table 1: Example
With careful and thorough systems analysis a reliable system =
could be=20
created logically with E-R diagram leading to the construction of =
a=20
Relational Data Base for almost any configuration within any =
commercial=20
company. It must be pointed out that there are two issues which =
the above=20
has uncovered and often escape the attention needed in developing =
a=20
reliable and effective CM method.
Objects must be identified uniquely.
The link between objects must be established.
Traceability
One important function of CM is to identify the links within =
object=20
type and provide a measure of traceability. Traceability links one =
CM=20
object to another at object level.=20
Generic and specific links between CM objects.
NB Software object could be:-=20
Code Unit; sub unit; reusable parts of code; function; library=20
procedure; file; Design specification; Requirement specification;=20
Functional specification; Test case and data; Documentation.=20
=93To make changes to the (software) system, programmers =
normally need to=20
understand the relations among components of the system, e.g. the =
contents=20
and purpose of modules in the system, their relations to other =
modules in=20
the system, and the historical context in which the modules are=20
developed.=94 [RAMAMOORTHY - Ref 5]=20
=93To maintain correctly information about software objects and =
all links=20
between them manually is a daunting and sometimes near impossible =
task. It=20
is possible to use reverse engineering tools to generate some of =
the=20
information stored in the database directly from programs.=94 =
[CHEN et=20
al - Ref 6]=20
Traceability should also be considered at the system level =
(synonymous=20
with Integration & Test and Version Control) and at Life Cycle =
level.=20
Thus integrating the software objects with hardware, comms =
objects,=20
documentation etc. This will achieve full CM throughout the entire =
configuration=20
The question of traceability is the key to converting what is=20
effectively merely a list into a proper CM method.=20
When Does A Computer System Become A =
Configuration?=20
There are very few =93brand new computer systems=94 around =
these days. The=20
question =93When does a computer system become a configuration=94 =
is best=20
solved by suggesting to management that the real answer is =93As =
soon as CM=20
is adopted=94. There is a tremendous amount of work needed to =
catalogue=20
every CM object into a working CM database tool and very careful =
thought=20
has to be put into the choosing of the right CM tool for the job. =
I would=20
beg any organisation to do a proper analysis of their own computer =
system=20
and all its support function (that is the functions that the =
computer=20
system provides to support the commercial operations of that =
company)=20
before buying a round hole in which to try to squeeze a square =
peg. There=20
are already many packages on the market and it is not the purpose =
of this=20
paper to compare and contrast these commercial products.=20
One important point which must be emphasised is that CM should =
be part=20
of the lifecycle of the configuration. New lifecycle models offer=20
alternatives to the traditional waterfall model especially when=20
considering the software development techniques such as reusable =
software,=20
prototypes (throw-away and evolutionary), automated software =
synthesis=20
from requirements. [BERSOFF & DAVIS -.Ref 8]=20
Many texts talk of =93the baseline=94 of a configuration. This =
paper=20
contends that there will be a =93momentary snap-shot baseline=94 =
at any given=20
instant in time. Even at that snap-shot instant in time some CM =
objects=20
will be undergoing a change in status or state. The reality is =
that the=20
whole configuration will be evolving all the time. This is not to =
be=20
feared or fought against, but should be seen as a natural =
progression in=20
the life of any thriving, living, growing business or company. The =
confidence element comes from knowing that the configuration is =
changing=20
under control and that that control is governed by the technical =
support=20
staff (and not the other way round).=20
This paper has attempted to cover Configuration Management from =
a=20
practical point of view. It has tried to introduce the concepts=20
fundamental to a successful operation. A good system of =
Configuration=20
Management within ANY computer based system must lead to an =
improvement in=20
effectiveness of that system. This will manifest itself in the =
more=20
efficient running of that system, aided by faster responses to =
questions=20
concerning that computer based system and by a more efficient work =
force=20
who have the confidence in that computer system and who can handle =
changes=20
to that system with confidence and the minimum of fuss and =
disruption to=20
the real business in hand. It is hoped that this paper will form =
the basis=20
for meaningful discussions at an academic, technical and practical =
level.=20
References
Ref 1: SIMON J & DENNIS G - =93Methods of Tracking =
Intersystem=20
Configuration Management Dependencies=94 Journal of Systems =
Management, July=20
1993=20
Ref 2: SWEETMAN S - =93Utilising Expert Systems to Improve the=20
Configuration Management Process=94 Project Management Journal =
Vol. 21,=20
March 1990=20
Ref 3: MORRIS M. - =93Configuration Management: Getting the =
Facts Right=94=20
Inform IFN ISSN 0892-3876 Vol. 5, May 1991=20
Ref 4: BS 6488 : 1984 British Standard Code of Practice for=20
Configuration Management of Computer-Based Systems.=20
Ref 5: RAMAMOORTHY et al - =93The Evolution Support Environment =
System=94=20
IEEE Transactions on Software Engineering Vol 16 No.11 November =
1990. .=20
Ref 6: CHEN, HEISLER, ISAI, CHAN and LEUNG - =93A model for =
assembly=20
program maintenance=94 Journal of Software Maintenance Vol 2 no.1 =
March 1990=20
Ref 7: =93Programming in the Large=94 IEEE Trans. Software =
Engineering Vol=20
SE-12 number 7 July 1986=20
Ref 8: BERSOFF E & DAVIS A - =93Impacts of Life Cycle =
Models on=20
Software Configuration Management=94 Communications of the ACM Vol =
34 No 8=20
Aug 1991.=20
Ref 9: BS 5515:1984 British Code of Practice for Documentation =
of=20
Computer Based Systems=20