We are still not addressing the business at a CIO level
Configuration management is not new in an enterprise setting.
Robert Forbes, International Sales Manager, Change & Configuration Software
Operation, Hewlett-Packard (Canada), talks to Anil Patrick R about the
nuances and benefits of automating configuration management in the enterprise.
How does change and configuration management fit into asset
Traditionally, change management involves all the software components on a computer.
This means being able to manage every software asset that we have.
The larger the organisation and more geographically
dispersed it is, the greater the challenge of managing these resources
becomes, even in a controlled environment
Can you outline the typical bottlenecks that IT teams face
when it comes to change and configuration management?
The usual method is for the IT team to go around with CDs to users every time
an application has to be installed, updates or fixes rolled out, or migrations
implemented. This is a laborious process requiring a lot of resources.
The larger the organisation and more geographically dispersed it is, the greater
the challenge of managing these resources becomes, even in a controlled environment.
When you consider constant changes in the environment, a completely new level
of complexity is added. So not only are we doing the updates but we are also
bringing in significant security issues. For example, if you update one environment,
what effect will it have on the other? So increasingly there is a burden on
the IT department to manage that. This is true for most platforms, particularly
in a Windows environment.
Also, how about realising that this is typically a cost? It is part of the administration
environment. Today it is necessary to keep costs down whether those of labour
or assets (software and hardware).
Arent there automated solutions available to handle
Semi-automated solutions are available. Rather than taking
CDs around, we can now deliver objects to client computers using an intranet
or the Internet. These solutions tend to use scripts for functioning. So if
we have an application update package to be delivered, then we have to write
a certain amount of code saying where the package has to be sent to.
As part of this we have to understand what is out there on the network. For
example, what do I have in terms of hardware and software? How do I need to
deliver the software and what are the limitations or prerequisites? These are
some problems in a semi-automated environment using scripts.
Are these suitable for automating configuration management?
The problem with script-based solutions is that it is common to find high rates
of delivery failure. Let us assume that the IT manager has sent some information
out to a thousand clients. Supposing that I have a failure rate of 25 percent,
suddenly Im going to receive 250 calls to my helpdesk. That is the only
way Im going to find out since there is no communication between the client
and the IT guys. So they have to manually figure out what went wrong and fix
Another delivery has to be done and of course, there will be another related
failure percentage. Meanwhile, the IT manager is falling behind in his work.
This means that we are still not addressing the business at a CIO level. We
are only managing an administrative environment. This is why configuration management
solutions using a desired state environment are required.
What is a desired state environment?
In a desired state environment, the information is packaged as objects. We break
it down into little objects to be accomplished for a desired state. When this
is delivered to the end user that is the natural state.
When the package is delivered, the solution will do a quick test to check if
everything is alright. The objects at both ends are compared. If the collections
are identical, it is a successful delivery. If it isnt, there is a problem
and then it says which bits are missing or have to be removed. All I need to
do in this scenario is to send down the differential to that point.
On the other hand, if it is a script or semi-automated environment, I will have
to redeliver the whole package. This is because those solutions have no way
of knowing which bits and pieces are missing.
Are these solutions capable of doing more than configuration
It is also possible to manage assets such as software and hardware, as well
as accounting. For example, data such as when did I buy a particular element,
the serial number, and how long am I depreciating the server.
These solutions can also manage policy. In a large corporation, everyone probably
has a standard version of software. Their access rights and levels vary according
to their job profile or workgroups. For example, the software used by accounts
will be different from that used by engineering.
Can you explain policy management in detail?
Policies help administrators define who gets what in a highly selective manner.
We can also manage the policy of what new deployments require to deliver an
application. So in order to load an application on a client there have to be
some prerequisites such as so much memory available, so much disk space available,
etc. if you are doing an update, there must be a minimum version, things like
Let us say that in an engineering environment there are special projects and
very expensive software for those. Rather than buy a copy for everyone, you
might only buy half a dozen of them, and give particular users access to the
software for a particular period of time during the project. So I load the software
on those clients for the specific period of time. At the end of it, I take it
off the clients and move it to another project where they are required. Now
I am actually managing the cost of software.
We can also analyse every users software usage. There is a lot of ego
involved among users when it comes to software distribution. Users might want
a particular software just because others are using it and not because they
actually need it. Analysing whos using what and how much can help save
on the number of licenses that actually need to be purchased.
Are Indian organisations aware of the possibility of automating
The answer to this question comprises two basic perspectives.
One line of thought is from the process angle. Change and configuration management
are at the heart of what we know as part of ITSM, BS 15000 and ITIL that many
are talking about. We foresee this catching up in the next four to five months.
Therefore, there is awareness and interest.
The next level of it is broad-based adoption. There, in the ITSM or ITIL so
to speak, the heart of the entire process is the configuration management interface.
From that perspective, there is understanding and knowledge among Indian companies.
Although it is not as much as we would have liked, it is definitely happening
and is not new.
However, the desired state automation of change management is still not happening
Anil Patrick R can be reached at