What good is CMDB if it does not Tie into Change Management

No matter how cool the reporting you get from your CMDB tool is, if the information contained in it is stale outdated, or just plain wrong.. You are hosed.

The content of your CMDB is as valuable as the last person that updated it. Most likely the CMDB will be around longer than that person so make sure it is up to date.

Make sure that you update your CMDB as part of your Change process!!! Adds/Moves/Changes to any part of the data center should be required to use Change process. Part of the process should be a check piont that updates any dependent documentation. If you have a CAB board that reviews changes, the udpates shoule be required to be implemented as of a time limit within the change window or even as part of the change plan. Possibly the clean up prortion of the plan right after updating monitoring tools. Then review to verify that changes were put in place. Sign OFF!

Do this and you will be ready for changes to your data center environment. Especially in a hosted environment when you have hands and eyes that are less familiar with your environment (New Hires, Contractors, Co-Lo's).

Any Change to the environment or dependency -> Implement Change -> Update CMDB

Tying your Inventory/Assests back to Applications

As I have done many Data Center Migrations, I have found one common thread on the initial engagements....

There is a disparity amongst the support teams and the application owners as to what they call their applications. Support folks tend to shorten or give acronyms to systems and the application teams have their own names as well. This causes some problems within the change management arena as well as documentation. My suggestions are as follows:

• Standardize on the names of systems within your data center
• Standardize on all potential classification area's (ie. locations, support groups, Operating systems, function, etc...)
• Verify that every device ties back to a common system name.
• Within your system documentation you could then track:
•  System Name - Common or Highest Level System Name
• Component: Module or Subsystem Name associated with System (Blank ok)
• Function : Type of device (Websvr, DBSvr, Storage, AppSvr, citrix svr)
• Servicing Location: What locations or Enterprise does this device support?

By doing this you are on your way to having a healthy change management system with accurate information regarding systems and their associated owners, stakeholders, and other upstream or downstream devices/systems.

This is also imperitive in order to have a proper dependency matrix (I'll cover that in another post).