CMDB:
Nine Steps to Implement a Successful CMDB Project
CMDB is a popular topic these days. Everyone needs it. Few can explain it. Fewer can justify it. ITIL highlighted the need for Configuration Management and the software vendors responded with products. Analysts added their endorsement using terms like 'federation' and 'reconciliation' to explain the gaps while also making a stab at explaining the benefits. Yet actual CMDB adoption has not kept pace with the market's interest in it.
Intuitively people accept that Operations needs tools to help make better decisions, and few would deny that IT is a technology-immature organization. The current discourse is reminiscent of the early data warehouse days where products and technology drove the discussion using terms like OLAP, ROLAP and data marts with a liberal dose of build it and they will come reassurance. It seems that most new software product waves only focus on features and ignore implementation guidance.
This whitepaper lays out a prescriptive nine-step plan describing how to implement a cmdb, including best practices. This whitepaper may be used to educate staff and design an effective change management database project plan.
1. Education and Awareness
A CMDB brings a new and unique capability. New concepts have to be digested by the organization to change how IT thinks and makes decisions. Tools can be quickly installed but if the hard work of explanation and alignment are not completed then the tools it will remain toys in the hands of few.
A CMDB does not address the usual IT concerns of functionality, availability and performance but instead addresses how components are connected and constructed, as well as their dependencies upon other components. Like all operational tools, a CMDB is helping predict and prevent service disruptions by shortening problem resolution time and improving quality of service. However, a CMDB does add the new dimension of structure.
This section discusses concepts that need to be communicated and tested within the organization before implementing a CMDB.
Current definitions of a CMDB can be vague, for example:
- A CMDB implementation helps organizations adopt best practices.
- ITIL compliance requires a CMDB.
- A CMDB is a single source of record.
- CMDB is configuration management.
Consider this definition of a CMDB:
1. It is a decision support application that allows one to visualize what's there and how one may interact with what's there.
2. It tracks and reports on configuration events.
3. It formalizes components by assigning an identity, properties, and structure.
4. It can account for many types of components also known as Configuration
Items (CIs) and their relationships. CI Types can be anything you believe supports making decisions ranging from networks, appliances, servers, software, rules, files, people, location, documents, etc.
- A problem has occurred. What has recently changed? Was it approved or not?
- A change is being contemplated. What are the end points, and who could be affected and in what manner? Also the reverse situation can be addressed when a problem CI needs to be researched. A CMDB can indicate what a CI is connected to and its interdependencies with other CIs.
- A dashboard is required to summarize what's currently happening by CI or by layer. A capability to drill down to the offending layers and child CIs is required, one that would call out details such as:
