We are still not addressing the business at a CIO level

Robert Forbes

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 management?

Traditionally, change management involves all the software components on a computer. This means being able to manage every software asset that we have.

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).

Aren’t there automated solutions available to handle these problems?

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 I’m going to receive 250 calls to my helpdesk. That is the only way I’m 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 it.

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 isn’t, 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 management?

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 that.

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 user’s 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 who’s 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 configuration management?

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 in India.

Anil Patrick R can be reached at anilpatrick@networkmagazineindia.com