The Security Blog

What is ITIL? Why you should care:

Introduction to the ITIL 

David Moskowitz  

What is the ITIL?

Put simply: ITIL is an abbreviation for Information Technology Infrastructure Library.   The ITIL addresses good/best practice for IT Service Management (ITSM) recognition that information technology is or can be a service-based business within a business. The ITIL is a descriptive framework for best practice — not how to do it, but what to do. By comparison PMBOK is a proscriptive framework for project management — it tells you how to manage a project.

What is Good / Best Practice?

According to a Wikipedia, a Best Practice is more efficient and effective at producing the desired outcomes than other techniques.  In other words, following known best practice provides a degree of optimization. For IT, this addresses 2 critical areas: cost and process. 
 

A Brief Introduction to the ITIL 

How many times have you heard this, "Let’s not reinvent the wheel?" Within limits that question forms the basis for the creation of the ITIL.  When Margaret Thatcher was Prime Minster of England, she told the IT department to document best practice. The reason for the "request" was simple, the British Government didn’t think it was getting value for the money spent on Information Technology. Consequently, the effort was not supposed to be a theoretical exercise but a practical one. The basic commandment from the Iron Lady could be paraphrased as, "Document, don’t invent." That lead to the first release of the ITIL in the 1989/1990 time frame. 

The original release consisted of 40 books and focused heavily on mainframe-based IT departments.  In 2001, a refresh of the ITIL was published (aka the ITIL Version 2) that consolidated the information into 7 volumes and included significantly more of a PC focus. The ITIL V2 was all about IT processes and best practice within the context of those processes. While collaboration was part of the description, it was in a process-to-process context. Within limits this lead to some organizations adopting the ITIL V2 in ways that allowed process silos to develop.

Differences between ITIL V2 and  ITIL V3

The ITIL V2 largely ignored a critical fact: Services have life cycles. The recognition of this reality forms part of basis for the reorganization/refresh that is the ITIL V3, published in 2007. The ITIL V3 expands information from the ITIL V2 core volumes, Service Delivery (planning) and Service Support (operational), and includes information from the "lesser" ITIL V2 books. In the ITIL V3 processes are presented as part of the lifecycle that helps to break up the "soft silo" notion is part of V2. In other words, a core part of the approach for the ITIL V3 is how all of the processes work together to achieve IT Service Management, as integral parts of service life cycle.  In addition, the ITIL V3 is much more appropriate than V2 for organizations that are using Virtualization or Agile methodologies, providing Web-based services or any of the more modern approaches to software development and delivery (including SOA, SaaS).  The other reason for the 2007 refresh of the ITIL was to clean up the language, standardize definitions, and arrange the processes in a time line, consistent with the concept of lifecycle.

What this translates to is a refresh of the ITIL that is more comprehensive than prior versions and at the same time more focused to address current demands on IT in a Web-based world. Some people have suggested that the ITIL V3 is bigger and harder than V2. When you realize that V3 reorganizes the material from 7 books and adds missing pieces, then V3 isn’t that much bigger than V2 (taken in its entirety). V3 adds more guidance for functions (defining 3 that were not really addressed in V2 but most organizations had anyway, e.g., IT Operations Management to run the network operations centers), Roles, and Tools that are required by the lifecycle approach. V3 also adds the formal notion of Continual Service Improvement, hinted at but not defined in version 2.

In addition to lifecycles, the ITIL V3 includes a description of process models. Besides software development, it is usually necessary to develop supporting processes to use, operate, deliver, control, monitor and measure, or improve the service. Process models facilitate this effort. The concept of standard process models to create the necessary support processes is important — it makes the process of creating processes predicable and repeatable.

One of the major differences between the two versions. V2 talks about a service, V3 defines a service in one sentence: "A Service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." (I’ll explain this in more detail in the next installment.)

The ITIL V3 Core Volumes and what they cover:

The five core volumes of the ITIL V3 are: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. A brief overview of the five books follows.

• Service Strategy is the core of the service lifecycle. It addresses what the organization must do to provide service to its customers (or users).  It provides guidance to help the organization determine and prioritize IT investments and commitments that become part of the Service Portfolio.  Guidance is provided to help IT align spending with business need (financial management) with the goal to minimize cost of ownership by measuring and modeling patterns of business activity. Fundamental concepts include guidance to create the proper balance between service utility (what it does, fit for purpose) and service warranty (reliability, fit for use). Service Strategy determines what and why a particular IT service should be chartered (built).

• Service Strategy addresses the "What to build" questions. Once the service has been chartered (resources committed, including funding), Service Design determines "How" it will be built to meet the needs of the customers/users of the service. This is where IT crafts the proper functionality (utility) of the service as well as appropriate reliability (warranty) expressed in terms of Capacity (is the pipe big enough — with input from Demand Management), Availability (is it there when it’s supposed to be), Continuity (what happens if there’s a disaster), and Security (how the service is appropriately protected).  Another aspect of Service Design is making sure that what is built actually meets customer / user needs.  Service Level Management (SLM) was part of Service Delivery in V2 is now part of Service Design in V3. As a software developer I believe this is a better place for this process. SLM is responsible for understanding customer- user-based requirements and crafting Service Level Agreements (commitments to the users regarding the proper Utility and Warranty of the service as well as user responsibilities for the service — yes, a 2-way agreement).

• Once the service is built, Service Transition processes have the responsbility to make sure the service will actually deliver the expected business value, before it’s put into production.  Change Management (familiar from V2) is described in this volume along with Release & Deployment Management (with expanded responsibility compared to Release Management in V2). In addition, V3 includes Early Life Support that provides for a pilot of both services and SLAs. Service Transition validates and verifies new or changed services at the same time it seeks to protect the live environment from disruptive changes.

• Service Operation provides guidance for the operation of services at the same time it describes the face of IT that the user sees (Service Desk). The volume covers the end-to-end (round-trip) delivery of the service to the end user from the datacenter.  The lifecyle phase of Service Operation defines the live environment for the service including required monitoring and measuring performance (capacity), availability, security, etc. against the terms defined in the SLAs. Feedback is provided across the lifecycle so that appropriate improvements or adjustments can be made.

• That brings us to Continual Service Improvement (CSI) the lifecycle area that is specifically charged with improving services and processes. An interesting side effect is that the techniques documented in the CSI volume can be used as part of the process of adopting the ITIL within an organization.  CSI (and all of ITIL draw on proven techniques, e.g., the Deming Cycle balancedscorecard.org/).

What’s coming

This article is intended to provide a very brief overview of the ITIL. For people already familiar with it, comments welcome. If this is new, and you have questions, please let me know.  I’ll address both comments and questions in a future article.

In future articles we’ll delve into the Benefits of the ITIL, ITIL Certification, and How to Adopt the ITIL.

David Moskowitz
ITIL Certified Instructor and Consultant
david.moskowitz@gmail.com