In-Depth

Mapping ILM to ITIL

Do what needs to be done to operate storage infrastructure with a quality of service you can live with.

A reader recently sent me a request for background documents or links that would “map ITIL to ILM.” Apparently, he is preparing to deploy Information Lifecycle Management (ILM) and wants to wrap the effort in the set of best practices known as the Information Technology Infrastructure Library (ITIL).

In short, he is trying to find value in one kind of marketecture by contextualizing it within another kind of marketecture. My advice: use your common sense.

The general consensus around ITIL holds that it is a set of best practices and guidelines that define an integrated, process-based approach for managing information technology services generally. ITIL began in the 1980s as an attempt by the British government to develop an approach for efficient and cost-effective use of its many IT resources.

Today, like ISO, an entire industry of organizations, tools, consulting services, related frameworks, and publications have sprung up around the ITIL process, which focuses primarily on core IT operational processes such as Change, Release, and Configuration Management, as well as Incident, Problem, Capacity, and Availability Management. In other words, ITIL is a collective repository of experiential and theoretical guidelines that is making a lot of money for people from sales of methodologies and related services. Sometimes, when speaking with the ITIL-aware consultant/practitioner, you could swear that you are being indoctrinated into a cult.

ITIL has given us two things: 1) a pragmatic assertion that the true value of IT is in what it provides to the business process, and 2) an equally pragmatic assertion that delivering quality IT services involves a cycle of change management and continuous improvement. The first point is underscored by ITIL’s elevation of the help desk to the center of the IT operational universe.

This makes sense. Corporate opinions of IT services are shaped first and foremost by how user complaints are handled. Let’s not debate whether it is more important to ensure that systems are built properly so that users have nothing to complain about. Call it Toigo’s Law: Users will always find something to complain about.

It therefore stands to reason that the help desk person is the de facto ambassador of IT to the rest of the company. He or she had better be empathetic, knowledgeable, bright, and enthusiastic—and it also helps if he/she speaks normal English (or whatever language is popular in the company). Geek speak is out.

The second point doesn’t require any special ITIL books or consulting services to understand. IBM articulated its Systems Development Lifecycle (SDLC) nearly 40 years ago and it has infected everything it has touched since. Basically, all effective decision-making is a cyclical process. Collect information, define the appropriate strategy, implement the strategy, define the feedback loop, and act on the feedback to refine strategy. This is the essence of disaster recovery planning, security planning, application development, and just about any strategic planning process in the IT universe. That ITIL codified this as a best practice is nice and warm, but let’s give some credit where it is due. Big Blue’s Redbooks were every bit the guide to IT management that ITIL can ever hope to be, and it predated ITIL’s service orientation and lifecycle view by at least 20 years.

Big Blue is also, arguably, the master architect of ILM. Information lifecycle management could be established in the mainframe data center because IBM provided all the necessary tools in the form of DFSMS and DFHSM. With such tools, you could identify data sets and set up policies for how the data would migrate over infrastructure until their useful life was over and they could be safely purged.

What Mapping Do You Need?

This isn’t to say that everyone was disciplined in getting their data lifecycles defined and managed; many companies didn’t bother. They just moved data en masse, anonymously, and without any real attention to granular features such as regulatory compliance or criticality with respect to business continuity. They took the high school football playbook approach: only two plays—“Tarzan Right” and “Tarzan Left.”

Still, the tools were there, and with a bit of ingenuity, such as a DB2 database to serve as a metadata look-up table, you could deliver the four essential ingredients of ILM: a data classification method (so you know what you’re moving), a storage classification method (so you know where you are moving it), an access frequency counter (to help you determine when to move it), and a policy-based data mover (to actually move the data per policies). It was an autonomic system that, when implemented properly, handled your data assets as business rules dictated.

What mapping do you require between ITIL and ILM? The answer is none. ITIL simply provides metaphorical overlays on the ILM process; it neither helps illuminate nor defines what the ILM process is. I suppose you might find it useful to reference ITIL (as SNIA does in some of its papers on what it calls ILM) to impress the ITIL-savvy in your corporate bureaucracy, but, in any case, it isn’t necessary to map ILM to ITIL.

One other reason to contextualize your ILM initiative in the ITIL process might be to better guide auditors through your process—show them how the airy guidelines of ITIL are observed in your information policy development and refinement processes, for example.

The sad truth is that standards from ISO and quasi-standard mantras like ITIL, CoBit, and Six Sigma have managed to attach themselves to corporate processes from time to time, much like tapeworms. You see requests for bids that are thick with prerequisites steeped in ISO-this and ITIL-that. It is analogous to how the SNIA would like to have its work on SMI-S or XAM accepted blindly as “de facto standards”—which they aren’t.

My advice to the reader is to do what needs to be done to operate storage infrastructure with a quality of service that the company can live with, and to funnel issues related to data access and regulatory compliance through a business-savvy help desk. Moreover, build checks and balances into your data management processes that provide opportunities for improvement based on observed deficits, testing and business or infrastructure change. You will likely find that ISO, ITIL and every other set of guidelines have been satisfied—and you didn’t even need to buy a decoder ring.

My two cents. I am interested in hearing yours: [email protected].

Most   Popular