White Paper An Introduction to ITIL 

Triumfant ITIL Primer

Triumfant ITIL Primer  Page 2 

Overview: 

Definition, History, Purpose and Relevance 

ITIL stands for Information Technology Infrastructure Library, and is literally a set of books developed by the British government. Figure 1 shows the various books that comprise the library. The Central Computer and Telecommunications Agency (CCTA) of the U.K. was the original owner of ITIL. As of 2001, however, the CCTA became part of the Office of Government Commerce (OGC), which is the current owner of ITIL today. 

ITIL was developed under the premise that organizations were becoming increasingly dependent upon IT to fulfill their corporate objectives. This growing dependency gave way to the need for those IT services to maintain quality standards that corresponded to the objectives of the business, which in turn relate to the requirements and expectations of the customer. ITIL provides a set of best practices for IT service processes to provide effective and efficient services in support of the business. 

ITIL is not a standard. BS15000 is a British standard for IT Service Management based heavily upon ITIL. ISO20000 has been proposed as the international version of the BS15000 standard. ITIL is also a core part of the foundation of Control Objectives for Information and related Technology (COBIT). COBIT is the framework of choice for external auditors performing IT audits for Sarbanes­Oxley (SOX). Together, ITIL and COBIT provide a formidable combination to achieve SOX compliance. 

ITIL has been rapidly adapted across Europe for best practices and is rapidly gaining acceptance across the globe. As SOX and other IT governance issues become driving forces for many organizations, ITIL will be looked at seriously as a key component for achieving compliance within IT for those governance bodies.

Triumfant ITIL Primer  Page 3 

Figure 1: ITIL Publication Framework 

IT Service Management 

Much of the focus on ITIL is within IT Service Management (ITSM). ITSM pertains to the delivery and support of IT services that meet the requirements of the business organization. This primer will focus on the Service Support domain. Table 1 shows the various components contained within ITSM. 

Table 1: IT Service Management Processes 

Service Support ­ Operational Processes 

ITIL Service Support generally focuses on the daily operation and support of IT services and is broken down into five main processes and one key function. These processes, functions, and their relationships to one another are illustrated in Figure 2.

Triumfant ITIL Primer  Page 4 

Figure 2: ITIL Service Support 

The Service Desk 

The service desk is the only function within the ITIL framework. It handles incidents, problems and questions and is responsible for resolving incidents as quickly as possible. The service desk usually serves as the single point of contact for customers and is integrated into other service management processes and business processes. There are various classes of service desk that correspond to the capabilities required within a given IT organization. These capabilities can range from simple call routing to expert­level specialists resolving incidents. 

Incident Management: 

The goal of the Incident Management process is to restore service as quickly as possible with minimal disruption to the business. This allows the highest levels of service and availability to be maintained. An incident comprises any event, not part of a standard service operation, which causes, or may cause, an interruption or reduction in quality of service. Incidents are typically broken down into two categories—service requests and all other incidents. Service requests include requests for information or documentation and non­urgent requests (e.g., How To's, Password Resets, etc.). 

Important ITIL Terms 

Incident: Any event, not part of a standard service operation, which causes, or may cause, an interruption or reduction in quality of service.

Triumfant ITIL Primer  Page 5 

Problem: A condition characterized by multiple incidents exhibiting common symptoms, or a single significant incident for which the root cause is unknown. Known Error: A problem for which the root cause and a workaround have been determined. 

ITIL Incident Management Process 

As shown in the diagram above, there are many activities that make up Incident Management. These include:

• Incident Acceptance and Recording ­ Incidents arrive at the service desk via many possible avenues including phone, email, fax, self­service portals, etc. Regardless of the method, a record of the incident is recorded.

• Classification and Initial Support ­ Incidents are coded by type, status, impact, urgency, Service Level Agreement (SLA), priority, etc. The service desk may give the user suggestions to solve the issue, even if they provide only a temporary workaround.

• Service Requests ­ If the incident is a service request, the appropriate procedure for that request is initiated.

• Matching ­ Incidents are investigated and initially compared to a known error database. This database typically comprises a common knowledge base utilized by the service desk in addition to what an individual service desk administrator may already know. If 

the incident is not recognized as a known error, it is then compared to entries within the known problem database. Here, problem records identify open problems that are currently under investigation or pending change resolution. If the incident

Triumfant ITIL Primer  Page 6 

matches either a known error or known problem, it is matched to a known solution or workaround, respectively.

• Investigation and Diagnosis ­ If there is no match of known errors or known problems, the incident must be further investigated. This involves gathering as much information as possible about the incident to determine how to restore service as quickly as possible. If first level support within the service desk cannot determine a solution, the incident is escalated to second level support. This escalation process continues as appropriate according to SLAs, internal procedures, etc. If no resolution can be found, the incident is declared a problem and the Problem Management process is initiated.

• Resolution and Recovery ­ Once a solution is found, the issue is resolved by restoring services to normal operation.

• Closure ­ After the user verifies that service has been restored satisfactorily, the incident is closed. 

Problem Management: 

The Problem Management process has the goal of minimizing the adverse impact of incidents and problems resulting from errors within the IT infrastructure, and to prevent the recurrence of incidents related to those errors. There are two different types of activities within Problem Management—Proactive and Reactive. 

Proactive Problem Management: Prevents incidents from occurring by identifying weaknesses or errors in the infrastructure and proposing applicable resolutions. Although most organizations aspire to implement this portion of Problem Management, few are able to achieve success for reasons to be discussed later. 

Reactive Problem Management: Identifies the root cause of past incidents and proposes improvements and resolutions. Figure 4 illustrates how Reactive Problem Management is broken down into two areas: Problem Control and Error Control.

Triumfant ITIL Primer  Page 7 

Problem Management Process 

Problem Control:  Identifies underlying root causes of incidents to prevent future recurrences. Problem Control consists of the following activities:

• Analysis ­ Information is gathered to be analyzed from various sources including outputs from various ITIL processes such as Incident Management, Capacity Management, Configuration Management, Service Level Management and Availability Management.

• Problem Identification and Recording ­ Parameters defining the problem are established, such as recurring incident symptoms or service degradation threatening SLAs. Problem characteristics are recorded within the known problem database. Future incidents that occur related to the individual problem may reference the problem record.

• Classification and Allocation ­ Problems are classified by category, impact, urgency, priority and status.

• Investigation and Diagnosis ­ Data obtained from various processes and locations is analyzed to diagnose the root cause of the problem. This activity may include re­creating the problem or several iterative phases to deduce the actual root cause. Once the root 

cause has been determined, a workaround is developed if required. Once the

Triumfant ITIL Primer  Page 8 

diagnosis is complete, the problem is turned into a known error and is passed to the Error Control portion of Problem Management. 

Error Control:  The process of monitoring and providing solutions for known errors until they are resolved. Error control contains the following activities:

• Known Error Identification and Recording ­ Once the root cause has been determined, the problem status changes to known error. A workaround is developed to feed back to Incident Management to handle future incidents that occur before a final solution is implemented. The known error definition can also be sent to the known error database to be used in the matching process.

• Solution Investigated ­ An assessment is performed on what will be required to resolve the known error. This activity could consist of cross­functional teams to weigh different solutions on various criteria including costs and benefits.

• Defining Solution ­ A final solution is developed and a Request for Change (RFC) is made via the Change Management Process.

• Problem Evaluation and Review ­ After the change has been implemented, a Post Implementation Review (PIR) is performed to evaluate the success of the solution and associated changes.

• Closure ­ Assuming the problem review declares the solution as successful, the problem is finally closed.

Triumfant ITIL Primer  Page 9 

Change Management: 

The goal of Change Management is to manage the process of change through standardized methods and procedures, thereby limiting incidents related to change and improving day­to­day operations. 

Change Management Process 

Throughout the Change Management process, illustrated in the figure above, various levels of management may need to be involved for approval and planning depending on the type of change. Typically there is a Change Manager, a Change Advisory Board (CAB), and an emergency change committee. The following activities are performed for all non­standard changes:

• Request for Change (RFC) ­ Other ITIL processes, customers and IT personnel make requests for modifications to the managed infrastructure. These changes are typically

Triumfant ITIL Primer  Page 10 

not considered Service Requests, as those are considered standard changes that do not need to be individually addressed by Change Management.

• Recording ­ Information relevant to the RFC is recorded that includes a change identification number, relevant problem/known error, justification, description, change date, request originator information, and what configuration items are to be changed.

• Acceptance ­ RFCs are checked for valid information and either accepted or denied. Typically the acceptance involves financial approval, technical approval and business approval.

• Classification ­ Priorities and categories are specified for RFCs. Priority specifies the level of importance and category specifies the basis of impact and resources.

• Planning ­ A change calendar, or Forward Schedule of Changes (FSC), details all approved and planned changes. The CAB will meet to discuss the various considerations surrounding the RFC, such as dependencies, conflicts with other changes, impact to resources and other services, back­out plans, change window, etc.

• Coordination ­ Change Management is responsible for the coordination of building, testing and implementing the change. This is typically done in conjunction with the Release Management process.

• Evaluation ­ Results of non­standard changes should be evaluated to ensure that objectives were met, users are satisfied, evaluate possible side effects, and confirm if changes were within the projected budget.

• Closure ­ After a successful evaluation, the RFC is closed. 

Release Management: 

The goal of Release Management, illustrated in the figure below, is to ensure quality within the production environment through a managed rollout of new versions within the managed infrastructure. Change Management is focused on the coordination and planning of changes while Release Management is focused on the actual implementation of those changes. 

Release Management also works with Configuration Management to ensure that the CMDB is kept up to date and that all new software releases are stored in the Definitive Software Library (DSL). All spare hardware components and assemblies are stored within the Definitive Hardware Store (DHS).

Triumfant ITIL Primer  Page 11 

Release Management Process 

The following activities are part of Release Management:

• Policy and Planning ­ A document, called the Release Policy, is developed by the Release Manager and defines how and when releases are configured. Prior to planning a release, information must be gathered about various aspects of the release, such as product life cycle, description of relevant IT service and service levels, authorization for relative RFCs, etc. Planning the release involves coordination, scheduling, communication planning, definition of roles and responsibilities, development of back­out and quality plans, and more.

• Design, Building and Configuration ­ Standard and reusable procedures and documentation should be used for designing, building and configuring releases. Configuration items within the release may come from internal or external bodies. In either case, laboratory­based development testing along with appropriate operational documentation should be prerequisites before a release is considered available for implementation.

• Testing and Acceptance ­ Lack of testing is the most common cause for unsuccessful changes and releases. Releases should undergo functional, operational, performance and integration testing by the appropriate personnel. Testing should include back­out plans. Acceptance should be performed for each step of the release process and be submitted to Change Management for approval. Once approved, the release can be rolled out and the relevant configuration changes can be integrated within the CMDB (see Configuration Management).

Triumfant ITIL Primer  Page 12

• Rollout Planning ­ Includes a detailed timetable of release events including staff responsibilities and action items, documentation and purchasing plans for required hardware and software.

• Communication ­ Personnel, typically the Service Desk or Customer Relations, communicate the planned changes to users and the expected service impact. Training sessions may be required to aid users with the release.

• Distribution and Installation ­ Involves the distribution of software and supporting hardware identified and approved in the previous activities. 

Configuration Management: 

The goal of Configuration Management is to manage the value of IT services by maintaining a logical model of the IT infrastructure and services, and by providing information about them to other processes. This is accomplished by identifying, monitoring, controlling and providing information about configuration items and their versions. Configuration Management aims to have reliable records of IT components and services, while also providing accurate documentation. 

Configuration Management, illustrated in the figure below, identifies the various components of IT infrastructure as Configuration Items (CIs). All of the information regarding CIs is held within the Configuration Management Database (CMDB). 

Configuration Management Process

Triumfant ITIL Primer  Page 13 

The following are activities within the Configuration Management Process:

• Planning ­ Defining the scope, purpose, objectives, priorities, policies and procedures of the Configuration Management process.

• Identification ­ Defining and maintaining configuration structures for CIs including naming conventions, version numbers, physical components, interrelationships and documentation. This activity involves allocating identifiers and version numbers, and entering data into the CMDB.

• Control ­ Ensures the authorization and recording of CI changes, such as additions, deletions, relationship changes, etc.

• Status Monitoring ­ Tracks life cycle states of CIs. • Verification ­ Auditing used to validate the physical existence of CIs and that the 

corresponding entries in the CMDB are accurate.