Does it go into the CMDB?
The CMDB has been the subject of many articles and whitepapers over the last several years. To cut to the chase, it contains, or integrates to, the data that allows IT to operate in the various process areas and service desk function. Configuration data, incidents, problems, change records, service desk calls – they all go into the CMDB to allow for the sharing of data between functions. In Visible Ops, Modify First Response helps highlight the need to integrate change management information with Incident Management, which helps reduce overall Mean Time To Repair (MTTR) by allowing the Service Desk to quickly identify if anything related to the service in question was changed.
About the only thing that you wouldn’t want to drive in is the raw data being captured from SNMP agents and other monitoring methods. In the same way that inventory detail data is stored in a warehouse management system and the summary data passed to the host ERP the same can be done with the data collected by the automated systems.
An interesting point is that the data doesn’t have to all exist in the CMDB but it should be available via an interface. For example, employee master data relating to the employee ID, department, supervisor and so on likely all exists in the HR system. Rather than violate data normalization doctrines work with HR to either get a real-time view to the relevant data or a routine export.
The goal of a unified CMDB is to allow the various processes to have access to the most current and accurate information upon which to base decisions on fact vs. belief. Whether the data physically resides in the CMDB or not will depend on the organization in question and that is not the objective. Instead, the true objective is to ensure that the organization is properly supported by an IT organization armed with timely and accurate information.