Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Tue Dec 04, 2007 9:14 am Post subject:
Mark, I agree, but I would go a step further.
I always start with a question of what purpose does CMDB serve. We all know that many companies use CMDB as a dumping ground for all of their gear and then define relationship based on some unclear criteria just because 'it makes sense'. Little thought is given to what value you, as an organization, looking to extract from CMDB, especially in relation to business service management.
Hypothetically, if you have SLM established, or in planning, one of the things your CMDB will need to tell you is how a specific CI is related to a Service that business provides. From Incident management perspective you want to know a degree impact on a service in order to establish your priority for resolving a specific incident. Consequently, relationships in your CMDB should be built in a way that will provide you with required information. E.g. server A hosts database B which enable Application C which enables generation of financial statements for the company. So if Server A is not available and it is not available at the end of the fiscal, your CMDB better tell you that the priority of this Incident is Urgent, otherwise the company will be faced with legal and regulatory consequences.
I know this is a generic trivial example, but I hope it illustrates what should be taken into consideration when looking and building relationships in CMDB.
I welcome other suggestions and ideas as I am sure there are many great information and experiences I would like to be exposed to.
Have a look at the BCS-CMSG web site. They ran an event in December called designing the CMDB and the presentations are downloadable. Various practitioners covered the different viewpoints and it may help with internal communication or direction.
I presented at the event at thought it was well balanced and helped to unpick the confusion caused by the ITIL CMDB concept.
A key message was to make your CMDB as small as possible - it may then deliver the value you want. If you try to put everything in it you will fail to get the intended benefits - as most CMDB programmes do.
Hi, one thing that I find is when most people talk about Configuration Management, they mainly focus in on the CMDB. The CMDB is but one aspect of the Configuration Management Process. As you work through and define your Configuration Management process, you should be able to start to define the appropriate information to keep within your CMDB. You should be involving many stakeholders who may have an interest in using the information. You will then need to decide what information stays, and what is held elsewhere.
I agree with Cotswolddave in that many people try to make the CMDB the dumping ground and will be bound to fail, however, I would like to say, keep track of the appropriate information, and allow for growth as your needs will and should change as the business grows.
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