(A short clearly written summary of some of the challenges, and the (almost) current state of play. - Note Andrew's reference to the CIM standard 'Common Information Model' by the Data Management Task Force. If you are serious about designing a meta-data schema for a CMDB - don't! The CIM has every attribute and relationship you are likely to need for a long time already defined and documented. But not for the faint-hearted )
The primary objective of your CMDB should be that it shows the dependencies of the components of your infrastructure. Relationship attributes are more important than descriptive ones. But not just any realtionships - the final result should show each CI as a production factor of the Services you provide.
To this end the ITIL Service Level Management chapter recommends recording your Services in CIs in your CMDB. These should be the top level of the CMDB, and everything else mapped into them. To do this you will need to effectively define classify and model your services. To that end I recommend you look for a Pink Elephant whitepaper called:
Defining, Modeling & Costing IT Services
(Integrating Service Level, Configuration & Financial Management Processes)
Which is a good run up to how the real value of the CMDB lies in cordinating it with a simple service definition and classification model. Which would provide the meta-data schema for classifying Service CI attributes.
Which brings me to the final point. The CMDB is more than a collection of CIs with status attributes attached. It is a management tool and as such many of the structures that should be contained in it are actually 'arbitrary' collections of components that need to be controlled as 'systems' or 'applications' and etc. This means the CMDB has to be able to represent the infrastructure through more than one abstract model. (I recommend, component, system, and service layers). An upshot of this is that different 'kinds' of CI's will be necessary, (and not just to cover the differences between hardware, software and documentation), and with that different attributes. This means a normalised relational DB may not be the most effective representation. Expect a functioning CDMB to push RDBMS implementation to its limits.
But not to ignore you post, and to get back to the point, try and find:
Modeling the IT Enterprise Infrastructure
An IT Service Management Approach
by David Chui and D. L. Tsui
(Sorry I couldn't remember a URL or site for this one, but I am sure the proverbial Google search will bring it up pretty quickly. It is an excellent discussion of how to structure the basic relationships of a CMDB.)
Can you please explain what metadat is allabout with respect to CMDB .In what form will CMDB metadata be presented (like DB tables or XML or any other format)
Usually people are keeping some form of administration themselves. Start there. Standardize it (by definitions, units, notations), clean the data accordingly and you got your first CMDB. Software that (a) doesn't allow you to add attributes, CITypes and relations on the fly (b) doesn't work on the web (c) doesn't have a good report tool (with data export in popular formats) is no good. If it can do that, you can expand your CMDB as needed. DON'T never, ever start Config Management without some solid Change Management.
2) Understand what all the correlating Configuration Item Types are that you'll have to handle in your CMDB. Reference: "Configuration Item Types"
Using standard industry classifications will help you 1) Understand what you're up against, 2) avoid reinventing the wheel, 3) get you and your enterprise to a solution faster, 4) make your solution as complete as possible, and 5) help keep your costs of getting to your solution as low as possible.
I figured it would be useful to also add a reference to the IF4IT's "Configuration Management" discipline page. Both, the glossary and all reference material has been developing rapidly, thanks to its many users.
This type of information often comes in handy when trying to understand, design, deploy, operate and support your CMDB.
Reply With Quote
)
Bookmarks