I spent last week in the Zenoss booth at Knowledge17 talking with ServiceNow customers about the challenges facing IT leaders today. One repeated topic I was asked about was building a CMDB from zero. There were many who are in organizations that are exploding and haven’t been able to keep up with the ITOM needs that you see with more experienced customers. I’ve worked with many organization and have seen many different approaches to solving the CMDB puzzle — some succeeded and some failed — and I want to share what I’ve learned on these journeys.
-- Start with the process and not the data. It’s tempting to start with the “list of what we’ve got” and build from there — this is a mistake. The data in a CMDB is like a river, and we need to focus on what’s upstream and not worry about the water that’s already passed under the bridge. CMDB creation is about future state, not today. Anything still around when the process is done will be caught up by the process.
-- Don’t swallow this elephant whole. I once saw an implementation that started with an outside consultant who came into the organization and went to each team and asked for requirements, added them up, and then spent months trying to find a tool that met every goal. Well, guess how that turned out — CMDB became a four-letter word. Start with one team and work out the details, get feedback, and fix the problems. Don’t add other teams until you’ve fixed the problems.
-- If it’s not in the CMDB, it does not exist. No change requests, no user IDs created on it, no calling support. Period.
-- Automate or fail — there are no other options. The Zenoss-ServiceNow CMDB integration is a perfect example of this. Automation of monitoring — from adding new devices to decommissioned devices — is a must. There is no way to keep up with cloud scale without automation.
-- Find and correct those not following the process. I’m often asked if Zenoss can discover devices. “It can, but you shouldn’t,” I always say. This gets a puzzled look until I elaborate. The discovery of a device can’t tell you what you need to fully understand the business value of a device. “Yes, I can start monitoring it,” but who owns it? What’s its business function? Who needs to know when it’s down? These are among the many nondiscoverable questions that a CMDB will answer. My recommendation here is to import devices from your CMDB into Zenoss, then periodically scan for unknown devices and use that list to find who’s not following the process.
As IT moves further into the world of shortened development cycles, automated cloud deployments and microservices, not having a CMDB is no longer an option. Let me know what you think of the above and if you have your own tips. Send me your thoughts.
It was to great hear the continued validation from customers at Knowledge17 of the Zenoss-ServiceNow integrations with CMDB and incident management. I can’t way to hear more when we see you at Cisco Live next month in Las Vegas.
