ITIL v3 Framework Overview

ITIL v3 Framework Overview


ITIL 2007 edition (previously known as version 3) is an extension of ITIL v2 and fully replaced it following the completion of the withdrawal period on 30 June 2011. ITIL 2007 provides a more holistic perspective on the full life cycle of services, covering the entire IT organization and all supporting components needed to deliver services to the customer, whereas v2 focused on specific activities directly related to service delivery and support. Most of the v2 activities remained untouched in 2007, but some significant changes in terminology were introduced in order to facilitate the expansion.


Changes and characteristics of the 2011 edition of ITIL

A summary of changes has been published by HM Government. In line with the 2007 edition, the 2011 edition consists of five core publications – Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. ITIL 2011 is an update to the ITIL framework that addresses significant additional guidance with the definition of formal processes which were previously implied but not identified, as well as correction of errors and inconsistencies.

Twenty-six processes are listed in ITIL 2011 edition and described below, along with which core publication provides the main content for each process.


ITIL 2007 has five volumes, published in May 2007, and updated in July 2011 as ITIL 2011 for consistency:

  1. ITIL Service Strategy: understands organizational objectives and customer needs.

  2. ITIL Service Design: turns the service strategy into a plan for delivering the business objectives.

  3. ITIL Service Transition: develops and improves capabilities for introducing new services into supported environments.

  4. ITIL Service Operation: manages services in supported environments.

  5. ITIL Continual Service Improvement: achieves services incremental and large-scale improvements.

Due to the similarity between ITIL v3 of 2007 and ITIL 2011, no bridge examinations for ITIL v3 certification holders were created or made available for ITIL 2011 certification.

ITIL v3 Lifecycle


1) Service Strategy


The center and origin point of the ITIL Service Lifecycle, the ITIL Service Strategy (SS) volume, provides guidance on clarification and prioritization of service-provider investments in services. More generally, Service Strategy focuses on helping IT organizations improve and develop over the long term. In both cases, Service Strategy relies largely upon a market-driven approach. The Service Strategy lifecycle stage is often considered as the core of the service life cycle. In Service Strategy stage, the strategic approach for the whole lifecycle is identified to provide values to the customers through IT service management. Key topics covered include service value definition, business-case development, service assets, market analysis, and service provider types.


List of covered processes:

  • Strategy management for IT Services

  • Service portfolio management

  • Financial management for IT services

  • Demand management

  • Business relationship management

For candidates in the ITIL Intermediate Capability stream, the Service Offerings and Agreements (SOA) Qualification course and exam are most closely aligned to the Service Strategy (SS) Qualification course and exam in the Life cycle stream.


Service Portfolio Management

The customer needs services to achieve their objectives. The service provider should ensure they can provide these services. The purpose of Service Portfolio Management is ensuring these services are offered.

The service portfolio contains the services managed by the service provider. The service portfolio comprises: the pipeline section, which contains the services that are yet to be offered; the service catalog section, which contains the details of operational services; and the retired section, which contains details of the services that are no longer offered.


Financial Management for IT services

IT Financial Management comprises the discipline of ensuring that the IT infrastructure is obtained at the most effective price (which does not necessarily mean cheapest) and calculating the cost of providing IT services so that an organization can understand the costs of its IT services. These costs may then be recovered from the customer of the service. This is the 2nd component of service delivery process.


ITIL Demand Management

In order for your IT organization to effectively deliver services to customers, it is important to understand what services are needed and when they are needed. This is commonly referred to as Pattern of Business Activity (PBA). Demand Management is the ability to understand your customer’s patterns, anticipate their changing needs, and influence behaviors related to their demand for services. Keep in mind that demand is not stagnant; rather, it is constantly changing based on a variety of influencers, including your industry, usage patterns determined by time of year, weather, a new product launch, and many other factors.



Demand Management and ITIL Process Relationships

The Demand Management process interfaces and communicates with several other ITIL processes, including Capacity Management, Availability Management, and Service Level Management. Demand Management also depends on information from customers - it receives customer information regarding the demand for services and shares that information with other processes, such as capacity management.

Capacity and Availability Management are very closely related to Demand Management. Consider this: if a call center needs to handle 1,000 calls each day, do they have the staff to handle the 1,000 calls as they arrive? The ability to provide the volume is the process of Capacity Management while Availability is responsible for providing the service when it is required. You may have enough staff to handle the volume, but that does not mean that they are in place at the right time. For example, what if 50% of the calls arrive in the first hour? The Demand Management process will aid in determining what you need in place to handle the calls as they arrive. You could describe demand as workflow management.” 

Availability Management (ensuring that the IT infrastructure and tools are in place to meet the availability needs of the business) is equally important. For example, if you anticipate high demand for web orders of a certain product during the holiday season, you must ensure that you have the infrastructure in place (website is available) to handle the demand. Service Level Management, which documents the IT organization’s service level target (timeframe and responsibilities) to deliver services to a customer, is also crucial. As an example, if your service level agreement states all calls will be answered within a certain time frame, you must have the people in place at the right time to handle the demand. 

All of these efforts to supply the capacity and availability to meet the demand for services has a direct influence on budget and finance. The business must plan ahead in order to develop plans for future budgeting. 



2) Service Design


The Service Design (SD) volume provides good-practice guidance on the design of IT services, processes, and other aspects of the service management effort. Significantly, design within ITIL is understood to encompass all elements relevant to technology service delivery, rather than focusing solely on design of the technology itself. As such, service design addresses how a planned service solution interacts with the larger business and technical environments, service management systems required to support the service, processes which interact with the service, technology, and architecture required to support the service, and the supply chain required to support the planned service. Within ITIL, design work for an IT service is aggregated into a single Service Design Package (SDP). Service design packages, along with other information about services, are managed within the service catalogs.

List of covered processes:

  1. Design coordination

  2. Service catalog management

  3. Service-level management

  4. Availability management

  5. Capacity management

  6. IT service continuity management

  7. Security management

  8. Supplier management

A model used to help define roles and responsibilities in service design is a RACI matrix (Responsible, Accountable, Consulted and Informed).



Service Catalog Management

Service catalog management maintains and produces the service catalog and ensures that it contains accurate details, dependencies and interfaces of all services made available to customers.

Service catalog information includes:

  • ordering and requesting processes

  • prices

  • deliverables

  • contract points

Service Catalog

Service-Level Management

Service-level management provides for continual identification, monitoring and review of the levels of IT services specified in the service-level agreements (SLAs).

Service-level management ensures that arrangements are in place with internal IT support-providers and external suppliers in the form of operational level agreements (OLAs) and underpinning contracts (UCs), respectively. The process involves assessing the impact of change on service quality and SLAs. The service-level management process is in close relation with the operational processes to control their activities. The central role of service-level management makes it the natural place for metrics to be established and monitored against a benchmark.

Service-level management is the primary interface with the customer (as opposed to the user serviced by the service desk).


Service-level management is responsible for:

  • Ensuring that the agreed IT services are delivered when and where they are supposed to be;

  • Liaising with availability management, capacity management, incident management and problem management to ensure that the required levels and quality of service are achieved within the resources agreed with financial management;

  • Ensuring that appropriate IT service continuity plans exist to support the business and its continuity requirements.

The service-level manager relies on the other areas of the service delivery process to provide the necessary support which ensures the agreed services are provided in a cost-effective, secure and efficient manner.


Availability Management

Availability management targets allows organizations to sustain the IT service-availability to support the business at a justifiable cost. The high-level activities are realizing availability requirements, compiling availability plans, monitoring availability, and monitoring maintenance obligations.

Availability management addresses the ability of an IT component to perform at an agreed level over a period of time.

  • Reliability: Ability of an IT component to perform at an agreed level at described conditions.

  • Maintainability: The ability of an IT component to remain in, or be restored to an operational state.

  • Serviceability: The ability for an external supplier to maintain the availability of component or function under a third-party contract.

  • Resilience: A measure of freedom from operational failure and a method of keeping services reliable. One popular method of resilience is redundancy.

  • Security: A service may have associated data. Security refers to the confidentiality, integrity, and availability of that data. Availability gives a clear overview of the end-to-end availability of the system.


Capacity Management

Capacity management supports the optimum and cost-effective provision of IT services by helping organizations match their IT resources to business demands.

The high-level activities include:

  • application sizing

  • workload management

  • demand management

  • modeling

  • capacity planning

  • resource management

  • performance management

Capacity management is focused on strategic capacity, including capacity of personnel (e.g., human resources, staffing and training), system capacity, and component (or tactical) capacity.



IT Service Continuity Management

IT service continuity management (ITSCM) covers the processes by which plans are put in place and managed to ensure that IT services can recover and continue even after a serious incident occurs. It is not just about reactive measures, but also about proactive measures – reducing the risk of a disaster in the first instance.

ITSCM is regarded by the application owners as the recovery of the IT infrastructure used to deliver IT services, but as of 2009 many businesses practice the much further-reaching process of business continuity planning (BCP), to ensure that the whole end-to-end business process can continue should a serious incident occur (at primary support level).


ITSCM involves the following basic steps:

  • prioritizing the activities to be recovered by conducting a business impact analysis (BIA)

  • performing a risk assessment (aka risk analysis) for each of the IT services to identify the assets, threats, vulnerabilities and countermeasures for each service.

  • evaluating the options for recovery

  • producing the contingency plan

  • testing, reviewing, and revising the plan on a regular basis.


Security Management

The ITIL-Process Security Management describes the structured fitting of information security in the management organization. It is based on the code of practice for information security management system (ISMS) now known as ISO/IEC 27002.

A basic goal of security management is to ensure adequate information security. The primary goal of information security, in turn, is to protect information assets against risks, and thus to maintain their value to the organization. This is commonly expressed in terms of ensuring their confidentiality, integrity and availability, along with related properties or goals such as authenticity, accountability, non-repudiation and reliability.

Mounting pressure for many organizations to structure their information security management systems in accordance with ISO/IEC 27001 requires revision of the ITIL v2 security management volume, which culminated in the release of the 2007 edition.


Supplier Management

The purpose of Supplier Management is to obtain value for money from suppliers and contracts. It ensures that underpinning contracts and agreements align with business needs, Service Level Agreements and Service Level Requirements. Supplier Management oversees process of identification of business needs, evaluation of suppliers, establishing contracts, their categorization, management and termination.



3) Service Transition


Service transition (ST), as described by the ITIL service transition volume, relates to the delivery of services required by a business into live/operational use, and often encompasses the "project" side of IT rather than business as usual (BAU). This area also covers topics such as managing changes to the BAU environment.

List of ITIL processes in service transition:

  1. Transition planning and support

  2. Change management

  3. Service asset and configuration management

  4. Release and deployment management

  5. Service validation and testing

  6. Change evaluation

  7. Knowledge management


Change Management

Change management aims to ensure that standardized methods and procedures are used for efficient handling of all changes. A change is an event that results in a new status of one or more configuration items (CIs), and which is approved by management, is cost-effective, enhances business process changes (fixes) – all with a minimum risk to IT infrastructure.

The main aims of change management include:

  • Minimal disruption of services

  • Reduction in back-out activities

  • Economic use of resources involved in the change

Common change management terminology includes:

  • Change: the addition, modification or removal of CIs

  • Request For Change (RFC) or, in older terminology, Change Request (CR): a form used to record details of a request for a change and is sent as an input to Change Management by the Change Requester

  • ITIL v2 - Forward Schedule of Changes (FSC): schedule that contains details of all forthcoming Changes.

  • ITIL 2007 - Change Schedule (CS): schedule that contains details of all forthcoming Changes, and references historical data. Many people still refer to the known term FSC.

There are three types of changes: Standard Change,Normal Change,Urgent/Emergency Change.


 Service Asset and Configuration Management

Service asset and configuration management is primarily focused on maintaining information (i.e., configurations) about Configuration Items (i.e., assets) required to deliver an IT service, including their relationships. Configuration management is the management and traceability of every aspect of a configuration from beginning to end and it includes the following key process areas under its umbrella:

  • Identification

  • Planning

  • Change control

  • Change management

  • Release management

  • Maintenance


Release and Deployment Management

Release and deployment management is used by the software migration team for platform-independent and automated distribution of software and hardware, including license controls across the entire IT infrastructure. Proper software and hardware control ensures the availability of licensed, tested, and version-certified software and hardware, which functions as intended when introduced into existing infrastructure. Quality control during the development and implementation of new hardware and software is also the responsibility of Release Management. This guarantees that all software meets the demands of the business processes. Release management utilizes Definitive Media Library for storage of software.


The goals of release management include:

  • Planning the roll-out of software

  • Designing and implementing procedures for the distribution and installation of changes to IT systems

  • Effectively communicating and managing expectations of the customer during the planning and roll-out of new releases

  • Controlling the distribution and installation of changes to IT systems

Release management focuses on the protection of the live environment and its services through the use of formal procedures and checks.


A Release consists of the new or changed software and/or hardware required to implement approved changes. Release categories include:

  • Major software releases and major hardware upgrades, normally containing large amounts of new functionality, some of which may make intervening fixes to problems redundant. A major upgrade or release usually supersedes all preceding minor upgrades, releases and emergency fixes.

  • Minor software releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.

  • Emergency software and hardware fixes, normally containing the corrections to a small number of known problems.

Releases can be divided based on the release unit into:

  • Delta release: a release of only that part of the software which has been changed. For example, security patches.

  • Full release: the entire software program is deployed—for example, a new version of an existing application.

  • Packaged release: a combination of many changes—for example, an operating system image which also contains specific applications.



4) Service Operation


Service Operation (SO) aims to provide best practice for achieving the delivery of agreed levels of services both to end-users and the customers (where "customers" refer to those individuals who pay for the service and negotiate the SLAs). Service operation, as described in the ITIL Service Operation volume, is the part of the lifecycle where the services and value is actually directly delivered. Also the monitoring of problems and balance between service reliability and cost etc. are considered. The functions include technical management, application management, operations management and service desk as well as, responsibilities for staff engaging in Service Operation.

List of processes:

  1. Event management

  2. Incident management

  3. Request fulfillment

  4. Problem management

  5. Identity management

  6. Functions
  7. Service desk

The service desk is one of four ITIL functions and is primarily associated with the Service Operation lifecycle stage. Tasks include handling incidents and requests, and providing an interface for other ITSM processes.


Features include:

  • single point of contact (SPOC) and not necessarily the first point of contact (FPOC)

  • single point of entry

  • single point of exit

  • easier for customers

  • streamlined communication channel

Primary purposes of a service desk include:

  • incident control: life-cycle management of all service requests

  • communication: keeping a customer informed of progress and advising on workarounds

The service desk function can have various names, such as:

  • Call center: main emphasis on professionally handling large call volumes of telephone-based transactions

  • Help desk: manage, co-ordinate and resolve incidents as quickly as possible at primary support level

  • Service desk: not only handles incidents, problems and questions but also provides an interface for other activities such as change requests, maintenance contracts,

    software licenses, service-level management, configuration management, availability management, financial management and IT services continuity management.


The three types of structure for consideration:

  • Local service desk: to meet local business needs – practical only until multiple locations requiring support services are involved

  • Central service desk: for organizations having multiple locations – reduces operational costs and improves usage of available resources

  • Virtual service desk: for organizations having multi-country locations – can be situated and accessed from anywhere in the world due to advances in network performance and telecommunications, reducing operational costs and improving usage of available resources


Application Management

ITIL application management encompasses a set of best practices proposed to improve the overall quality of IT software development and support through the life-cycle of software development projects, with particular attention to gathering and defining requirements that meet business objectives.

Software asset management (SAM) is a primary topic of ITILv2 and is closely associated with the ITIL Application Management function. SAM is the practice of integrating people, processes, and technology to allow software licenses and usage to be systematically tracked, evaluated, and managed. The goal of SAM is to reduce IT expenditures, human resource overhead and risks inherent in owning and managing software assets.

SAM practices include:

  • maintaining software license compliance

  • tracking inventory and software asset use

  • maintaining standard policies and procedures surrounding definition, deployment, configuration, use, and retirement of software assets and the definitive software library.

SAM represents the software component of IT asset management. This includes hardware asset management because effective hardware inventory controls are critical to efforts to control software. This means overseeing software and hardware that constitute an organization's computers and network.


Event Management

An event may indicate that something is not functioning correctly, leading to an incident being logged. Events may also indicate normal activity, or a need for routine intervention such as changing a tape. Event management depends on monitoring, but it is different. Event management generates and detects notifications, while monitoring checks the status of components even when no events are occurring. Events may be detected by a CI sending a message, or by a management tool polling the CI. After an event has been detected it may lead to an Incident, Problem or Change, or it may simply be logged in case the information is needed. Response to an event may be automated or may require manual intervention. If actions are needed then a trigger, such as an SMS message or an incident being automatically logged, can alert support staff.


Incident Management

Incident management aims to restore normal service operation as quickly as possible and minimize the adverse effect on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within service-level agreement (SLA) limits.

An incident is defined as:

2007: An unplanned interruption to an IT service or a reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident. For example, failure of one disk from a mirror set.

V2: An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services and customer productivity.

The objective of incident management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price. The transformation between event-to-incident is the critical junction where Application Performance Management (APM) and ITIL come together to provide tangible value back to the business.



Request Fulfillment

Request fulfillment (or request management) focuses on fulfilling Service Requests, which are often minor (standard) changes (e.g., requests to change a password) or requests for information.

The term "standard change" means per-approved, repeatable, per-defined, low risk changes. If the change does not meet these criteria then it is not a standard change and should be defined as a request for change.


Problem Management

Problem management aims to resolve the root causes of incidents and thus to minimize the adverse impact of incidents caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors. A "problem" in this context is the unknown underlying cause of one or more incidents, and a 'known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified. The CCTA (Central Computer and Telecommunications Agency) defines problems and known errors as follows:

- A problem is a condition often identified as a result of multiple incidents that exhibit common symptoms. Problems can also be identified from a single significant incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.

- A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a work-around.

Problem management differs from incident management. Problem management aims primarily to find and resolve the root cause of a problem and thus prevent further incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.

The problem-management process reduces the number and severity of incidents and problems on the business, and documents the details of the problem and resolution to be available for the first-line and second-line of the help desk. The proactive process identifies and resolves problems before incidents occur.

Such processes include:

  • Trend analysis

  • Targeting support action

  • Providing information to the organization

The error control process iterative diagnoses known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.


The problem control process aims to handle problems in an efficient way. Problem control identifies the root cause of incidents and reports it to the service desk. Other activities are:

  • Problem identification and recording

  • Problem classification

  • Problem investigation and diagnosis

Root-cause analysis

Root-cause analysis is a formal problem-solving process and a critical component of Problem Management. Once a problem (or potential problem) has been identified, the root cause analysis process begins. The purpose of a root cause analysis is two-fold:

  1. develop a thorough understanding of the problem and its causes

  2. identify corrective/preventive actions that will reduce the risk of recurrence to an acceptable level

Benefits from employing a standard, structured root-cause analysis methodology include:

  • common terms, language, and structure with respect to root cause analysis

  • problem identification, including actual and potential impact

  • identification of the problem's causes, their interactions, and the supporting evidence

  • identification of corrective/preventive actions (CAPA) that will prevent recurrence of the problem

  • development of a knowledge base which others can use as a resource

Change-Management-Core-Stages Identity Management

Identity management (IdM) less commonly called Access and Identity Management (AIM) as a process focuses on granting authorized users the right to use a service, while preventing access to non-authorized users. Certain identity management processes executes policies defined in Security Management.


5) Continual Service Improvement (CSI)


Continual service improvement, defined in the ITIL continual service improvement volume, aims to align and realign IT services to changing business needs by identifying and implementing improvements to the IT services that support the business processes. It incorporates many of the same concepts articulated in the Deming Cycle of Plan-Do-Check-Act. The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle. To manage improvement, CSI should clearly define what should be controlled and measured.


CSI needs upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned,and activities identified to be successful. CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting. Continual Service Improvement and Application Performance Management (APM) are two sides of the same coin. They both focus on improvement with  tyAPMing together service design, service transition, and service operation which in turn helps raise the bar of operational excellence for IT.

Improvement initiatives typically follow a seven-step process:

  1. Identify the strategy for improvement

  2. Define what you will measure

  3. Gather the data

  4. Process the data

  5. Analyze the information and data

  6. Present and use the information

  7. Implement improvement


    ISO/ IEC 20000


    ISO/IEC 20000 is the first international standard for IT service management. It was developed in 2005, by ISO/IEC JTC1/SC7 and revised in 2011. It is based on and intended to supersede the earlier BS 15000 that was developed by BSI Group.

    ISO/IEC 20000-1:2011 is the international standard for IT service management. Is it just for large organizations or does it work for very small organizations as well? How can it help your organization provide better service?


    ISO/IEC 20000, like its BS 15000 predecessor, was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework, although it equally supports other IT service management frameworks and approaches including Microsoft Operations Framework and components of ISACA's COBIT framework. The differentiation between ISO/IEC 20000 and BS 15000 has been addressed by Jenny Dugmore.

    The standard was first published in December 2005. In June 2011, the ISO/IEC 20000-1:2005 was updated to ISO/IEC 20000-1:2011. In February 2012, ISO/IEC 20000-2:2005 was updated to ISO/IEC 20000-2:2012


  • No. 22, Zeytoon Building, Javaheryan St., Sattari Expy, Tehran, Iran
  • +9821 - 449 78 699
  • +9821 - 446 28 335
  • +98 - 930 584 2566
  • Info @ TaksaSystem.com

Send Message

  Mail is not sent.   Your email has been sent.