Getting Started with CMDB

[David Thigpen]

"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.

[Community Alums]

Looking forward to more topics on implementing CMDB....

[Joe Wilmoth]

I really enjoyed reading this article. Great for a beginner.

[She Sull]

Thank you David Thigpen, this confirms I am on the right track with our CMDB implementation. I'll be on the look out for more information on your third point as I continue requirements gathering with my stakeholders.

[Curtis2]

When using discovery technologies, the concept of how to build a CMDB is more of a question of "What should I be managing?"  Discovery technology will create a lot of CIs which may not be necessary for a Best Practice approach to Configuration Management.

Determining what that looks like is different for each environment; however, as a Consultant and Architect/Configuration Manager, I have always advised thus:

U - It is Unique

S - It provides a Service

M - It is Manageable

C - It is Configurable

Beyond that, one needs to look at regulatory and reporting requirements as well as the business needs and processes of the consumers of CMDB.  e.g. Incident, Problem, Change, Request...

For example:

A Harddisk Drive certainly meets the basic qualifications for a CI; however, no one really opens an incident against an individual drive in a RAID Array nor the physical drive of a workstation, right?  The incident, or change will be against the RAID Array itself or against the workstation.

So, while discovery will certainly see and register the hard drive as a CI, *we* don't have to manage it.

An IP Security Camera isn’t really a CI from an IT perspective; however, if SecOps is managing potential IP vulnerabilities associated with IP Cameras and has a requirement to relate Vulnerability Items to specific cameras via Tenable or other integrated tool, then an IP Camera is a CI.

Each case for a CI class to be managed should be challenged (some are obvious, like Servers) and a business use case provided and evaluated.

That said, who are your stakeholders?  What do they need in order to fulfill their functional roles?  Do you use VMWare?  If yes, then Virtual Machine Instance with a relationship to cmdb_ci_server (windows, linux, etc) will be needed.  You will certainly need IP Switch, IP Router, Firewall, Load Balancers but do you need Wireless Access Points?

Don't forget to talk to your InfoSec/SecOps organization.  If they are running something like Tenable and/or Forescout, they will have CI requirements as well which may require you to expand your managed CI list.

[Tanya Bartolett]

I don't know what the real topic is all about but it seems to be some building that you can see here and maybe would like to know this now as read more info will help you in knowing about stuff that was always there for us to go for a better enough reason later. MyAARPMedicare Thanks again !!