CMDB – Offline Source of Trusted Data or Ongoing Updated collection of actual Data?
Many organisations struggle with keeping track of what is within their IT enterprise environment and at best hope that they have a handle on IT asset controls for financial management governance. Many IT operational groups have their own view of what’s in the network based on their individual support requirements and have at best an incomplete view of “what’s out there”. Shadow networks are often not acknowledged and left to IT security and IT monitoring to discover rogue devices and legacy hardware that should have been decommissioned and removed from the IT environment.
There is a reawakening of the need to be in control of the not only the enterprise IT assets, but to also know the business service relationships including supporting services and hardware dependencies in order to increase visibility of what is required to deliver a stable service. This is resulting in a relook at Configuration Management and the role of the Configuration Management Database (CMDB) “tool”. Whilst other practices such as Release & Deployment Management and Change Control focus on the controlled deployment of new and modified services, Service Configuration Management is largely focused on the development and management of a centralised data repository (CMDB) and the organisational specific policies describing the identification, administration and control of the configuration items (CI’s) within the IT infrastructure. This data and information is critical to the success of all other IT service Management (ITSM) practices and business processes when providing services and adding value to the organisation. Service Configuration Management is a practice to identify, record, control, and report on all IT components that are within the scope of the CMDB. The CMDB is a structured database used as a repository of information that provides a logical model of the environment. The creation and maintenance thereof is the primary purpose of the Service Configuration Management practice.
So, what needs to be done?
There needs to be a strategy for the CMDB and what is often forgotten is that like any ITSM practices the Service Configuration Management practice also requires roles, policies and relevant management reporting requirements. Some of the questions that need answering for your organisation include:
- What is the vision for our CMDB?
- What is the goal of our CMDB?
- What is the scope of the items needed to control to meet that goal?
- What attributes (information) about those items needs to be gathered and controlled to meet that goal?
- What will the information sources for those items be?
- How should all this information be linked together in a view that adds value to your ITSM goals?
To answer the question in the titles of the article, the vision for your CMDB needs to be based on the understanding of the differences between Service Configuration Management and Asset Management and what you are trying to achieve. Service Configuration Management is information on items used in the provision of IT services and Asset Management is information items that are defined within the Asset Management process. Configuration Management Configuration Items (CI’s) will be promoted to the CMDB and actively managed, verified and audited by the Service Configuration Management practice where one should be able to link supporting ITSM records including, but not limited to, Event Records, Incident Records, Problem Records, Known Error Records, Change Records and Release Records.
According to ITIL® the CMDB can be either a trusted source of controlled data and information showing what CI’s, attributes and relationships are authorised to be in the environment, or it can be a source of accurate data showing what CI’s, attributes related to services are actually in the environment. Both approaches have merit, but it is important to address the desired end state early it the creation of the CMDB. This is especially important to address if the CMDB will be fed automatically with discovery tool data and whether the information is over written or if the exceptions in the form of Moves, Adds and Changes are highlighted and actioned. The refresh rate is also important to ensure the CMDB currency is in line with the needs of the business.
The exceptions need to be published to allow the Configuration Manager and other stakeholders to action and to ensure these are authorised and tie back to approved change control protocols. This information would be important to both the Change Control practice and Service Configuration Management as it would allow unauthorised changes to be detected and corrected.
When planning the CMDB it is important to have a defined Vision and Goals for the tool. A CMDB is one of the most flexible tools an organisation can implement but therein lies its danger. Many CMDB projects have failed by attempting to be too expansive and end up being a CI dumping ground as opposed to being critical to Service delivery and support and delivering organisational value.
Successful CMDB projects start by clearly stating what the goal of the tool is going to be and then using that goal to ensure that scope creep does not occur. Where possible it is recommended that a structured Project Management methodology be used to create a CMDB as the associated change control practice is highly relevant.
Need help with your CMDB? Get in touch today!
Query / Quote: firstname.lastname@example.org
ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.