Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Nov 16, 2004 Posts: 24 Location: Australia
Posted: Wed Dec 01, 2004 7:48 pm Post subject:
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).
Posted: Thu Dec 02, 2004 3:26 pm Post subject: Re How to Update the CMDB
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...
Posted: Wed Apr 27, 2005 3:46 am Post subject: CMDB
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.
Posted: Thu Oct 20, 2005 4:55 am Post subject: CMDB
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!
Joined: Sep 22, 2006 Posts: 9 Location: Plymouth, UK
Posted: Mon Sep 25, 2006 8:39 pm Post subject: How to update the CMDB
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Fri Sep 29, 2006 11:29 am Post subject:
Gav wrote:
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.
Hello Gav,
I apologize for contradicting you and I hope you don't take this personally, in any way, but I want to go on record and clearly state that you "cannot" create a CMDB using excel. The reason for this is because you cannot create, manage, and leverage the necessary "relationships" between trackable entities that are a critical part of any CMDB. The best you can do with Excel is create an "inventory" such as an Asset Register.
Something that I personally want all of the readers to understand is that many things that are called "CMDB" by vendors are not actually CMDBs. The requirements for a true CMDB are very straightforward and "relationships" are at the heart of them. If you cannot create named and managed relationships that show exactly how things are dependent on each other, then it's not a CMDB.
Also, a real CMDB is not limited to "Assets". This doesn't mean you can't have a CMDB that focuses strictly on Assets and the relationships between and within them but, if you do, it's rather limited.
In a good CMDB you can track anything and everything that is critical to your enterprise: People, Places, Things, etc. and how they are all tied together.
If you are using Excel or even Access to track an inventory of entities, then the best you're doing is creating an "inventory". Even a relational data model that leverages Foreign Key Relationships between attributes in one table that point to records in another are not good enough, as these do not in any way, shape, or form, describe the relationship between the two.
NOTE: If anyone wants a copy of a white paper I use for lectures, that clearly denotes the requirements of a CMDB, please let me know. You can contact me at "Frank.Guerino<@>TraverseIT.com" and I'll send it to you. It's been reviewed, tested and applied many times by many people that run IT in some very large enterprises and it seems to always meet their requirements. I'll gladly share it with anyone that's interested.
Anyhow, I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sat Sep 30, 2006 5:21 am Post subject: Re: How to update the CMDB
Bobwill9 wrote:
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?
Hello Bob,
To address your original question, the answer is "it depends"... In a mature organization you may have many things & people that update the CMDB. Here are a few:
- Human Entry for the addition, modification, removal of virtual Assets (i.e. SW binaries, Processes, etc.)
- Human Entry for the addition, modification, removal of tangible Assets (Compture HW, Vehicles, Racks, etc.)
- Automated Software Build Scripts/Programs
- Automated Software Distribution Scripts/Programs
- Automated Software Installation Scripts/Programs
- Automated Software Instantiation Scripts/Programs
- Automated Software Execution Scripts/Programs
- Automated Software Deconstruction Scripts/Programs
- Automated Software Rollback Scritps/Programs
- Systems Management & Monitoring Scripts/Programs (such tools may constantly scan your enterprise and reconcile with the CMDB, peforming automated incremental modifications)
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum