Information Technology Infrastructure Library (ITIL)

Overview of ITIL

Information Technology Infrastructure Library (ITIL) is a set of standard practices for managing IT services, development, and operations. The United Kingdom’s Central Computer and Telecommunications Agency (CCTA) developed the standards, or set of recommendations, in the 1980s. These standards are published in “books”, the initial set of books numbered over 30 volumes. Because of the massive amount of information, the CCTA consolidated the 30 volumes into 8 books in 2000 for version 2 of the library. In 2009, the Office of Government Commerce (a successor of the CCTA) announced that second version of the ITIL would be withdrawn and as of early 2010 version 3 with 5 volumes is available. Version 2 has nine books in the ITIL, the ninth book is ITIL Small-Scale Implementation that has additional guidelines for smaller IT units.

The original eight books in version 2 of the ITIL are:

1. Service Support - focuses on the user of the IT services to provide the information and services the user needs to support business services

2. Service Delivery - focuses on the services needed to provide support to the business users. Included in this book is service level management, capacity management, continuity management, availability management, and financial management.

3. Security Management - focuses on protecting the confidentiality, integrity, and availability of the information assets.

4. ICT Infrastructure Management - (ICT is an acronym for Information and Communication Management) focuses on the best practices for requirements analysis, planning, design, deployment and ongoing operations management.

5. ICT Technical Support - focuses on providing support to the other processes, i.e., research and development, marketing, and the creation of documentation

6. The Business Perspective - is a collection of best practices to address the issues encountered in providing high quality IT management

7. Application Management - focuses on best practices to improve the overall quality of IT software development and support

8. Software Asset Management - includes best practices for maintaining software license compliance, tracking inventory and software asset use, maintaining policies and procedures for defining, deploying, configuring, using and retiring the software assets.

ITIL Service Desk

The ITIL Service Desk is a component of the Service Support book of the Information Technology Infrastructure Library (ITIL). The Service Desk is the single point of contact or entry for an end user that needs help with an issue. The goal of the Service Desk is to help restore normal business operations with little or no business impact to the Customer within the stated response time frames and priorities. To accomplish this goal an ITIL Service Desk performs at a minimum the following activities: Receive all calls and emails on incidents/problems, Incident recording, Incident classification, Incident prioritization, Incident escalation, Update the Customer and other parties on progress, Provide communication for other ITIL activities such as release notifications and change schedules, Reporting on Service Desk performance.

The ITIL Service Desk is the process used to combine the best practices detailed in two ITIL books, Service Support and Service Delivery, and has two main functions, incident control/management and communication. These functions can be further defined into the following sub-functions:

Service Support

Incident management

Problem management

Configuration management

Release management

Change management

Service Delivery

Availability management

Capacity management

IT Service Continuity management

Financial management

Service Level management

The Service Desk is the mechanism the Customer uses to record an incident or problem. It is also used as the communication portal for monitoring the activities and processes associated with the sub-functions listed above. The sub-functions are described in more detail below.

Service Support

Incident management aims to restore normal business operations with little or no impact to the Customer by providing a process to record, track, and review an incident. According to the ITIL documentation there is a difference between an incident and a problem. An incident is defined as any event that deviates from the standard operation of the process and causes or has the potential to cause a disruption in the Customer’s service. A problem is an unknown underlying cause of one or more incidents.

Problem management aims to determine and resolve the root cause of incidents and problems and to minimize the adverse impact to the Customer’s business. Also part of problem management is the error control process and the problem control process. The error control process, through an iterative process, diagnoses known errors until they are eliminated by successfully implementing a change using the Change management process. The problem control process has four defined activities: identification of the root cause of reported incidents, problem identification and recording, problem classification, and problem investigation and diagnosis.

Configuration management is the process responsible for maintaining information about configuration items required to deliver an IT Service, enabling control of the infrastructure by monitoring and maintaining information on all the resources needed to deliver services. At a minimum this includes planning, control, status monitoring, verification and audit.

Release management focuses on the protection of the production environment and its services through the use of formal methodologies and procedures. A release is defined as a collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT Services. The goals of release management include: planning the rollout of the software or hardware, designing and implementing procedures for the distribution and installation of the release, communicating to and managing the expectations of the Customer during the release, and controlling the distribution and installation of the release into the IT systems.

Change management is the process of using standardized methodologies and procedures to reduce the risk of any changes to the software or hardware adversely impacting the Customer. A change is defined as the addition, modification or removal of anything that could have an effect on IT services. The main goals of change management are to minimize disruption to service, reduce the need for back-out activities, and efficient utilization of resources involved in the change.

Service Delivery

Availability management responsible for ensuring that all IT infrastructure, processes, tools, roles etc are appropriate for the agreed service level targets for availability. The components of availability management include: reliability, maintainability, serviceability, resilience and security.

Capacity management is responsible for ensuring that the capacity of IT services infrastructure is able to deliver agreed service level targets in a cost effective and timely manner. Capacity Management considers all resources required to deliver the service, and plans for short, medium and long-term business requirements.

IT service continuity management is the recovery of the IT infrastructure used to delivery the services. This includes plans are defined and put into action that ensure that the services can recover and continue in operation should a serious incident or problem occur.

Financial management is making sure that the IT infrastructure is purchased at the most effective cost. This includes calculating the costs of running and maintaining the IT processes so that the company understands the true costs of the IT systems. This also helps the company in setting prices for services provided to the Customer.

Service level management is perhaps the most important piece of the Service Desk process. This is what the Customer uses to be sure they are getting the service they are paying for. A service level is a measured and reported achievement against one or more service level targets. Service level management involves the use of metrics compared against a benchmark.

Diagram of an ITIL Service Desk process

Profile of an ITIL Consulting Company

Enterprise Consulting Services (ECS) is a “boutique consulting firm specializing in IT service management consulting, implementation and outsourcing using the ITIL framework”. The target audience for their services is CEOs, CFOs, and CIOs with a “charter to improve service and reduce the total cost of the technology support infrastructure. The services offered by ECS include IT Service Management, IT Asset Life Cycle Management and IT Security Management across the “IT value chain”. The ECS services overview sheet details how their consulting services will do to help a client’s overall IT processes. They also include a diagram of what a Service Desk Design should look like but their documentation is very quick to point out that their services and solutions are vendor neutral. However, the documentation points out that ECS has worked with many different providers, including Microsoft, Dell, HP, Altiris, and Courion.

The listing of clients on the company website is quite diverse. It includes Bausch & Lomb, EnergyEast (a utility company), Wegmans, Constellation Brands, Ontario County e-Government, Citi, TRW, Sungard , and SMU. Of particular interest to me was the implementation of an ITIL initiative for EnergyEast. EnergyEast is an electric and gas distribution company that serves 3 million customers in five states in the Northeast US. ECS integrated incident management, asset request management and security identity management into the company’s infrastructure. Included in this was a redesign of the existing incident, request and monitoring processes using the ITIL frameworks, along with the implementation of a self service “Smart Form” that provided one stop shopping for end user incident management.

ITIL Software Tool

SysAid Technologies has a Service Desk product call SysAid. This product is offered as a Software as a Service (SaaS). The product incorporates the best practices as details in the ITIL documentation. SysAid has two versions, one has what are deemed as core modules and the full version that includes an ITIL Problem Management module, an ITIL Change Management module, and an ITIL Configuration Management Database module in addition to the core modules.

This is a web based product that uses a 3 tiered architecture configuration (an end user view, an application layer, and a database layer).

The core modules included in their Service Desk product are:

Helpdesk - has all the core functionality for incident tracking for an ITIL Service Desk product

End-User Portal - easy submission of incidents and requests, includes a FAQ database for users to use in resolving their own technical issues

Knowledgebase - database for storing resolutions for the most common service requests

Asset Management - houses all hardware and software changes, and can interface with external purchasing systems

Remote Control - IT personnel can gain control over remote computers

Reports & Analysis - includes pre-defined reports along with the ability to create reports "on the fly"

SysAid Chat - an instant message service for anyone logged into SysAid

IT Benchmark - monitors metrics against defined benchmarks

The additional modules that can be added to SysAid are:

Tasks and Projects - a project management tracking tool

Advanced Monitoring - provides additional network monitoring

Manager Dashboard - provides a real time snapshot of the overall Service Desk system, also has the ability to drill down for additional information

ITIL Problem Management - tracks and manages root problem causes

ITIL Change Management - track, monitor and report on all past and current change activity, schedule and monitor progress for all future changes

ITIL Configuration Management Database - helps the user to track elements in the IT network

Software Design Patterns

Software Design is easy enough to understand but what the heck is a pattern when thinking about software design. Is it repetition, a template, a basic design paradigm, just what the heck is it. It turns out that a software design pattern is all of the above and more.

Christopher Alexander has been credited with being the first to use the term “design patterns”. He first used the term in 1964 to describe architectural patterns, a solution to a commonly occurring architectural problem. He saw the same problems appearing over and over in different architectural projects, i.e., how many windows does a room need, and the same solutions being used for these problems, i.e., the number of windows needed depends on the function of the room (context), the desires of the customer, and the buildings products available. Alexander further stated that “a pattern described a problem that occurs over and over again and the core solution to that problem is such a way that you can use the solution a million times over without doing it the same way twice”.

As Christopher Alexander continued his examination of design patterns he coined the term “pattern language” which is simply a collection of design patterns that relate to a particular field. More precisely, pattern language is a structured method of describing good design practices within a field of expertise. This is what is referred to in today’s software environment as “best practices”. Emulating good design decisions while steering away from bad design decisions (anti-patterns).
According to Alexander every pattern we define must be formulated in the form of a rule, which establishes a relationship between a context, a system of forces that arises in that context and a configuration that allows these forces to resolve themselves in that context.

Pattern language as applied to software was further defined by what is known as the “Gang of Four”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They wrote a book, Design Patterns: Elements of Reusable Object-Oriented Software. In this book, published in the mid 1990’s the Gang of Four used the premises put forth by Christopher Alexander to describe reusable solutions to commonly recurring problems in software design. Reusing design patterns helps prevent issues that cause major problems (using best practices or learning from other’s mistakes).

This all sounds interesting but how does this apply to software design. I think it all boils down to this, you don’t have to reinvent the wheel! In today’s world, software design patterns are most often applied at the architectural level and one of the most often used patterns is the Model-View-Controller (MVC) pattern. However, there are many more design patterns relevant to software design. I personally like the three-tier architecture, a client-server architecture with distinct processes for the presentation, the application processing, and the data management.

The three-tier architecture has three distinct layers or tiers that are independent of each other but are connected by defined interfaces. This design allows for the tiers to be upgraded or replaced independently of the others as the need may arise, such as a change in requirements or technology.

The presentation tier is at the top. This tier displays (presents) the information to the user. Typically, this involves HTML pages and JSPs. This is what the user sees and interacts with. The application tier (Logic tier in the diagram below) controls the flow of the software application. This tier is sometimes referred to as the business rules tier because it is here that the business rules are implemented. The application tier controls the flow of data between the presentation tier and the data tier. The third tier is the data management tier. This is where the databases are found, where the data is stored and retrieved.

A diagram of the Three Tier Design Pattern.

There is a definite difference between the MCV design pattern and the Three Tier Architecture design pattern. In the Three Tier architecture design pattern the client tier does not communicate directly with the data tier, all communication must pass through the application tier. In contrast, in the Model View Controller design pattern, each object communicates with the other objects, which means less independence and modularity.