This article is more than 1 year old
ITIL - it's really important, like...
But what is it?
In the last two years, systems management and helpdesk vendors have bandied around a term as if it will be the saving grace of organisations for the future - Itil.
Trouble is, not that many organisations have a clue what Itil is or what it can do for them - and yet we're seeing that it has become one of the big "tick marks" on the buyer's list. "Yes, I know it hits all the functional needs, it fits my price requirements, it's the right colour, it does the toast in the morning - but does it do Itil?"
So what is Itil? It stands for IT infrastructure library and is an approach to IT services management. In itself, it's not a product - it can be best regarded as a set of best practices built upon knowledge of previous attempts of doing specific IT processes and how tools can automate and expedite these processes.
Itil was developed as a set of practices in the UK through the late 1980s and early 1990s, primarily as guidelines for the public sector. A set of books was produced by the British Standards Institute (BSI) and The Stationery Office, and the UK government pushed Itil as a standardised way for the public sector to deal with specific technical processes.
However, large private companies soon saw there was value in adopting the main Itil processes. Then a spin-off market was created for books written on how to understand Itil, how to adapt Itil to specific markets, verticals and so on, and how to make Itil "unique" to an organisation's needs.
In 2000, the Itil guidelines were revisited and the Office of Government Commerce - in conjunction with the IT Service Management Forum and the BSI - created an updated set of documentation for Itil. These new documents focus on eight major Itil process areas: service support, service delivery, planning to implement service management, application management, ICT infrastructure management, security management, software asset management and the business perspective.
This new set of documents caught the eye of the vendors. Here was a pre-prepared set of processes they could bend their products to facilitate and automate. All of a sudden, the likes of BMC, CA, HP and IBM started to show a great deal of interest in Itil.
As the sales messages started to include mention of Itil, the customer base began to take more interest - and that's how we ended up in the current situation where Itil is a major factor in the decision-making process for buying new IT products. The problem is that not that many organisations actually use Itil to best effect.
Why is this? Well, the handbooks are not the most easily read books in the world, the processes do not necessarily match the existing processes that an organisation is already using and vendors have implemented Itil support in a more piecemeal fashion than many of them would like to admit.
Still, vendor support is now much better than it was when they first launched Itil. The likes of BMC and CA are taking the lead in trying to simplify what Itil is all about.
For example, let's look at CA's "underground maps". These pictorial representations take the Itil processes and create process flow diagrams that use the well-recognised analogue of an underground/metro map to show how the flows work. These freely available maps provide a common point of reference for both the business and the IT department to discuss how Itil can be utilised to give a common approach to standardised IT problems and how feeds to and from the business can plug in to this standard process.
Likewise, BMC's "swimlane" diagrams take process flows and layer them over the standard Itil areas (each area is shown as a parallel track, as one would see in a swimming pool, hence the name), showing where overlaps are and again providing this central point for IT and the business to get together.
But is Itil important? I think so. Itil is not just some new idea dreamed up by some vendor's marketing floozy. It is based on a lot of empirical research in both the public and private sector, looking at which processes do and do not work. It distils all of this into a set of common processes that a company can follow wholesale or use as baselines for its own processes.
Itil "compliance", or adopting Itil's methods, should enable organisations to maintain common processes through from one technical infrastructure to another, from one vendor's tooling to another, without the need for any major changes to the process itself.
When using external consultants or when outsourcing business processes or application services, Itil will help in the handover. As the processes are common, there is no requirement for lengthy transfers of "our unique IT processes". Itil makes replacing staff on helpdesks easier too. If the processes are common across industries, anyone who has worked on an Itil-based helpdesk in the past will be easily able to adapt to your Itil-based helpdesk.
Itil has matured over the past two years. This is mainly due to the acceptance by the vendor community that commonality of approach to basic IT processes is a good thing. Tooling is now becoming strongly Itil-based and Itil process templates come out of the box. Why waste time in creating your own approaches to IT processes when the best solutions are available with the tools you've chosen anyway?
One small fly in the ointment: the last refresh of Itil was in 2000. There is a new refresh review ongoing, which started in August 2005 and is expected to be completed during 2007.
The problem for the vendors is then whether to change their systems wholesale to the new Itil or to maintain their current Itil paths. For end users, a similar choice applies - and they might also have to choose whether to maintain loyalty to an existing vendor. Until we see the new Itil, it's a moot point - but a point worth bearing in mind while talking to your vendor of choice.