Main menu

Category Archives: CMDB

When I’m talking to customers, I’m continually reminded that many (or should I say “most”) of them have no accurate records of what IT assets they have or where they are located. For the most part, of course, I’m referring here to physical items of hardware. The problem is worse, much worse, when one considers software assets – for here there is a question not just of good management control but a legal obligation to adhere to licence and intellectual property agreements.

One of the most productive ways of helping a customer to reduce their IT costs is to carry out a hardware and software audit. So often we find hardware maintenance contracts in place for hardware assets that were disposed of years ago and of course the same is true of software assets.

However there is a massive sting in the tail in the case of software assets – Licence types and rights to use.

Probably the most common gotcha is the over-deployment of a software item. How many active copies is your company licenced to deploy, how many are actually deployed and where are they?

Another of the more common “gotchas” with licensing, is that sometimes people have purchased upgrade licences, but not considered the whether the base licence is already in place to upgrade from. No base licence – no rights to upgrade!

Another one of the “gotchas” is accounting for deployments. E.g. thinking that Microsoft Server 2008 (Standard Edition) can be virtualised as many times as a company likes. (Technically, it can be – providing you are prepared to pay for it!) Unlimited virtualisation rights are the preserve of the Datacenter edition of the product!

Take the time to research Product Use Rights and licence metrics – not least in the development environment: does your licence permit the installation for the purposes of testing, demonstration and evaluation or are further licences required?

The standard ITIL programme of courses covers service asset & configuration management but goes nowhere near the specialist requirements of software asset management. Let’s hope that the new AXELOS arrangement gives due prominence to this very important IT discipline.

A student brought me up short on a recent course when we were discussing the distinction between incident management and problem management. We had been talking about the need for Incident Management to resolve the user’s issue quickly and the purpose of Problem Management to identify the root cause and provide a workaround or a permanent solution.

• A user contacts the service desk and complains that a particular document he is trying to print fails when sent to his local departmental printer.
• The service desk asks the user to redirect the print to a different printer (different manufacturer) two floors down.
• This is successful albeit very inconvenient. The service desk agrees with the user that this issue has been resolved and the incident can be closed.
• The service desk agent believes that this issue needs to be investigated further and raises a problem record.

• The problem management team eventually identify that there is a deficiency in the printer firmware and ask the manufacturer to provide a fix.
• Meantime, based on the experience from the incident, a Known Error record is generated containing details of the workaround that was successfully employed by the originating user.
• This is used on several occasions in the following months to resolve further similar incidents albeit with considerable inconvenience to the users concerned.

• Eventually, the printer manufacturer comes up with an updated version of the firmware. This is tested, found to be a valid solution and a change request is raised to roll the new version out to every printer of this make and model.
• No further incidents are raised.

• Sometime later the original user, based on prior experience, is directing his printed output to the printer two floors down. A colleague asks him why he is doing this. “Because our departmental printer can’t cope with this particular type of document” he replies.
• Well, I don’t have any trouble says the colleague – prompting to original user to try the local printer which, of course, works perfectly.

The IT service provider has clearly let down its customers/ users. But whose responsibility was it to advise the user-base in general, and this particular user in particular, that the workaround was no longer necessary. What went wrong? How would you change processes to improve the communication flow?
Stuart Sawlehttp://www.sysop.co.uk

Whenever I speak about Green IT, I assert that most IT Managers don’t know how much electricity their IT infrastructure consumes. Some challenge my statement and state categorically that they know exactly how much electricity they use because it is separately metered. Usually, however, this turns out to be the Data Centre alone. It does not include the vast amount of infrastructure out there on the network: user desktops; switches; routers; departmental printers; etc.

It’s an almost impossible task to keep track of the power consumption of everything out there – or is it?

We have a powerful tool at our disposal in the CMDB. We only need to ascertain the power usage of a device once and can record that in the CMDB and very quickly total the power usage of all of those devices across the network. Sure, we need to factor in service hours (likely switch-on time) and our model will never be as accurate as direct measurement. However it will give us a pretty good estimate and, more importantly, it will help us determine trends – are we getting better or worse – and will help us model the effect of changes to the standard roll-out.

I fully appreciate that not all service management tool-providers will include this level of detail at the moment; but with the rapidly rising cost of electricity and the increasing importance of a green agenda; it won’t be long before they do.