Overview of the ITIL v3 Library

In order to improve the framework for presenting best practices, the ITIL version 3 developed the ITIL service lifecycle as illustrated in the schematic to the right. The five volume in the ITIL Version 3 set, published in May 2007, correspond to the five primary process areas depicted in this modelR:

  1. Service Strategy
  2. Service Design
  3. Service Transition
  4. Service Operation
  5. Continual Service Improvement

The model shows Service StrategyN at the centre providing practices and techniquesN for Service Design, Transition and Operations that exist in an iterative loop fed by Continual Service Improvement practicesN, techniques and processesN.

In truth, there is no clear distinction between what is presented as processes, functions and techniques in Service Strategy and Continual Service Improvement. Conceptually they stand out from the other three 'lifecycle' processes and throughout the lifecycle phases of Design, Transition and Operations elements of Strategy and Improvement are invoked.

The five ITIL Version 3 books (service lifecycle stage ??) are:

ITIL Process Schematic
ITIL Process Schematic

Service Strategy

Chief Author - David Cannon, HP
As the center and origin point of the ITIL Service Lifecycle, the Service Strategy volume provides guidance on clarification and prioritization of service provider investments in services. This book was an update of the Version 2 publication - The Business Perspective with a decided re-focus towards an industry perspective - one reflecting the views and compositions of the authorship: a market-driven approach. Key topics covered include service value definition, business case development, service assets, market analysis, and service provider types.

    Economic Techniques
  • Return on Investment (ROI) Analysis
  • Service Management MethodologyR
"user feedback and feedback from the training community indicate that the Service Strategy publication is difficult to understand. The text needs to be made more accessible by using simpler language, so that all the concepts remain the same but are explained in a clearer manner. The readability is to be improved by a technical edit that will involve rewording but not necessarily rewriting the whole text."

OGC Mandate for Change, Project requirements for an update to the ITIL® core publications © The Stationery Office 2009, September 2009, p 3.

Service Design

Chief Author - Lou Hunnebeck, Third Sky
The ITIL Service Design 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 interacts with the service, technology, and architecture required to support the service, and the supply chain required to support the planned serviceD.

    Technical Activities
  • Requirements Engineering
  • Data & Information Management
  • Application Management

Service Transition

Chief Author - Stuart Rance, HP
Service transition relates to the delivery of services required by the business into live/operational use, and often encompasses the "project" side of IT rather than "BAU" (Business As Usual). This area also covers topics such as managing changes to the "BAU" environment.

  • Managing Communications & Commitment
  • Managing Organization & Stakeholder Change
  • Stakeholder Management

Service Operation

Chief Author - Randy Steinberg, ITSM Strategies Inc
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 Operations 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.

  • Monitoring And Control
  • IT Operations
  • Mainframe Management
  • Server Management & Support
  • Network Management
  • Storage & Archive
  • Database Administration
  • Directory Services Management
  • Desktop Support
  • Middleware Management
  • Internet/Web Management
  • Facilities and Data Centre Management
  • Information Security Management & Service Operation
  • Improvement Of Operational ActivitiesN

Continual Service Improvement (CSI)

Chief Author - Vernon Lloyd, FoxIT
Aligning and realigning IT services to changing business needs (because standstill implies decline). The goal of Continual Service Improvement is to align and realign IT Services to changing business needs by identifying and implementing improvements to the IT services that support the Business Processes. 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 to be treated just like any other service practice. There needs to be up front 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.

  • ROI for CSIR
  • SLM for CSIR
  • Asssessment
  • Benchmarking
  • Service Measurement and Reporting

What's in the Update

Process Changes

ITIL Version 2 to Version 3 Process Comparison

Greater Commercialization

"how can I say that ITIL’s success may result in a backlash against ITSM? Because I believe that ITIL is turning its back on the past. This public domain collection of best practices built by dedicated volunteers is now on the fast track to becoming an overly commercialized, complex, bureaucratic and expensive endeavor."

Killing the Goose: The Commercialization of ITIL (Guest Article), by David Mainville, Mon, 2010-03-08 18:21

A review of the ITIL authoring team demonstrates the input of large private sector firmsD. There are five members from Hewlett-Packard, two from Pink Elephant and single representation from Accenture, Guillemont Rock, Connectsphere. The public sector is represented by a member from Carnegie Melon University and the Chief Architect who has roots in governmentR. The shift towards the private sector is deliberate reflecting user concerns on the demonstration of Return on Investment for implementation of ITIL. Sections in Business Strategy and Continual Service Improvement reflect this request.

"By definition, business value terms correspond to marketing terms, providing a means for comparing service competitiveness across alternative providers.

Service Strategy, Section 5.3

Coverage Expansion

"Sure ITIL2 is still in there somewhere but not so as you'd notice."

The scale of ITIL V3, The IT Skeptic, April 29, 2009

"The introduction of ITIL v3 has placed the focus squarely in the stratosphere with the introduction of dozens of new processes, roles and CMDB-like data-stores. Schemes are being designed to “certify” a vendor’s tool compliance to ITIL. What does that even mean--other than a chance to impose additional cost on the vendor?"

Killing the Goose: The Commercialization of ITIL (Guest Article), by David Mainville, Mon, 2010-03-08 18:21

The desire to accommodate the somewhat different foci of both public and private sector organization is only one element in the evolving search for process/procedure exhaustiveness. - continual inclusion of processes, some within the logical domain of business management, has created 27 processes (the number varying depending on whom is quoted and what is cited as a "process").

One cause is the gradual inclusion of sources over the era of v2 dominance. While Service Support and Service Delivery were at the heart of ITIL v2 (and the curriculum for Masters Certification), the creation of The Business Perspective, ICT Infrastructure Management, Security Management, Planning Deliver Service Management (ie. Implementation) and Application Management filled in the missing elements so that ITIL would encompass the entire world of IT operations. The need for to be all-encompassing, to stretch pass the shackles created by a scoping exercise inevitably seem to overwhelm pragmatism and any logic inherent in a simple, well articulated framework.

The service lifecycle is solid framework when restricted to Design - Transition - Operate, but the need to accommodate the v2 add-on processes creates appendages (Service Strategy and Service Improvement) that do conform well to the expressed model, sacrificing its credibility and usefulness as an organizing principle for the 'best practice library'.

Many of the elements in Service Strategy will be found in Business Management publications. They constitute business best practices. Since IT must be run as a business these principles apply to it as well. But, is it necessary to re-create business best practices as ITIL best practices? This has not been done for Project ManagementN.

The ICG indicated that the extensive coverage of Return on Investment (ROI) was prompted by a large number of requests to show how to create a business case for ITIL implementation so that advocates could convince senior management of the need for it. The extensive coverage of financial principles and ROI was intended to meet this demand but, I think misses the mark. The real demand was for hard facts and data on the ROI for ITIL implementation and not an esoteric discussion on how to do ROI. In truth, the majority of financial officers with IT departments have degrees in financial administration and/or accounting and are well-versed in these techniques. I doubt they refer to ITIL for guidance.

Moreover, the need for exhaustiveness in the presentation of material is not consistently followed. If financial management principles are needed, why too are Human Resource principles not presented, or, the aforementioned Project Management principles.

Topic Realignment - The Service Lifecycle Framework

The most obvious change is the format of the library itself. The ITIL v2 library was presented in seven core booksD, with primary attention being given to the first two books — Service Support and Service Delivery. They offered guidance as to how organizations can improve their processes to work smarter, but did not particularly align the processes discussed with larger business requirements.

In contrast, the ITIL v3 has been organized into five new books: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. These books follow a more practical order:

  1. How to develop a business-driven strategy for IT service management
  2. How to design a system to support the chosen strategy
  3. How to transition the newly designed system to the production environment (in terms of people and processes as well as technology)
  4. How to support operations in an ongoing fashion
  5. How to continue improving processes and operationsR.
ITIL Service Lifecycle Model

Definition of Lifecycle
"A method of analysing industries and/or specific organisations based on the premise that all business has a lifespan, moving from birth to eventual demise."R.

"Consecutive and interlinked stages of a product system, from raw material acquisition or generation of natural resources to the final disposal."R

"A series of states connected by allowable transitions. The life cycle represents an approval process for Configuration Items, Problem Reports and Change documents"R

Definition of Business Process
".. a collection of related, structured activities or tasks that produce a specific service or product."R

"A collection of activities that takes one or more kinds of input and creates an output that is of value to the customer."R

".. the execution of a sequence of related steps in response to an event that leads to a clearly defined deliverable or outcome. "R

A review of these two definition should demonstrate that a "lifecycle" is a kind of high level process, that results in iterations of the birth-life-death of a product. The ITIL Service Lifecycle consists of processes. It describes a best practice library of ITSM procedures for use by the people and projects of the organization. It is, in CMMI terms a process asset library that supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across an organization. This set of standard processes is then tailored by projects to create organizationally-specific processes. These may be supplemented by other non-IT organizational process assets (eg. human resources) to support tailoring as well as the implementation of the defined processes.

An ITIL best process may be composed of other processes or process elementsD. Process architecture provides rules for connecting the process elements of a process. The organization's set of standard processes may include multiple process architectures.

In the Version 3 conceptual schema presented above ITIL processes come in two flavours:

In reality, it is difficult to determine the meaning of these boxes and their content. This is because the ITIL descriptions have bypassed the thorny question of detailing the service lifecycle, providing descriptions of various length and treatment within the booklets but with little consistent presentation of the lifecycle's architecture - how the processes inter-connect. Indeed, many of the described processes have elements within two or more of the five respective booklets. Their placement in one book or another seems almost arbitrary (eg. capacity, available and continuity are highly inter-dependent and each has strong elements of design, transition and operation).

The treatment of "Continuous Improvement" as a distinct set of processes (suggesting the processes of Service Reporting and Service Measurement are not operative until CSI activities are initiated) is particularly problematic. Not only are the CSI processes relevant in operations but many of the other four lifecycle processes (ie., strategy, design, transition, operation) have sub-elements (ie., atomic process elements) that are more relevant at defined maturity levels (according to CMMI). ITIL processes as "best practices" assume that other processes (ie. pre-requisites germane to achieving lower maturity levels) exist. In citing Service Reporting and Service Reporting as CSI processes ITIL v3 seems to position CSI at CMMI maturity level 4D - Quantitatively Managed.

Several ITIL v3 process and discussion topics have application throughout lifecycle stages or do not readily fit within the context of the lifecycle:

  • Both Service Strategy and Continual Service Improvement need to be undertaken during the other three lifecycle stages.
  • Return on Investment (ROI) - is a financial technique equally applicable at any lifecycle stage to determine whether an initiative will be viable
  • Knowledge Management is an overarching process, above or unrelated to any service lifecycle stage."Knowledge Management is a whole lifecycle-wide process in that it is relevant to all lifecycle sectors and hence is referenced throughout ITIL from the perspective of each publication. It is dealt with to some degree within other ITIL publications...R"

The depiction on the right presents a more systemic view of the Service Lifecycle. It closely parallels the Organizational Change Management ProcessR; the encapsulating philosophy behind the Service Lifecycle. Service Transition (ie. the "life" element in the lifecycle is at the centre of the framework. Service Design is the Input and Service Operations is the Output. Further, in conformance with ICOMN usage, Service Strategy is the primary Mechanism driving this model. An RfC is the primary mechanism and, often, the trigger, for process initiation. Continual Service Improvement is also a mechanism. Service Strategy contains controls which govern the model. An ICOM rendition of the highest level service lifecycle model might look like the second graph.

This treatment of the top node of the Service Lifecycle places Service Transition as a starting point for decomposing the lifecycle processes. It has advantages:

  • it places the primary concern for an IT organization at the centre of their operations - Changes to the "Known and trusted environment" are one of the first things IT organizations must addressN
  • it more correctly contextualizes the two ITIL areas in the presented service lifecycle model that do not easily fit into a process lifecycle framework (hence their placement in the centre and periphery of so many of the ITIL lifecycle model depictions)N.

SOA - Services Lifecycle
SOA and ITIL Convergence: Towards a Business Service Information LibraryR
ICOM Depiction of Service Lifecycle

Information Architecture

ITIL version 2 makes allusions and references to information management of the key ITIL data needsR. Version 3 encapsulates these needs in the Service Knowledge Management System (SKMS) - set of tools and databases that are used to manage knowledge and information. However, while introducing these requirements, ITIL version 3 provides little definition or description for the information holdings, prompting considerable criticism such as the commentaries below.

"So how about it readers? I too doubt that there is even one real SKMS anywhere. To be a SKMS it should:

  • provide full lifecycle management from acquisition to disposal for a 'complete' inventory of CIsR
  • ...where those CIs include business cases, plans, management, organization, knowledge, people, processes, capital, systems, apps, information, infrastructure, facilities, people, service models, acceptance criteria, tangible and intangible assets, software, requirements and agreements, media, spares...R
  • contain the "experience of staff"R
  • contain data about "weather, user numbers and behaviour, organisation's performance figures"R
  • record supplier's and partners' requirements, abilities and expectationsR
  • record user skill levelsR
  • record and relate all RFCs, incidents, problems, known errors and releasesR
  • group, classify and define CIsR
  • uniquely name and label all CIsR
  • relate all these items with multiple types of relationships including compoentn breakdown structure, composition of a service, ownership, dependencies, release packaging, product makeup, supporting documentation...R including "part of", "connected to", "uses" and "installed on"R
  • integrate data from document stores, file stores, CMDB, events and alerts, legacy systems, and enterprise applications, integrated via schema mapping, reconciliation, synchronization, ETL and/or miningR
  • provide tools against this integrated data for query and analysis, reporting, forecasting, modelling and dashboardsR
  • take baselines and snapshots of all this dataR
  • perfrom verification and audit of all this dataR
  • be based on a Service Management information modelR
  • measure the use made of the dataR
  • evaluate usefulness of reports producedR
...and so on and so on.

The IT Skeptic thought ITIL V2 CMDB was a silly idea but not everyone agreed. Surely a larger proportion of readers can see that ITIL V3's SKMS has gone to a new level of absurdity.

The IT Skeptic

The CMDB was challenge enough but now we have to contend with Russian dolls - a CMDB (or more) inside a CMS, inside a SKMS.... really... how much will that cost and anyone out there prepared to propose how I pitch that to a CFO? No not another "trust me"....

Ian Clayton, The IT Skeptic

There is no Enterprise Resource Management system currently covering this spectrum of data. The "gap" is caused by a lack of integration of the data elements, differing responsibilities for them and ill-defined governance over this aspect of IT operations. However, according to Charles Betz, the big vendors are making strides in rectifying this situation.

"It's clear that the Big Four (IBM, CA, HP, BMC) are all moving aggressively in this direction with their product suites and marketing. Components such as change, incident, availability, project, vendor, contract, and skills management of course have been available for years. The next stage is to integrate them, which is why HP bought Mercury, IBM bought MRO, BMC bought Remedy, CA bought Niku... do you think that these companies are just sitting on these acquisitions? Hardly. All are engaged in a feverish race to integrate these acquisitions into coherent suites for IT, and this integration is no different than what we saw when financial systems (payables, receivables, general ledger, etc) were integrated into comprehensive ERP suites. Who would buy a GL separate from their receivables system nowadays? Yet this was how it was twenty years ago..."

Charles T Betz, The IT Skeptic

The SKMS is, of course, a best practices abstraction, an abstraction because the most basic definition of of "best practices" implies their collection and emulation from the best operations willing to provide inputR (ie., real life examples) and not theoretical presentations for which there may be no current operating instance nor any practical means of achieving itN. But, this questions the entire concept of ITIL as a collection of "best practices"...

"I don't have any issue with ITIL being progressive or 'ahead of market'. That way it can be a good reference point for organizations wanting to improve ITSM practices. However, that intent takes ITIL away from the basic definition - of being a documented 'best practice' (or the new practice of usage goes - 'Good practice') for ITSM. From the source, "ITIL is a public framework that describes Best Practice in IT service management". From the overall look and feel, with every version, ITIL is moving from that basic definition/objective to be an IT Service Management Body of Knowledge (BOK)- This usage can be seen in multiple places in the current ITIL publications. If that is an accepted intent, then concepts like SKMS are valid. But, in the same publication, it is also said that ITIL is a 'source of good practice'.

The web definition of best practice goes: "A best practice is a technique or methodology that, through experience and research, has been proven to reliably lead to a desired result". Watch the word "Experience" here. Wikepedia also says: Best practices can also be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people.... The definitions of 'Body of Knowledge' goes: "Collection of all the available knowledge on a topic, or all the published material on a subject. I feel it is critical, at least now, that ITIL be very clear on what it is : "Collection of best (good) practices" or "ITSM Body of Knowledge"

In reality, ITIL v3's allusions to the SKMS or the CMS or, for that matter, any of the mentioned information systems is conceptually immature and requires a lot of work. Note the depiction offered in Service Transition - Asset and Configuration ManagementE and contrast this with the Knowledge Management depictionE. The "Integrated CMDB" is replaced by the "SKMS" but the description of the SKMS is far more than the Integrated CMDB. Clearly, a lot of work remains undone in presenting ITSM best practices data management.

Common Approach Divergence

While the majority of discussion on ITIL identifies Service Strategy processes as those cited above, the Service Strategy book doesn't even identify them as processes as is done in the other four areas. Instead, it refers to "Service Economics". And, there is no adherence to the standard format for treatment of processes evident in the other four books (ie. list Input, Outputs, CSF, Interfaces, KPIs, etc). Indeed, in the OGC v3 project preparatory paper, the design-transition-operation stages are uniquely identified as "the lifecycle title" while Strategy and Improvement were referred to Strategy & Improvement titlesR. This suggests that Service Strategy was written first and the format developed later without returning to it for extensive editing to achieve conformity. Of course, the books were each written by a different author with differing perspectivesN but I think it would have been desirable to have these "processes" treated in the same manner as throughout the rest of the material.

This shortcoming has been acknowledged by OGC. In their September, 2009 update on the release of a new version 3 edition, section 5.1 they define the scope of the undertaking to include:

Restructure the guidance to ensure that all five publications are organized in the same way:
  • Ensure that each process has goals, purpose and objectives
  • Look at how the processes are dealt with, and ensure a common treatment for all.

OGC Mandate for Change, Project requirements for an update to the ITIL® core publications © The Stationery Office 2009, September 2009, p 3.

Out of Scope for the re-write are, quite expectedly, anything that would "invalidate the current use of ITIL, whether by organizations which have adopted its use or by individuals who have taken an ITIL qualification and are currently using the method in their workplaceN.

Concepts Needing Further Articulation

Expanding the Supply Chain Heuristic

Within the Capacity Management Chapters of ITIL resides the distinction between Component, Service and Business considerationsR. These reflect elements of Supply Chain Management ('The management of a network of interconnected businesses involved in the ultimate provision of product and service packages required by end customers.R') - Strategic, Tactical and Operational.

Supply chain management is a cross-function approach including managing the movement of raw materials into an organization, certain aspects of the internal processing of materials into finished goods, and the movement of finished goods out of the organization and toward the end-consumer. As organizations strive to focus on core competencies and becoming more flexible, they reduce their ownership of raw materials sources and distribution channels. These functions are increasingly being outsourced to other entities that can perform the activities better or more cost effectively. The effect is to increase the number of organizations involved in satisfying customer demand, while reducing management control of daily logistics operations. Less control and more supply chain partners led to the creation of supply chain management concepts. The purpose of supply chain management is to improve trust and collaboration among supply chain partners, thus improving inventory visibility and the velocity of inventory movement.

Wiki - Supply Chain Management

Included in ITIL v3 /
Excluded /
ITIL ProcessFocus
ITIL v3 Service Strategy
Service Portfolio ManagementR   IT Service Management
Integration of business processes: IT frequently employs bottom-up integration, stitching together a patchwork of technology and application components.
Business Service Management
A holistic top-down approach aimed at aligning the IT infrastructure with the business. Business Service Management is the ongoing practice of governing, monitoring and reporting on IT and the business service it impactsD.
Demand ManagementD  Use of differential charging to encourage customers to use IT services at less busy times. Analysis of patterns of business activity and user profiles. Business processes are the primary source of demand for services. Patterns of Business Activity (PBA) influence the demand patterns seen by the service providers.
IT Financial ManagementD   Provisioning Value targets the underlying cost to IT related to provisioning a service, including all fulfillment elementsD, both tangible and intangible.

Service Recording assigns cost entries to the appropriate service.

The cost of service outage measures the financial value placed of a service, and is meant to reflect the value of lost productivity and revenue over a specific period of time.

Operating and Capital Planning Processes
Common and fairly standardized, and involve the translation of IT expenditures into corporate financial systems as part of the corporate planning cycle.

Compliance practices demonstrate that proper and consistent accounting methods and/or practices are being used.

Other Elements IT Operational Planning - Translation of Tactical Plans into operational plans, setting clear and concrete expectations for component performance. Sub-activities should include:
  • Architecture ServicesR - Ensuring appropriate systems are defined to optimize the use of the architectural model.
  • Project Management - Identifying and prioritizing component-based projects in line with the operational plan.
Architecture ServicesR - ensuring appropriate services are designed in conformance with the architectural framework.

IT Service Tactical Planning - Translation of Strategic Plans into tactical plans, setting clear and concrete short-term goals for the service. These should cover:

  • Service Improvement Plan - A formal Plan to implement improvements to an IT Service.
IT GovernanceD - A subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The primary goals for information technology governance are:
  1. assure that the investments in IT generate business value,
  2. mitigate the risks that are associated with IT.

This can be done by implementing an organizational structure with well-defined roles for the responsibility of information, business processes, applications, infrastructure, etcR.

Business/IT Alignment is a desired state in which a business organization is able to use information technology (IT) effectively to achieve business objectives - typically improved financial performance or marketplace competitiveness.

IT Strategic PlanningR - undertaken at regular intervals giving rise to long-term plans; the long term plans should periodically be translated into operational plans setting clear and concrete short-term goals. These should cover:

  • Communications - Policies and standardsD established and communicated to the Client organizations.

  • HR Management - Sound, fair and transparent personnel management practices to recruit, hire, vet, compensate, train, appraise, promote and dismissR.
  • Quality Management - Implementing and maintaining quality management standards and systems by providing for distinct development phases, clear deliverables and explicit responsibilities. R.
  • Project Management Framework - establish and periodically review a general project management framework which defines the scope and boundaries of managing projects, as well as the project management methodology to be adopted and applied to each project undertakenD.
ITIL v3 Service Design
Service Catalogue ManagementDTechnical Service Catalogue
Details of all the CIs necessary to support the provision of the services: involves interfacing with support teams, suppliers and Configuration Management on interfaces and dependencies between IT services and the supporting services, components and CIs.
Business Service Catalogue
Details of all the IT services delivered to the customer.
Business Service Catalogue
The relationships to the Business UnitsR and the business process that rely on the IT services.
Service Level ManagementD   Service Level Agreements (SLAs)
Monitoring of the performance of service or groups of service to one or more customer bases.

Underpinning Agreements (UAs)N
Achievement of SLA targets - formal arrangements with internal and external groups forming part of a service chain. UAs focus on the operational requirements that the services need to meet during the service chain and may be represented by specific components of the infrastructureN.

ITIL v3 Service Lifecycle: Demand Management manages the expectation and perception of the business, customers and users and ensure that the quality of service delivered by the service provider is matched to those expectations and needsN.
Capacity ManagementD Component Capacity Management
Management, control and prediction of the performance, utilization and capacity of individual IT technology components.
Service Capacity Management
Management, control and prediction of the end-to-end performance and capacity of the live, operational IT services usage and workloads.

Short-Term Demand Management may occur when there has been a partial failure of a critical resource in the IT infrastructureR.

Business Capacity Management
Translates business needs and plans into requirements for service and IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned and implemented in a timely fashion.
Availability ManagementComponent Availability
All aspects of component availability and unavailability: monitoring, measuring, analyzing and reporting on component availabilities using such measures as MTTR, MTRS, MTBSI, MTBF
Service Availability
All aspects of service availability and unavailability and the impact of component Availability, or the potential impact of component unavailability on service availability.
Overlap - covered by the Business Continuity Plan and/or the Disaster Recovery Plan within the IT Service Continuity Management process.
IT Service Continuity Management Business Impact Analysis (BIA)
Quantification of the impact to the business that loss of service would have.

Risk Analysis
Determination of the likelihood that a serious service disruption will actually occur. This is an assessment of the level of threat and the extent to which an organization is vulnerable to that threat.

IT Service Continuity Plan
Information needed to recover the IT systems, networks and telecommunications in a disaster situation once a decision to invoke has been made, and then to manage the business return to normal operation once the service disruption has been resolved.

Risk Analysis
Determination of the likelihood that a disaster will actually occur. This is an assessment of the level of threat and the extent to which an organization is vulnerable to that threat.

Business Continuity Plan
Documentation describing the roles, responsibilities and actions necessary to resume business processes following a business disruption.

Information Security ManagementN Component Security Monitoring
Part of many components and systems that needs to be continuously managed.
Service Security Monitoring
Part of many services that needs to be continuously managed.

ITIL v3 Service Lifecycle: Access Management is the Operational process associated with monitoring the security of a service.

Business Security Policy and Plans
Specific security policies that address each aspect of strategy, control and regulation.

A comprehensive security strategy, closely linked to the business objectives, strategies and plans.

Supplier ManagementN - processes and procedures for establishing new suppliers and contracts. Operational Supplier Management
For suppliers of operational products or servicesR.

Commodity Supplier Management
For suppliers that provide low-value and/or readily available products and services, which could be alternatively sourced relatively easily (e.g. paper or printer cartridge suppliers).

Tactical Supplier Management
For relationships involving significant commercial activity and business interactionR.
Strategic Supplier Management
For significant 'partnering' relationships that involve senior managers sharing confidential strategic information to facilitate long-term plansR.

ITIL v3 Service Transition
Service Asset and Configuration ManagementR Configuration Management
Maintaining the status and integrity of components and systems
Service Asset Management
Maintaining the status and integrity of logical CIs.
Validation and TestingRTest Strategy
Defines the overall approach to organizing testing and allocating testing resourcesR.

Test Models
What is to be tested and the test scripts that define how each element will be tested.

Many different types of tests might be used to verify that the service meets the user and customer needs as well as the service provider's requirements for managing, operating and supporting the service.

Component and Assembly TestDR.
Depend on the type of service and channel of delivery. Functional testing is covered in many testing standards and best practices.
Service TestingDR
Includes many non-functional tests. These tests can be conducted at several test levels to help build up confidence in the service release:
  • Service Test and EvaluationR
  • Service TestR
  • Service Operational Readiness TestR
  • Service Release TestR
Release and Deployment ManagementR Release Unit
The portion of a service or IT infrastructure that is normally released together according to a Release PolicyR.

Release and Deployment Models
Standard models that detail the approach, mechanisms, processes, procedures and resources required to build and deploy releases on time and within budgetR.

Component Identification
Deciding the best way to break down a major deployment into components and determining the appropriate deployment approach for eachR.
Change ManagementRComponent Change Management
Changes affecting baselined components and systemsR
Service Change Management
Changes affecting baselined logical CIsR.
Organizational Change ManagementR
Improve the organization by altering how work is done by impacting one or more of the following organizational operations:
  • Processes
  • Systems
  • Organization structure
  • Job roles

Knowledge ManagementR Knowledge Transfer
Knowledge needs to be transferred to other parts of the organization at specific points in the lifecycle.

Establishing Data and Information Requirements
Designing data and information items content and form

Defining an Information Architecture
Architecture matched to the organizational situation and the knowledge requirementsR

KM StrategyD
  • Governance
  • Organizational changes underway and planned
  • Roles and responsibilities
  • Funding
  • Policies, processes, procedures
  • Methods for Knowledge Management
  • Technology and other resource requirements
  • Performance measures.
ITIL v3 Service Operation
Event ManagementR Event Notification
Most CIs are designed to communicate certain information about themselves by pollingD or by a programming hook inserted into an application.

Event Detection
Detected by an agent running on the same system, or transmitted directly to a management tool specifically designed to read and interpret the meaning of the event.

Event Filtering
Determine which Events trigger actions.

Event Significance
Assign Actions to EventsD

Event Correlation
What actions need to be taken to deal with the Event.

Conceptually the Invocation of an IT Service Continuity Plan might reference an Event that triggers a Service-wide response.  
Incident ManagementR Standard Incidents
  • Identification - user(s) impacted and Service Desk contacted
  • Logging - incidents fully logged and date/time stamped
  • Categorization - allocate suitable incident categorization coding
  • Proritization - agree and allocate an appropriate prioritization codeR
  • Initial Diagnosis - try to discover the full symptoms of the incident and to determine exactly what has gone wrong and how to correct it asapR
  • Escalation - When unresolved then pass incident to correct people (Tier II) to resolve
  • Investigation and Diagnosis - support groups involved with the incident handling will investigate and diagnose what has gone wrong
  • Resolution and Recovery - test and apply measures that restore service to normal operating characteristics
  • Closure - Verify that users are satisfied and agree to the cessation of recovery actions

Major Incident
A separate procedure, with shorter timescales and greater urgencyR. The Major Incident procedure should include the dynamic establishment of a separate major incident team under the direct leadership of the Incident Manager, formulated to concentrate on this incident alone to ensure that adequate resources and focus are provided to finding a swift resolution.

Service Incident
Not covered but conceptually would be included in Service Level Management by a Customer Service Representative.

IT Service Continuity Management
Service-wide outages invoke a distinct set of procedures covered by IT Service Continuity Management (ITSCM)

IT Service Continuity Management
Business-wide outages invoke a distinct set of procedures covered by a Business Continuity Plan (BCP).
Problem ManagementR Standard Problem
  • Detection - suspicion or detection of an unknown cause of one or more incidents
  • Logging - recording of relevant details
  • Categorization - Using Incident categories
  • Proritization - same way and for the same reasons as incidentsR
  • Diagnosis - diagnose the root cause of the problemR
  • Workaround - implementation of a temporary method to restore service, perhaps with lower functionality.
  • Known Error Recording - maintain history of treatment for subsequent investigations
  • Resolution - test and apply resolutionR
  • Closure - When any change has been completed and reviewed the Problem Record should be formally closed.

Major Problem
After every major problem (as determined by the organization's priority system), while memories are still fresh a review should be conducted to learn any lessons for the futureR.

Service Problem
Not covered but conceptually would be included in Service Level Management by a Customer Service Representative.

IT Service Continuity Management
Service-wide outages invoke a distinct set of procedures covered by IT Service Continuity Management (ITSCM). Diagnosis and recovery procedures may well involve the direct assistance of the hardware or software vendor to implement a workaround and resolve the root cause of the service failure.

IT Service Continuity Management
Business-wide problems invoke a distinct set of procedures covered by a Business Continuity Plan (BCP).
Request FulfillmentR Standard Request
  • Service Selection - Selection of a service from a defined list (eg. Service Catalogue).

  • Approval - an estimate of the cost must be produced and submitted to the user/manager for financial approval. In some cases further approval may be neededR
  • Fulfillment - Simple requests may be completed by the Service Desk while others will have to be forwarded to specialist groups and/or suppliers for fulfillment.
  • Closure - Following check that the user is satisfied with the outcome.
Service Improvement Plan (SIP)
Underlying difficulty identified which is adversely impacting upon service quality. Service Level Management must, in conjunction with CSIN and Availability Management, instigate a SIP to identify and implement whatever actions are necessary to overcome the difficulties and restore service quality.R
Business Improvement Plan (BIP)
A systematic approach to help an organization optimize its underlying processes to achieve more efficient results. BIP attempts to reduce variation and/or waste in processes, so that the desired outcome can be achieved with better utilization of resourcesR.
Access ManagementR Standard Component Access Request
Request for access to a system or componentR.

Standard Service Access Request
Request for access to a serviceR.

Providing Rights
Access Management executes the policies and regulations defined during Service Strategy and Service Design.
Verify that the user requesting access is who they say they are and they have a legitimate requirement for that service.

Identity Change Control
Changing access rights on the basis of employment changeD.

Logging And Tracking Access
Validation of the rights provided according to defined policies. Exceptions should be handled by Incident Management.

Removing Or Restricting Rights
According to defined guidelines a User's rights to access may be revoked.

ITIL v3 Service Improvement
7-Step Improvement
  • Step 1 - Defining What Should be Measured - driven by business requirements.
  • Step 2 - Defining What Can be Measured - limitations on what can actually be measuredR.
  • Step 4 - Processing the Data - process the data into the required formatR
  • Step 5 - Analyzing the Data - Data analysis transforms the information into knowledge of the events that are affecting the organizationR.
  • Step 6 - Presenting and Using the Information - utilizing reports, monitors, action plans, reviews, evaluations and opportunitiesR.
  • Step 7 - Implementing Corrective Action - identify issues, present solutions and explain how the corrective actions to be taken will improve the service.
Step 3 - Gathering the DataR / Component Metrics - these metrics are often associated with component and application based metrics such as performance, availability etc. Step 3 - Gathering the DataR / Process MetricsR - captured in the form of CSFs, KPIs and activity metrics for the service management processes.

Step 3 - Gathering the DataR / Service MetricsR - the results of the end-to-end serviceR.

Service Reporting/MeasurementR Component Measurement
Starting at the bottom, the technology domain areas will be monitoring and reporting on a component basis. This is valuable as each domain area is responsible for ensuring the servers are operating within defined guidelines and objectives. At this level, measurements will be on component availability, reliability and performance. The output of these measurements will feed into the overall end-to-end service measurement as well as the Capacity and Availability PlansR.
Service Measurement
Individual measurements combined to provide a view of the customer's experienceR.

Better Conceptualization of Service Strategy - Governance

ITIL v3 has "tested the waters" associated with IT governance but has not fully immersed itself in the concepts. A proper scoping exercise should be undertaken to assess whether concepts such as ROI, etc. are treated as corporate skills (to be undertaken within a context of financial competencies). Once accepted "the cat is then out of the bag". Foremost amongst items to be expanded upon is IT GovernanceD. IT governance implies a system in which all stakeholders, including the board, internal customers, and in particular departments such as finance, have the necessary input into the decision making process.

No matter if you are implementing CSI around service management or services it is critical that governance is addressed from a strategic view.

ITIL v3 CSI, Section 8.3 Governance

Placing Governance in the CSI book (instead of Service Strategy) positions it in the context of service improvement and not a key element in service strategy.

Integrating CMMI Concepts

Organizational maturity concepts within ITIL v3 are captured in book 5, Continual Service Improvement. This concept separation (versus consideration within the context of each stage of the service lifecycle) has several implications:

ITIL Information Architecture - the SKMS

The ITIL Information Architecture is positioned on the Information Integration layer of the Configuration Management System schema. As mentioned in the previous section the exact relationship between the Configuration Management System (CMS) and the SKMS remains obscure in ITIL v3.

Underpinning this knowledge will be a considerable quantity of data, which will be held in a central logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB). However, clearly the SKMS is a broader concept that covers a much wider base of knowledge.R

Many sections within ITIL v3, particularly those closely paralleling processes, have an Information system identified to support activities, but there is only a brief section on Knowledge Management, if any, elaboration of the kind of information needed to support the activities. Presumably, this is to be left to the software vendors supplying these supporting tools, opening up the field for innovation and vendor differentiation.

This section is will collect the pieces scattered throughout the five ITIL v3 publications and "fill in the gaps" as best as possible when notable omissions are evident.

ITIL v3 Configuration Management System

ITIL ProcessFocus
ITIL v3 Service Strategy
Service Portfolio Management  Requirements Catalogue
Central repository of the users' requirementsR, including Application SizingR. Key data:
  • Requirement ID - this is a unique ID that never changes and is used for traceability
  • Source - the business area or users who requested the requirement or the document where the requirement was raised.
  • Owner - the user who accepts ownership of the requirement.
  • Priority - the level of importance and need for a requirement.
  • Requirement Description - a succinct description of the requirement.
  • Business Process - the type of business activity involvedE
  • Justification - sets out the reasons for requesting the requirement.
  • Related Requirements - Interdependent requirements by their Requirements ID
  • Change History - the entries in this section provide a record of all the changes that have affected the requirementR.

Customer Engagement Plan
main relationships between IT and the business and how these relationships and necessary communication to wider stakeholders will be managed.

Service Portfolio Database
Service packages come with one or more service level packages (SLP). Each SLP provides a definite level of utility or warranty from the perspective of outcomes, assets and the PBA of customers. Each SLP is capable of fulfilling one or more patterns of demand. SLPs are associated with a set of service levels, pricing policies, and a core service package (CSP).

Definitive repository containing official IT documentsR. Foremost amongst this kind of information are the policies and directives underpinning service delivery. Also included would be IT strategies and strategic plans, constraints, financial budgets and plans.
Demand Management  Patterns of Business Activity (PBA) - analyzing and tracking the activity patterns of the business process makes it possible to predict demand for services

User Profiles (UP) are based on roles and responsibilities within organizations for people, and functions and operations for processes and applicationsD. UPs provide information on the roles, responsibilities, interactions, schedules, work environments and social context of related users.

IT Financial Management  Financial Plan - cost estimates for service offeringsR

Service Accounting Costs - the translation of corporate accounting categories to IT service categories for budgetary and cost performance monitoring.

TCO/TCU data on service costs

Operating and Capital Budgets and Spending
IT expenditures maintained in corporate financial systems as part of the corporate planning cycle.
ITIL v3 Service Design
Service Catalogue ManagementR Technical Service Catalogue
Details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the businessD.
Business Service Catalogue
Details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT servicesD.
Definitive Document Library
Definitive repository containing official IT documentsR. Foremost amongst this kind of information are the policies and directives underpinning service delivery.
Service Level Management  Service Portfolio Database - SLPs
Services consist of one or more service level packages (SLP). Each SLP provides a definite level of utility or warranty from the perspective of outcomes, assets and the PBA of customers. Each SLP is capable of fulfilling one or more patterns of demand.

SLA Framework
An SLA structure to ensure that all services and all customers are covered in a manner best suited to the organization's needs.
Capacity Management - CMISR Component Utilization Data
Unlikely to be a single database, and probably exists in several physical locations. Data from all areas of technology, and all components that make up the IT services, can then be combined for analysis and provision of technical and management reportingR.
Service Data
Transaction response times, transaction rates, workload volumes, SLM thresholds, etcN.
Capacity Plan
Future business plansR of the organization need to be considered and the effects on the IT services understood.
Availability Management - AMISR Component Availability Data
Data on component availability and unavailability such as MTTR, MTRS, MTBSI, MTBF, Availability
Service Availability Data
Data on service availability and unavailability and the impact of component Availability, or the potential impact of component unavailability on service availability.

Vital Business Functions (VBFs)
The business critical elements of the business process supported by an IT service.

Availability Plan
Should cover a period of one to two years, with a more detailed view and information for the first six months.
IT Service Continuity Management (ITSCM)  BIA AnalysisR.
The impact of a failure for all Mission and/or Business Critical applications and systems

Risk Analysis
The likelihood that a disaster or other serious service disruption will actually occur to one or more services.

IT Service Continuity Strategy
The results of the BIAs and RAs will enable appropriate Business and IT Service Continuity strategies to be produced in line with the business needsR.

Business Continuity Plan (BCP)
Plans that describe the sequence of actions, and the parties responsible for carrying them out, in response to a series of identified risks, with the objective of restoring normal business operation as soon as possible for Mission and/or Business critical applications and systems.
Information Security Management - ISMSNR   Security Framework
Comprehensive security strategy, linked to business objectives, strategies and plans.
Supplier Management Supplier & Contract DatabaseD
Information relating to suppliers and contracts, as well as all the information relating to the operation of the supporting services provided by suppliersR.
ITIL v3 Service Transition
Service Asset and Configuration ManagementPhysical CMS
Account for, manage and protect the integrity of physical CIs through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made.
Document CMSR
Account for, manage and protect the integrity of documentary CIs through the service lifecycle by ensuring that only authorized material is referenced and followed and only authorized changes are made.
Validation and Testing Test Library
Library of test models, test cases, test scripts and test data that can be re-usedR
Release and Deployment Management Physical CMS
Throughout the deployment process, appropriate records will be created and maintained. As CIs are successfully deployed, the CMS will be updated.R.

Deployment Information
History of the deployment itself, who was involved, timings etc., training records, access rules and levels.

Known Error DatabaseR
Typically a new or changed service will be introduced with identified errors, which while not according to the original Service Design specification are nonetheless minor enough in nature to be acceptable in live operation. These may well be under active investigation and resolution by the service builders, or may be considered acceptable. In either case the errors will be deployed into the live error database as an element of the deployment of the live service. This information will be available through the SKMS to the service desk who will then be able to link incidents reported against these known errorsR.
Change ManagementChange Request Database
Formal communication seeking an alteration to one or more CIsR.
Service Change Management
Formal communication seeking change to a service offering CIsR.
Knowledge ManagementR 
ITIL v3 Service Operation
Event Management Management Information Bases (MIBs) of IT Devices
A database for each device that contains information about that device, including its operating system, BIOS version, configuration of system parameters, etc.R.
Incident ManagementR Incident Management System
    Incident Records
  • Unique reference number
  • Incident classification
  • Date and time of recording and any subsequent activities
  • Name and identity of the person recording and updating the Incident Record
  • Name/organization/contact details of affected user(s)
  • Description of the incident symptoms
  • Details of any actions taken to try to diagnose, resolve or re-create the incident
  • Incident category, impact, urgency and priority
  • Relationship with other incidents, problems, changes or Known Errors
  • Closure details, including time, category, action taken and identity of person closing the record.

    Reference Tables/Material

  • Incident and problem history
  • Incident categories
  • Action taken to resolve incidents
  • Diagnostic scriptsR

This will help it to identify the CIs affected by the incident and also to estimate the impact of the incident.

Known Error Database
Provides valuable information about possible resolutions and workarounds.

See ITSCM aboveSee ITSCM above
Problem Management Known Error Database
Storage of previous knowledge of incidents and problems - and how they were overcome. The Known Error Record should hold exact details of the fault and the symptoms that occurred, together with precise details of any workaround or resolution action that can be taken to restore the service and/or resolve the problemR.
Request Fulfillment Incident Management System
Usually handled by the Incident Management Databasewith Service Requests being handled as a particular type of 'incident'R .
Access Management Human Resource SystemsN
Identify information is filed and the file is associated with a corporate identity, usually an employee or contractor number and an identity that can be used to access corporate resources and information, usually a user identity or 'username' and an associated password.
ITIL v3 Service Improvement
7-Step Improvement Component Metrics
Associated with component and application-based metrics such as performance, availability etc.
Process Metrics
Captured in the form of CSFs, KPIs and activity metrics for the service management processesR.

Service Metrics
The results of the end-to-end serviceR.

Service Reporting & MeasurementR There are typically three distinct audiences for reporting purposes:
  • The business - focus on delivery to time and budget
  • IT management - interested in the tactical and strategic results that support the business
  • IT operational/technical managers - concerned with the tactical and operational metrics which support better planning, coordination and scheduling of resources. The operational managers will be interested in their technology domain measurements such as component availability and performance.
There are typically three distinct audiences for reporting purposes:
  • The business - focus on delivery to time and budget
  • IT management - interested in the tactical and strategic results that support the business
  • IT operational/technical managers - concerned with the tactical and operational metrics which support better planning, coordination and scheduling of resources.

Further Material

Visit my web site