ITIL’s configuration management could learn from server configuration management, and look towards the future state
ITIL’s service asset and configuration management (SACM) process could learn from server configuration management. ITIL’s SACM tries to understand the present and past states; server configuration management moves towards a future state.
As a systems administrator, I used cfengine to install and configure servers. (Cfengine and similar tools will “rebuild” environments; Ghost and similar tools will instead “clone”/copy environments.) After setting up a fully-automated install environment, our boss came by one day and said he needed a server installed (from its FedEx box) and on the network ASAP. We were able to unbox the server, rack it, power it on, and deploy it as a web server within 30 minutes.
Server configuration management tools like cfengine are extremely powerful. When I learned about them, I thought they were full “configuration management” tools. Then I heard at one of the LISA conferences that cfengine wasn’t a full configuration management tool because it didn’t put together the servers into bigger pieces and control your entire infrastructure. That’s part of how I started to understand ITIL’s configuration management process and how it’s different.
ITIL’s configuration management process is powerful, too. It helps you understand the impact of change and plan improvements to service delivery. Yet, I think ITIL’s configuration management process could learn from server configuration management, by better trying to understand the desired future state.
What server configuration management tools do, briefly
Cfengine, puppet, and other server configuration management tools work more or less like this:
- Define the traits a server should have
- Assert what you want done, possibly dependent on these traits: “I don’t care what it looks like now–this is what I want”
- Iterate towards this goal state: This is the useful part, where the program runs and moves the server closer to meeting the assertions.
For example, the server “alpha” should have the trait “web-server”. Any server with the trait “web-server” should have a directory called “/var/log/apache” and files older than 7 days should be deleted from this directory. Every hour, the server configuration management tool then runs and ensures the directory exists and deletes the old files. (Why doesn’t the directory exist? It doesn’t matter. Maybe it’s the first run. Maybe someone accidentally deleted the directory.)
ITIL’s configuration management, briefly
ITIL’s service asset and configuration management process, part of service transition, is about understanding what you have and how it’s related. You create a plan for what you want to manage, then identify what you have, control it, record its current status, and verify your data is correct. A bunch of other processes, especially ITIL’s service change management process, then use this configuration data to understand the current environment–notably the risks associated with the way things are set up.
Configuration management needs 100% data accuracy for people to trust it, and configuration management should be able to provide a “map” of the critical components needed to provide IT service so you can see how parts are related to the whole.
ITIL configuration management should help you move towards a future state
The gap, I feel, is that the writing about ITIL configuration management doesn’t consider the value of asserting the way things should be even if they are not that way right now. For example, ITIL configuration management may show you that you have a network switch with 100mbps throughput supporting your primary database server–but you should be able to say “I need >= 500mbps throughput for my database server” and at least see the areas where your current state does not conform to your desired state. This would then become the basis for a plan (and ideally automated action) to move you towards the goal state (using the change management process).
ITIL configuration management is extremely well positioned to do this: it should already understand your current environment. If you add another “layer” of the way the environment should look, then you can apply the server configuration management concepts of iterating towards that desired state. Change requests then change the assertions about the environment, and configuration management helps push the environment towards those assertions.