How to update the CMDB

[Bobwill9]

ITIL talks about the CMDB like its a black hole. How is the CMDB actually managed? Do you use SMS or Ciscoworks to do this?

[Gav]

CMDB can be created using Excel if there is no other tool. But, it is recommended that a tool is purchased. Many tools offer CMDB's these days. Some graphical (network diagram style), some not so.

Your black hole analogy is a good one, but it can be however you want it. You can create a single store for all CI's or your CMDB can simply reference their location, and therefore can be thought of an index in a sense.

From a practical sense, CI's will exist all over the place. The CMDB offers an holistic view of each CI and their relationships with each other. In the case of documents being CI's then, tools offer a single store however its not imperative for configuration management to work (although I would prefer it that way).

[GSR]

Hi,

I agree with GAV that Excel should not be used for maintaining asset information, unless you have no other tool available, and even then, only as a very temporary measure. I would be more inclined to develop a simple database to store the informaton if a tool has yet to be purchased. This would at least help in the interim... In general, SMS, Oracle, Ciscoworks, and similar products can be used, and each have pro's and con's from cost to functionality, capabilities etc...

One question is if there is an incident management system in place, then does this system have the capability to automatically record and update changes to an asset? If not, then does it provide the capability to connect to other available sources to retrieve or at least link the information in one application to another?

I presume by "How is the CMDB acautally managed?" means "How to maintain the information?" In one case a standard that stipulates tech must verify items a, b, c, and f within the CMDB for each call, while another might state an update scan will be completed each week, or every morning, etc...

As to what a CMDB will contain... This is really up the organisation. For instance, is the intent to track information on asset so that informed decisions can be made with respect to upgrades (HW and SW), maintenance costs, contracts, warranties, emergency patches, sys updates, and so on... or do you want to just know where the equipment or software product is located?

Overall, you really want to find a tool that will collect as much information as possible through automated methods, to reduce manual entries and updates to the information.

In the case of documents being CI's... I presume that this references regulatory requirements. If so, you need to consider a central store, with the capability to relate the CI to another CI. However, as pointed out, it is not imparative for the CM to work.

Just keep in mind that if the info is not collected through automation, then someone or several persons will need to create, update, and ensure the information remains accurate, and this can become an administrative nightmare, along with many other issues...

GSR

[Azard]

Hi, when we talk about “How is the CMDB actually managed?”, it is a little unclear. Here is my take on it. There are actually several components to managing the CMBD.

One component is the auto-discovery tools:
The CI’s that have been identified that you want to manage and track are stored in the CMDB. You want to automate this as much as possible. Doing manual counting will result in the data quickly being not kept up to date and your CMBD will become obsolete. Of course this assumes that you have identified the key information for all of the CI’s you wish to track. With these requirements, you can use these as a starting point to select appropriate auto-discovery tools if your organization doesn’t currently have them.

The other component is Change Management:
The Change Management (CM) process is the only process that updates the CMDB information. All changes to the “live” environment are tracked through CM. A request for change may be initiated from an incident or problem record, and it may result in a release management planning, etc.

The CMBD is the foundation for all of the ITIL processes. It is one that will provide you with the least visibility, or quick wins like Incident or Change Management, but without related CI’s, these process will lack the fundamental link to tie them all together.

Cheers,

[SGW]

I've been thinking about it in a slightly different way. I think that CMDB should represent "what has been authorised" or "what it should be". All the changes that result in a change 'should' be via an authorised and standard process. That might vary from a) Jim always does it but we trust him to make the right decision to b) a full fledged change advisory board. etc etc
The key pont is that someone authorises it and someone updates the master reference (CMDB)as part of that process. If you accept that as a reasonable process then you can maintain a CMDB of authorised configurations. I can hear you all saying how is that going to work in practise. Well only at the start point can you accept imports from dicovery/config tools of "what the configuration is now" after that I would argue you shouldn't. If you have such discovery/config tools then you should, however compare 'what is really out there' (from a tool) with 'What the authorised configuration'(The CMDB) The difference is ....unauthorised change and/or people being lazy and not updating the CMDB. Either way it is a useful output to start putting pressure on people to conform

Hope that's of interest. I don't read or contribute to the forum on a regular basis so don't expect me to take this point futher! I came across the forum by accident, read the points and thought I'd put my 2penneth in!

Regards
Steve

[neopunk]

Hello All,

I read through the discussion in here.

Can someone give me the names of tools that can be used to implement configuration management sucessfully. The tool should be feasible economically.

Awaiting your positive replies.

Thanks to all in advance.

Cheers

[matt78h]

Hi Neopunk

As has been mentionedback in this thread, there isn`t really one "perfect" tool for the job. When we looked for our tool we were looking as a tool which would help us with Incident/ Problem management as well as having an onboard CMDB. We eventually went for a product called Touchpaper (which isn`t in yet, would like to heard from anyone who hase V7 now).

After the decision was made I attended the Practitioners course for CM and the info they gave out listed a whole load of things to look at before you make a decision. I think they gave me a sheet with pointers so let me know if you want it.

Basically you list the things you are looking for the product to do and have then in order of preference, you then have a look at various products and see whether they tick all the boxes.

There are loads of CM products out there, too many to mention really, just have a look around and you should be able to find the one you need.

Hope this helps!

Matt

[Guerino1]

[Guerino1]