Overheard at a recent conference:
“Oh, we are working on configuration management…Why? Because it’s an ITIL process”
The conversation continued with “…yeah, I don’t know why it’s not going well. We bought <well-known tool name here> which has a CMDB. We have been adding configuration items (CI) into the CMDB for the last two months. Nobody in the IT team is using the CIs for incidents or change…”
I walked away, no longer wanting to hear any more of the gory details. Unfortunately, I feel this is more the norm than the exception. Let us take a few moments to examine why.
IT is a version of “Hoarders”
IT is notorious for buying lots of stuff (that is a technical term) and equally notorious for not decommissioning items. Working in Higher Education, I often see departments who have plenty of funds and those departments who have to do whatever necessary to survive. This culture propagates surviving on the “scraps” thrown off by the “rich” departments when they get new items. IT often helps “repurpose” equipment to defer costs. Unfortunately, we end up with rooms full of devices, some of which may be running important business operations, with limited knowledge of what/how they are connected, the service they help provide, or why. Sometimes it may even become difficult to know who supports the device.
These actions have positioned IT to have a “hoarder” mentality. Don’t think so? We all know the team mate who has a copy of Windows 3.1 on 3½” disk who is hanging on to them because “…you just never know when the might be needed…” The spare equipment room, items sitting on inventory shelves, unappropriated devices in communications closets, servers under desks, overhead desk cabinets full of various versions of software, all adding up to “a big ol’ mess”.
With this much stuff, the task of building usable CIs becomes daunting. The sheer volume (thousands of items) becomes overwhelming and dooms the thinking of the configuration management team to “…we can’t do this…”.
It’s all about the CMDB
Ask this question “Are you doing any type of configuration management?” There is a good chance you will get a response of “Yes, we’ve got a CMDB”. This is just maddening.
I do not blame vendors for this. It is the vendor’s job to promote its products, but unfortunately, too many folks take the information provided by the vendor and translate it into “…to do configuration management we need a CMDB…”” to making your configuration management process work. Configuration management is about understanding the items that make your services work and their relationships. The CMDB should help the IT team mitigate risk during change decisions, help in trending during problem management, and allow the IT team to understand the impact of their operational decisions.
Education on Configuration Management
Where is the education? Now before all the ATO send me hate mail, I’m taking about where are the practitioners talking about configuration management? Formal training is not the issue. There seem to be very few good storytellers out there when it comes to configuration management.
In fairness, the reason there may be so few good storytellers may be due to how much context plays in configuration management. Let’s be honest, the context of my organization is different from the context of your organization. Incident management runs pretty much the same across all organizations. Simple premise of “get the issues resolved as quickly as possible” translates to everyone. The stories are transportable to each organization regardless of context. Because of this, ideas become quickly adaptable and usable.
With configuration management, we do not see the same ability to be transportable. Configuration management begins with the relationship of your services to the business. It becomes difficult to adopt an idea that does not match with your context.
Configuration management also seems to be the place most people really want a “recipe” for. “Just tell us how to do it”, the phrase uttered from many configuration management teams who realize the level of work they will need to do just to figure out where to start. Education on configuration management is most likely not a fair phrase. Configuration management does require a “deep dive” into the method and diligence to obtain desired outcomes. Make sure your team has the passion and the “intestinal fortitude” to make the tough decisions to build a configuration management process for your context.
“Ownership” of CIs
When you start discussing Configuration Management, you will undoubtedly run into folks in your organization who feel they “own” whatever CI you may be discussing. Sometimes their attitude may be perceived as “…this <device> is my responsibility…how dare you have an opinion on what I should do…” or “…I don’t report to you…you can’t tell me what to do…” They come by this honestly. For many years, IT perpetuated “silos” and one did not simply cross boarders without permission. Because of the way IT has worked in the past, many people see the items that they manage as “personal” pieces of their work and change for those items “require” a personal level of collaboration with the individual.
As we know, ITSM breaks down this paradigm and promotes a spirit of service across departments. Unfortunately, this does not always hold true when it comes to people managing devices. Depending on your organization culture, you may have teammates who do not buy in to the concept of configuration management. The configuration management team must do everything they can to break down these walls and ensure all teammates understand configuration management is not about taking away authority. Building a plan that helps IT deliver great services depends on team member participation at all levels. If your organization culture values individual performance over team achievement, you will have problems getting configuration management to stick.
Final Thoughts and Tips for Configuration Management
Configuration management is tough because:
- Everyone in IT must commit to the process
- It depends on organizational context
- It may require big organizational change AND individual change
- Understand the services your organization offers. Have discussions regarding CIs around how they relate to services.
- Find people who are willing to do the deep dive into Configuration Management and who are willing to change the organization. Having a few “cynics” who are willing to challenge ideas is a good thing as long as they are working for the betterment of the business and not disrupting progress.
- Repeat with me, “IT’S NOT ABOUT THE CMDB!” The CMDB should be something that helps accelerate other processes.
- At some point, someone is going to take the change personally. The Configuration Management team should practice dealing with this issue. Have a script on how to respond when challenged with why the change is necessary. Remind others, it’s about us looking good.
- Take the time to move a CI through its lifecycle manually. Doing so will help the Configuration Management team understand how CIs are used with other processes, the relationships CIs have with services, and if your process meets your context. Once you have perfected the flow, use the CMDB to accelerate processes.
Configuration management is not impossible but it does require commitment, compassion, and compromise. Be sure to build a team that has the passion to build a configuration process and to help IT commit to using it.