Your CMDB isn’t unhealthy. Trust me on this one. It can’t be unhealthy because it is nothing more than meta data that describes the configuration items and their relationships in your environment. All of the data might not be correct and complete, and heck, it may even highlight CIs that aren’t compliant. That doesn’t make it unhealthy. I’ll argue that that is exactly what the CMBD is supposed to do. Highlight and point you to the areas in the infrastructure that need additional insight and more data. Collecting that data is the problem, and it’s one that is upstream or downstream from the CMDB. The aim of this multi-part series is to act as couples therapy for you and your CMDB. It’s time for the fighting to end and to go back to the honeymoon period when everything was clean, shiny and new.
# What does success look like?
Let’s start at the end in order to better understand where to begin. Once your CMDB is populated, how are you going to use it? What data are you going to extract from it? It should be a tool that you leverage to create value to the business. Need some inspiration?
– Change Management – When I have good data on a CI, it is easy for me to ensure that the proper teams are being involved in change conversations. When a switch port change upstream is going to affect my server, I want to know.
– Financial Management – I bought this system, I use this system, but what does this system really cost me?
– Security Operations – Uh Oh! I had a breech. What is impacted? Do you jump into a spreadsheet and start digging around looking for the data or can you quickly pull up a list of all items that are related to the affected system? From there you can narrow in your remediation steps.
– End User Support – My laptop is broken. Again. Heard this? With a solid CMDB at the foundation, you can help diagnose and even proactively eliminate frequent problems. All of the CD drive trays on the new laptops you just bought have a problem? Now you have a way to track and manage that and hold the vendor accountable.
– Lifecycle Management – When did we get that system? Which systems don’t match the baseline? When is it time to retire that system? What’s going to be impacted when we do retire it? Can you run a report and notify all of the correct folks when the decision is made to move a piece of hardware out of the organization?
– Capacity Planning – You say you need more memory, or you need more storage, but do you know how much you already have and how much you’re using?
The list is long, and the importance of understanding how you want to use this data is clear.
# Who’s on the team?
So you know what success looks like and you know all of the different aspects of your organization the CMDB can provide clarity for. So the next critical thing to understand is the who’s who in the zoo. Traditionally organizations assign the role of maintaining the CMDB to an admin or a team of admins that ultimately own the foundation. It is important to have governance and this team certainly forms the key stakeholders that provide that. But realize the skill gap that a CMDB admin may have as compared to a server or network admin. Those folks live in these systems and better understand the basic items that are populated in the CI. It is important that they also have ownership of the data quality in the CMDB. Further, they are the ones that benefit most from an accurate and actionable CMDB. Even more reason for them to be engaged in care and feeding over time. Lastly it may seem like a natural thing, but you need these folks to feel comfortable using the interface. They need to be empowered to make changes, leverage dashboards, and be involved in the same way that the CMDB admins are. So include the business. All of the business.
More to come in the next part…baselines, eating elephants, and fun stuff like that.
Digital IRL 