"We want a CMDB" is a statement I hear frequently as a consultant for ServiceNow. Usually it is followed by "Where do we start?" There are almost as many answers to that question as there are organizations that ask it. However, there are some accepted guidelines that can help.
First though, some definitions. A CMDB is simply a database whose records contain information about the items in your environment that you depend on to provide IT services. If you consider something important in pursuit of that goal, it should be in the CMDB. Configuration Item (CI) is the term used for each discreet component, and there is a separate record in the database for every one. An item can be things as varied as hardware, software, documents, procedures, integrations, etc. Configuration Management is the process by which all that information is collected, stored, verified, and used throughout an organization. I like to describe the CMDB as a decision support tool, providing information to people and processes regarding the past, current, and future state of the IT environment.
Now, those guidelines.
First: Understand who the stakeholders will be. Of course they can expand over time, but get a good handle on who will be basing their decisions on the CMDB you build. Part of that is understanding what underlying issue(s) and needs are to be supported by the CMDB. Do we want to resolve incidents faster? Are laptops disappearing from the datacenter? Do we have an issue with software compliance? All of the above? Talking to different groups inside (and sometimes outside) IT and understanding potential CMDB uses is a good start.
Second: Remember the purpose of the CMDB. Our goal is not to build the biggest database possible. Our goal is to provide information so that others can make informed decisions. Never lose sight of that. Do not add to the structure of the CMDB or to the data it contains if it is not forwarding that goal.
Third: Limit initial scope. The scope of the CMDB is a topic that will be expanded on here in a future post. For now, suffice it to say that all the cliché's you've heard about project scopes ("Boiling the ocean", "Eating the elephant", "low hanging fruit") apply here.
5 Comments
