Posts Tagged ‘CMDB’

A lot of confusion exists, when people talk about CMDB.

Firstly, and the previous ITIL versions caused this, too often people think the CMDB is one database. Although this was never meant nor literary expressed like this in the ITIL framework, it was often translated like this (even by consultants). This reflex almost immediately turned the CMDB into an assets database.
The V3 ITIL framework has resolved this and it is now becoming clear that the CMDB is a collection of data sources (and not just one database).

But and this is more important, in the everyday operations, you still run into some issues, when you look at the definitions of a Configuration Item.

Let me explain by using an example (pure fiction, but so real in many cases), starting with a question:

Is a USB stick a CI ?

A lot of people will answer: NO
Their reasoning will be that they aren’t unique (no serial number and not enough place to tag it with an identifier) and the cost doesn’t weigh up to the cost of maintaining it as a CI.

There is not a lot I can argue with, because their reasoning is correct.

The requests to get a USB stick are handled by the Helpdesk
I don’t want to give out 5 sticks to every employee, so I would like to know who has one
When they leave, I’d like them to return it (optional in the case of a USB stick, but sometimes important)
I’d like to do stock management on these USB sticks, so that I always have them available
I need a way to allocate the cost (maybe not in the case of a USB stick)
The tool that I’m using as my IT support tool gives me the opportunity to do all of the above (if I have the USB stick in there as a CI)

So do we make it a CI anyways ? and if you were only looking at the cost, how about something a little more expensive, say an external hard drive or a secondary power supply or a docking station (which, I know, often does have both a unique serial number and the space to tag it).

How do I solve this? And this is how I advise it to the clients I work for:

Create a generic CI : USB Stick 2GB
You can, as you would with other CI’s, fill in details about brand, supplier and any other attribute that makes sense. Also, if your tool will allow it, put in the number you have purchased (my tool calls this max. number of installations)
Now register any demand for a USB stick as a service request (remember a service request is actually a pre-approved change with minimal impact and where every step to be taken is known and documented). Every time the request is fulfilled you add (link) the user to the CI.

With this we achieve a lot of different things that we want, without turning the USB device itself into a CI:
– The USB stick offering can be placed under a (sub)service (e.g. provide consumables for a standard work platform)
– The demand can be easily processed (and registered) by the Helpdesk
– Usage (who has one, how many requests, even charging if that is applicable) can easily be tracked and reported on
– Stock can be managed (e.g. create alert if available quantity falls under 10)
– When it is decided to switch to 8gb sticks, a new CI will be created, and hence a more formal change will need to be processed, making room for supplier management (purchasing: still the correct supplier at the correct price), release (testing and documenting) and config mgt (updating CMDB, update catalog: possible making old stick unavailable, adding new stick, updating service request, adjusting reporting, etc…)

The number of things you can add in this way and track and manage through the Helpdesk and helpdesk tool extends even further than IT. I’ve seen this system used in smaller companies to track and manage books on loan, confidential documents, keys, credit cards, etc… Of course if you HR is tracking this, there is no need to duplicate…

And than again, the question so often asked in configuration management/cmdb discussion is, where is the cut-off point? where do I stop registering them as a generic, and start identifying as a CI?
And again the answer is : IT depends! Where does the need start to have a formal change process when it changes, that is where you would identify them as individual CI’s.

Let’s take laptop as another example. I know that in most companies they are registered as a CI (sometimes/often bundled with consumables).

But look at this example: a large company which has outsourced its entire HW to an external company. Next to that the helpdesk too is outsourced.
This company approached a laptop from their point of view in the change management process and concluded that they would not perform change management on individual laptops (that was the outsourcer’s problem). However they do want to control what that standard laptop is and who has one.

It could make perfect sense to them, to register a generic workstation setup (e.g. standard laptop), with as it’s attributes what they understand under that (e.g. dell latitude E6400, 160GB, 2MB RAM, etc…) and only track who has one. The service request (at the outsourcer) holds one approval (direct manager, known to the system and the approval process is automated).
Now, of course the outsourcer will have a CMDB where the laptops are obviously treated as CI’s. The only thing remaining is set up a reporting, so that if needed, decision makers in the company can get info on laptops from the outsourcer, end of story.