The CMDB Objective
I have recently finished the creation of a brand new CMDB setup from scratch. I created it in a popular cloud based ITSM platform but the technology used was not a driver and is largely irrelevant for the purpose of this blog. My overwhelming driver was kindly handed to me by internal audit whose simple request was to be able have one version of the truth.
When it comes to holding asset details and mapping them to IT services, a lot of organisations hold multiple lists. Maybe the finance people have a list of chargeable assets, the project people hold a list of servers that need to be upgraded and the Service Management community hold the service maps that relate servers to services. Security might also have a list of assets to integrate to SIEM and your technology resilience or DR Manager might hold a list of servers on DR cover or those that are clustered, load-balanced or otherwise in a High Availability configuration.
My task was to bring all of those lists into a single version. I choose to do that in a single CMDB instance. Federation might work for you, but I wanted them all in a single database and held inside the ITSM platform so they neatly linked to Incident, Problem and Change management modules.
The second ask from audit was that the configuration management database contained enough information to understand the criticality of any IT asset. When IT think about criticality, they tend to think about the tier of the server and the SLA for restoration. When business users and audit talk about criticality, they mean the impact on business capability and products.
The CMDB Build Process
As a Service Manager, I was asked to lead the creation of the new CMDB and had to pull upon my limited understanding of Project Management methodology. I wanted to ensure that my CMDB was not only a single version of the truth but also that it mapped asset relationships to link the infrastructure not only to IT Services but also to the Business Capability and Business Products that consumed the IT Service.
To do that my project plan high level steps looked a little like this:
- Identify key stakeholders (those that could input, influence or had an interest in the success or failure of my CMDB)
- Identify requirements (captured as user stories, what did each stakeholder need from CMDB)
- Build the logical data model (creating the relationship model from infrastructure, through IT Services to Business Capabilities and Products)
- Build the physical data model (handing the logical data model over to a developer to build through configuration)
- Capture the CI data (using automation tools to gather asset attributes and populate the CMDB baseline)
- Finding the relationships (extract relationships using automation where possible and pulling on Service Managers and Architects where it did not)
- Automating the relationship upload (this was one of the biggest challenges and I will write a separate blog entry dedicated to it)
- SACM process (developing the processes for verification and audit of captured data)
if I had to start again, with the benefit of hindsight, my high level steps would probably be the same but I would pay more attention to certain areas:
- Prioritise the stakeholders and requirements. I spent a lot of time loading EUC data and creating relationships with installed software packages to deliver a single use case for Software Asset Management.
- Think about the level of CI and relationships to capture and be realistic as to where the data will come from. I had a grand vision to relate servers to their storage and to capture the LUN allocations against each mount-point. After a lot of toil and heartache I had to admit that it was so dynamic and the storage estate so diverse that the best that I could do was relate a server to a storage device, which actually was all that was needed to meet the use cases captured.
- Stick to out of the box. My mantra remains Buy before Build and Configure before Customisation. My ITSM Developer had to do a lot of configuration to deliver to my logical data model. I probably had opportunity to reduce that if I had looked more at the ITSM platform out of box model when building the data model.
- Configuration is not a once and done activity. I can not stress this one enough. I knew it going into the project that the resultant CMDB database would need to be fed and watered through SACM processes, but I did not secure the resource required to do that before the project completed. That meant that I became caretaker manager until a permanent body was allocated to the task.
- You will need to explain and train. maybe I have been in the game too long as acronyms like CI, CMDB, SACM and CMS just roll of my tongue. When engaging the business I had to use simple language that they understood. Even after I delivered the fully functioning and data rich CMDB, I had not allowed for the amount of effort it would take to train Incident, Problem and Change Managers to navigate the new CI relationship structure.
The End Result
I stuck at it and now have a fully populated CMDB with automated data feeds that deliver a single version of the truth and maps the infrastructure layer up to IT services, Business Capabilities and Products.
SACM processes are defined to verify and audit the data quality and coverage.
Incidents and Problems are linked to CIs allowing focus on the asset classes that caused most disruption. Changes are linked to CIs that can be traced up to the business layer to understand the criticality and potential business disruption associated.
What you have found the most challenging aspect of your CMDB journey? What would you like to see more detail of in a future blog? Comment below.