In-Depth
ITIL to ILM, Part II
ITIL emerged from an effort to establish better coordination and service-level controls over IT infrastructure within the British government. It’s certainly changed since then.
Two columns ago, prompted by a reader inquiry, I started to talk about the prospects for mapping of ILM to ITIL—information lifecycle management to IT Infrastructure Library. Though I didn’t say so, it struck me as a sort of metaphorical “perfect storm” in the making: a collision of two ideas so admirable yet so mired in hype and marketecture that the stage is set for yet another massive spending spree by businesses that would produce, in the end, no meaningful result.
The responses to the column were many. Adherents—those "for" ITIL—were put off by the piece. Of course, ILM and ITIL should be married, they argued. Everything should be mapped to ITIL.
ITIL, now codified in ISO 20000 (called “20K” by insiders), defined lifecycles and offered process and procedural foundations for implementing constant improvement in everything from service ticket handling to application software development. Even security now had a book in the IT Infrastructure Library dedicated to it.
On the other hand, there were readers who were more hostile toward ILM and ITIL than I. One man from a leading storage vendor wrote, “I read a lot of deep thinkers in [the trade press], but sometimes I think we’re our own worst enemy. We over-architect, hypothesize, speculate on new protocols, reminisce about old theories of data management, and stew about performance profiles. It is heady stuff, but I guarantee that none of that ever moved a bit of data or changed a backup schedule or eliminated an unnecessary replication relationship.”
I also received a ping from a CA press relations employee inviting me to chat with their ITIL czar, Brian Johnson, vice president of CA’s ITIL Worldwide Practice. I was curious about what he would say, so I called him. In retrospect, it was probably the best thing I could have done.
Johnson has an affable nature and a thick Scottish brogue. He was also one of the original group involved with the creation of ITIL, which was invented by John Stewart (not the comedian, Johnson advised) in 1991. Johnson told me that ITIL emerged from an effort to establish better coordination and service-level controls over IT infrastructure within the British government at the time. A user group comprised of both government functionaries and vendors in the IT services market was formed to help spread the gospel of what Johnson describes as common sense.
One of the first applications of the ITIL approach was in the British health care system. ITIL sought to help establish a lifecycle management approach for incident reports, both to make processes more efficient and to establish the metrics for assessing how things were going. ITIL books, which codify the application of lifecycle methodology to many aspects of IT management, including software design and security, began to be published in 2000, and they were adopted by leading multinationals, including many banks, British Petroleum, Shell, KLM airlines, and others.
The IT Service Management Forum, sort of a shell organization over ITIL user groups, spread to 35 countries, and BS 15000 (the British standards embodying many ITIL concepts) was absorbed into ISO 20K.
This is the short form of the 45-minute history provided by Johnson, who capped his presentation with the statement that CA is taking ITIL very seriously and is using the ITIL principles internally to improve processes and deliver improving service levels to its customers. I proceeded to ask my questions—or rather to provide my impressions and concerns about ITIL and its mapping to ILM—and found myself really liking this man.
Johnson said that there is no such thing as an “ITIL certified” or “ITIL compliant” anything. Allusions by the Storage Networking Industry Association in its ILM-focused Data Management Forum to ITIL standards are meaningless. “ITIL is not a standard,” Johnson noted. “While there are people certifications, obtained through the completion of accredited training, the notion of ITIL-compliant software is a myth.”
He added that the APM Group Ltd. has been engaged to look after the ITIL trademark, implying that SNIA and other organizations who seek to wrap themselves in the flag of ITIL while abusing the philosophy and nature of the practice had best watch their collective legal backs.
Johnson said he could see a potential mapping of ILM to ITIL: “The goal of ITIL is to link processes together and to establish a common language between applications and infrastructure.” He had co-developed an ITIL book on software lifecycle support early on that he offered as an example of what was required.
“Take an incident report in a software environment. ITIL says that you should classify the incident. This will help you to define root causes of related incidents and define standardized procedures for addressing similar incidents. It also helps you to define what incidents may not require immediate action, so support personnel are not awakened in the middle of the night to address an issue that could wait until normal working hours, for example. The objective of ITIL is to become more efficient, but also more pragmatic.”
Johnson repeatedly emphasized pragmatism and common sense, “ITIL needs to be used for the right reason. It appeared at a time when the government was reducing the number of data centers and needed to share resources more efficiently. It was never intended to be a silver bullet for whatever ails IT.”
The interview with Johnson, who is clearly steeped in the history, ongoing mission, and goals of ITIL, was refreshing—but also disconcerting. How could such a simple idea—prompted by the sanguine observation that “common sense is often not so common”—develop such a cult-like following?
I related the story of a friend with thirty years in IT and the disaster recovery planner for a major Midwest bank, who offered his services post-retirement to EDS. The outsourcer asked: Was the fellow certified by Disaster Recovery International? When my friend, who had always eschewed flaky certification programs, stated that he did not carry that particular one, EDS said it could not use his services—despite three decades on hands on knowledge and experience. Somehow, a certification had become institutionalized, much in the way that “ITIL certified” is finding its way into requests for proposal and other mechanisms of the IT business—not to mention its inappropriate use by vendors who claim ITIL certification for their products.
Johnson empathized with my concerns. He noted that many IT shops that review their processes for ISO 20K conformance are delighted to discover that most ITIL goals and best practices are already part of their standard operating procedures. Getting to this point didn’t require a lot of expensive training and certification to make their people ITIL certified. Bottom line: This is common sense stuff, not rocket science.
The only thing that left me wanting about the conversation was why CA and other ITIL acolytes in the storage industry weren’t rapping the knuckles of the SNIA for seeking to perpetuate ITIL mythology to rationalize their approach to Information Lifecycle Management.
Where are the digital rights management police when you need them?
Your opinions are welcome. [email protected]