The IT Infrastructure Library is a European initiative to document and define IT processes in service management and provisioning. Like many standards, ITIL is very vague when it comes to implementation. Managers love it, and sysadmins are either allergic to it or claim complete ignorance. In actuality, both parties can learn from ITIL.
It doesn’t help that many large organizations implementing ITIL standards have become complete fascists about it. Most might describe the phenomenon as “zeal,” but “fascist” is more appropriate. Managers charge headlong into a situation with a pre-determined solution, and they fail to take into consideration the details of actual implementation.
The single most common misconception about ITIL is that it completely and wholly describes processes. It does not, and sysadmins are the first to recognize that. The bearded Unix sysadmin who frequently swears in meetings should be given more credence at times. He probably knows, better than management, which processes will work and which will fail. ITIL’s authors clearly state that it is a set of “best practices,” not a process definition.
As Luke Kanies of Reductive Labs accurately and frequently reiterates, “The state of system administration is pitiful.” Administrators lack a standard set of tools, real automation software and standards implementations. ITIL tries to define standards and best practices, but the implementation usually fails.
Lack of tools is probably the number one reason for ITIL’s irrelevance. Take, for example, the coveted CMDB, or configuration management database. The ITIL texts use the CMDB as a sort of burial ground for anything complex. They essentially push the difficult tasks into this mythical CMDB, and then completely avoid discussing it in any detail. In reality, a CMBD will be numerous applications, including configuration management software and monitoring software.
On a related note, a change management database is another example of a mythical concept. The idea of change management is to document changes, likely resulting from a change management meeting, and then have the ability to reference said changes in the future. When something breaks, effective IT organizations first research “what changed” to figure out the problem. In an ideal world, your configuration management database, change management system, ticketing system and hardware database will all interoperate. Wouldn’t it be nice to search for all changes related to a particular service that resulted from a specific trouble ticket? Nothing remotely close exists in the real world.
