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: Service Strategy Service Design Service Transition Service Operation 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

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. Processes Service Portfolio Management Demand Management IT Financial Management 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. Processes Service Catalogue Management Service Level Management Availability Management Capacity Management IT Service Continuity Management Information Security Management Supplier ManagementR 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. Processes Service Asset and Configuration ManagementR Validation and Testing Release and Deployment Management Change Management Evaluation Knowledge ManagementR Activities 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. Processes Event Management Incident Management Problem Management Request Fulfillment Access Management Activities 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. Processes 7-Step Improvement Service Reporting & Measurement Methods 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

• v3 Service Strategy, Financial Management expands upon v2 concepts to express a shift in the primary target from public to private sector organizations.
• v3 Service Strategy, Demand Management was covered under Capacity Management in ITIL v2. The split in v2 Capacity Management highlights v3 consideration of Demand Management as a strategic, rather than design element.
• v3 Service Strategy, managing services portfolios originates in the ITIL v2 Application Management^R. ITIL v2 only discussed Service Level Management. ITIL v3 represents a fundamental rethinking of services, recognizing the need to conceptualize and identify a portfolio of services before dealing with the specifics of levels of service.
• ITIL v2 Service Level Management has been split into several distinct processes:
  • v3 SLM processes more narrowly pertain to the development and maintenance of relationships with IT lines of business (LOBs). The primary means to conduct this business is through written agreements with the LOB and amongst participants in the service chain including external vendors.
  • v3 Service Catalogue Management elaborates on the need for a dedicated catalogue of IT services, introducing procedures to ensure it is kept current with reliable information. V3 introduces a distinction between a Customer Service Catalogue (services visible to the customer, defined by SLAs) and a Technical Service Catalogue (supporting/shared services, components and CIs necessary for providing services to lines of business).
  • Supplier Management was reflected in management of Underpinning Contracts^R
  • v2 Service Review activities are now included under ITIL v3 Continual Service Improvement.
• v3 Capacity Management has been split into two distinct processes that distinguish between Service Strategy and Service Design foci:
  • Demand Management (Service Strategy) targets management of user/business demand for IT services
  • Capacity Management (Service Design) closely follows its' v2 description
• Availability and IT Service Continuity Management processes in ITIL v3 are identical to ITIL v2.
• v3 treats IT Security Management as part of the Service Design core volume, resulting in a better integration of this process into the Service Lifecycle. The v3 process was updated to account for new security concerns.
• The scope of Change Management is expanded to more explicitly include service changes that affect IT operations^N
• Like Change Management the scope of Configuration Management is broadened to include a wider spectrum of "service assets". Hence, the name change of the process to Service Asset And Configuration Management^N. The Configuration Management Database (CMDB) has been superceded by the Configuration Management System (CMS), a granularity one level below that of the overarching System Knowledge Management System (SKMS).
• v2 Release Management has been split into three distinct processes:
  • v3 Release & Deployment Management provides considerably more details in the areas of Release planning and testing
  • The testing component has been spun off (or duplicated) into a separate v3 process - Service Validation and Testing. This new process closely has its' foundation in the CMMI Validation process^R
  • a "generic" Evaluation process "to provide a consistent and standardized means of determining the performance of a service change in the context of existing and proposed services and IT infrastructure"^R. This new process closely has its' foundation in the CMMI Verification process^R
• v3 collects v2 references to capturing the organization's corporate knowledge into a distinct process (within the Service Transition lifecycle stage). Knowledge Management (KM) was covered by various processes in ITIL v2, most notably in Application Management and “Planning to Implement Service Management”^N.
• v3 Incident Management contains all concepts in v2 but has been re-conceptualized into several distinct processes:
  • v3 distinguishes between Incidents (Service Interruptions) and Service Requests (standard requests from users, e.g. password resets)
  • v3 Event Management was covered under Incident Detection and formed a distinct process in ITIL v2 ICT Infrastructure Management^N.
  • Service Requests are no longer fulfilled by Incident Management; instead there is a new process called Request Fulfillment
  • There is a dedicated process now for dealing with emergencies ("Major Incidents")
• A new sub-process "Major Problem Review" was introduced in v3 to review the solution history of Major Problems in order to determine its’ root-cause and prevent its’ reoccurrence.
• v3 Access Management was covered under ITIL v2 Security Management^N.
• v3 Service Measurement and Reporting were covered in ITIL v2 Service Level Management^R
• v3 7-Step to Service Improvement process is an elaboration of the techniques and processes introduced in ITIL v2 – Planning to Implement Service Management^D.

Greater Commercialization

A review of the ITIL authoring team demonstrates the input of large private sector firms^D. 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 government^R. 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.

Coverage Expansion

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 Management^N.

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

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 operations^R.

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 elements^D. 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:

• self-contained processes (presumably with their unique set of inputs, sub-processes and outputs)
• a conglomerate of activities within a box with common steps

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 4^D - 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 and ITIL Convergence: Towards a Business Service Information LibraryR ICOM Depiction of Service Lifecycle

Information Architecture

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.

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 input^R (ie., real life examples) and not theoretical presentations for which there may be no current operating instance nor any practical means of achieving it^N. But, this questions the entire concept of ITIL as a collection of "best practices"...

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 Management^E and contrast this with the Knowledge Management depiction^E. 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

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:

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 workplace^N.

Concepts Needing Further Articulation

Expanding the Supply Chain Heuristic

Definitions
• Component Focus - management, control and prediction of the performance, utilization and capacity of individual IT technology components.
• Service Focus - management, control and prediction of the end-to-end performance and capacity of the live, operational IT services usage and workloads.
• Business Focus - translates business needs and plans into requirements for IT services and the IT infrastructure.

Legend:

Included in ITIL v3 /

Excluded /

N/A

ITIL Process	Focus
	Component	Service	Business
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: assure that the investments in IT generate business value, 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 ManagementD	Technical 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 Management	Component 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 TestingR	Test 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. Testing 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 ManagementR	Component 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.
	Verification 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

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

• it fails to recognize that lifecycle processes/sub-processes have variants^D depending upon the capabilities of the organization
• there are few organizations any longer creating ITSM processes from scratch. Almost everyone is in improvement mode (eg., everyone creates an AS-IS process flow for comparison with TO-BE as based on ITIL best practices). Thus, the integration of maturity concepts within ITIL best practices would represent a vast improvement.

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

Legend:

CMS /

DDL /

IMS

ITIL Process	Focus
	Component	Service	Business
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).	DDLR 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.	DDL 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 Management	Physical 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 Management	Change 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 CMS 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 above	See 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

• Killing the Goose: The Commercialization of ITIL
• HP Powerpoint Presentation on migration of Version 2 to Version 3
• Forsythe - Key Differences Between ITIL v2 and v3
• Video Presentation on Version 3 Lifecycle Framework, or in segments --> Intro | History | Service Lifecycle | Best Practices, or from ILX web site
• ITIL Version Overview - AcerIT
• ICIO Search Update with Sharon Taylor
• IWiki - ITIL Criticisms