ITIL SERVICE LIFECYCLE

1. ITIL SERVICE LIFECYCLE SERVICE TRANSITION

2. ITIL LIFECYCLE – STAGES – SERVICE TRANSITION Service Transition(ST)is development and improvement of capabilities for transitioning new and changed services into operations. ST will ensure that the design will deliver the intended strategy and that it can be operated and maintained effectively. ST is concerned with managing change, risk & quality assurance and has an objective to implement service designs so that service operations can manage the services and infrastructure in a controlled manner.

3. ITIL LIFECYCLE – STAGES – SERVICE TRANSITION • Concepts • V Model • Configuration Item • Configuration Management System • Knowledge Management • Data-Information-Knowledge-isdom • Service Knowledge Management System • Definitive Media Library

4. ITIL LIFECYCLE – STAGES – SERVICE TRANSITION • Processes • Transition Planning and Support • Change Management • Service Asset and Configuration Management • Release and Deployment Management • Service validation and Testing • Change Evaluation • Knowledge Management

5. Service Transition V Model

6. Key Terms • Change : The addition, modification or removal of anything that could have an effect on IT Service; scope should include all IT services, Configuration Items, Processes, documentation, etc • Configuration Item (CI) : Any component that needs to be managed in order to deliver an IT service • Build : The activity of assembling a number of Configuration Items to create part of an IT service. It may also refer to a Release • Configuration Management DataBase (CMDB): ConfigurationManagement identifies the various components of IT infrastructure as Configuration Items (CIs). All the information regarding CIs are help within the Configuration Management Database (CMDB) • Configuration Management System (CMS) : A set of tools and databases that are used to manage an It Service Provider’s configuration data • Definitive Media Library (DML) : One or more locations in which the definite and approved versions of all software Configuration Items are securely stored

7. Key Terms • Release : A collection of hardware, software, documentation, process or other components required to implement one or more approved Changes to IT Services • Release Unit : Components of an IT service that are normally released together. • Service Knowledge Management System (SKMS) : A set of tools and databases that are used to manage knowledge and information which includes the Configuration Management System. • Transition : A change in state, corresponding to a movement of an IT service or other Configuration Item from one Lifecycle status to the next. • Validation : An activity that ensures a new or changed IT service, process, plan or other deliverable meets the needs of the business.

8. Configuration Item (CI) • Anything that needs to be managed in order to deliver an IT Service • CI information is recorded in the Configuration Management System • CI information is maintained throughout its Lifecycle by Configuration Management • ALL CIs are controlled by Change Management • CIs typically include • IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs

9. Configuration Management System (CMS) • Information about all Configuration Items • CI may be entire service, or any component • Stored in 1 or more databases (CMDBs) • CMS stores attributes • Any information about the CI that might be needed • CMS stores relationships • Between CIs • With incident, problem, change records etc. • CMS has multiple layers • Data sources and tools, information integration, knowledge processing, presentation

10. Configuration Management System

11. ITIL SERVICE LIFECYCLE SERVICE TRANSITION – TRANSITION PLANNING AND SUPPORT

12. Purpose/Goal/Objective The purpose of the Transition Planning and Support activities is to: • Plan appropriate capacity and resources to package a release, build, release, test, deploy and establish the new or changed service into production • Provide support for the Service Transition teams and people • Plan the changes required in a manner that ensures the integrity of all identified customer assets, service assets and configurations can be maintained as they evolve through Service Transition • Ensure that Service Transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers • Coordinate activities across projects, suppliers and service teams where required.

13. Purpose/Goal/Objective The goals of Transition Planning and Support are to: • Plan and coordinate the resources to ensure that the requirements of Service Strategy encoded in Service Design are effectively realized in Service Operations • Identify, manage and control the risks of failure and disruption across transition activities. The objective of Transition Planning and Support is to: • Plan and coordinate the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates • Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities • Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.

14. Scope • The scope of the Service Transition Planning and Support activities includes: • Incorporating design and operation requirements into the transition plans • Managing and operating Transition Planning and Support activities • Maintaining and integrating Service Transition plans across the customer, service and contract portfolios • Managing Service Transition progress, changes, issues, risks and deviations • Quality review of all Service Transition, release and deployment plans • Managing and operating the transition processes, supporting systems and tools • Communications with customers, users and stakeholders • Monitoring and improving Service Transition performance

15. Policies, principles and basic concepts • Service Design will – in collaboration with customers, external and internal suppliers and other relevant stakeholders – develop the Service Design and document it in a Service Design Package (SDP). • The SDP includes the following information that is required by the Service Transition team: • The applicable service packages (e.g. Core Service Package, Service Level Package) • The service specifications • The service models • The architectural design required to deliver the new or changed Service including constraints • The definition and design of each release package • The detailed design of how the service components will be assembled and integrated into a release package • Release and deployment plans • The Service Acceptance Criteria.

16. ITIL SERVICE LIFECYCLE SERVICE TRANSITION – CHANGE MANAGEMENT

17. Purpose/Goals/Objectives The purpose of the Change Management process is to ensure that: • Standardized methods and procedures are used for efficient and prompt handling of all changes • All changes to service assets and configuration items are recorded in the Configuration Management System • Overall business risk is optimized. The goals of Change Management are to: • Respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and re-work • Respond to the business and IT requests for change that will align the services with the business needs. The objective of the Change Management process is: • To ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

18. Scope • Addition, Modification or Removal of • Any Service or Configuration Item or associated documentation • Including • Strategic, Tactical and Operational changes • Excluding • Business strategy and process • Anything documented as out of scope

19. Value to the business • Prioritizing and responding to requests • Implementing changes in required times • Meet agreed service requirements while optimizing costs • Reducing failed changes and rework • Correctly estimating quality, time and cost • Assessing and managing risks • Managing staff time

20. Key Terms • Change : Addition, modification or removal of anything that could have an effect on IT Services • Request for Change (RFC) : A formal proposal for a change to be made. • Change Window : A regular, agreed time when changes may be implemented with minimal impact on services. • Change Advisory Board (CAB) : A group of people that advices the Change Manager in the assessment, prioritization and scheduling of changes.

21. Policies, principles and basic concepts • Change Types • Normal Changes Changes to : • Service Portfolios, Service definitions • Project changes, User accesses, Operational Changes • Standard Changes • Change to a service or infrastructure for which the approach is pre-authorized by Change Management. • Has an accepted and established procedure. • Emergency Changes • Insufficient time for normal handling • Should use normal process as far as possible • Changes that will have a high negative impact on the business

22. Sample of Normal Flow

23. Remember • Change, configuration, release and deployment • Should be planned together • Should have coordinated implementation • Remediation Plans • Every change should have a back-out plan • Sometimes a change can’t be backed out • Must still have a plan for what to do

24. 7 Rs of Change Management • Who RAISED the change? • What is the REASON for the change? • What is the RETURN required from the change? • What are the RISKS involved in the change? • What RESOURCES are required to deliver the change? • Who is RESPONSIBLE for the build, test and implementation of the change? • What is the RELATIONSHIP between this change and other changes?

25. Roles: Change Manager • Usually authorizes minor changes • Coordinates and runs CAB meetings • Produces change schedule • Coordinates change/build/test/implementation • Reviews/Closes Changes

26. Roles: CAB and ECAB • Change Advisory Board (CAB) • Supports the change manager • Consulted on significant changes • Business, users, application/technical support, operations, service desk, capacity, service continuity, third parties… • Emergency CAB (ECAB) • Subset of the standard CAB • Membership depends on the specific change

27. ITIL SERVICE LIFECYCLE SERVICE TRANSITION – SERVICE ASSETS AND CONFIGURATION MANAGEMENT

28. Purpose/Goals/Objectives The purpose are to: • Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships • Account for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made • Protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle • Ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System.

29. Purpose/Goals/Objectives The goals are to: • Support the business and customer’s control objectives and requirements • Support efficient and effective Service Management processes by providing accurate configuration information to enable people to make decisions at the right time, e.g. to authorize change and releases, resolve incidents and problems faster. • Minimize the number of quality and compliance issues caused by improper configuration of services and assets • Optimize the service assets, IT configurations, capabilities and resources. The objective of is: • To define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.

30. Scope • Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control. • It includes: • Full lifecycle management of IT and service assets, from the point of acquisition through to disposal • Maintenance of the asset inventory.

31. Scope • Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. It provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and configuration items. SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that are not formally classified as assets. • The scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g. shared assets.

32. Policies, principles and basic concepts • Service Lifecycle CIs • Business case, plan, design package… • Service CIs • Service package, acceptance criteria,… • Service assets • Management, organization, process, knowledge, people, information, applications, infrastructure, financial capital • Organization CIs • Internal and External CIs

33. SACM – Key Concepts • Asset • Any component of a business process • Process (Change Management) • Organization (Experience, Reports) • People, Infomration, Applications, Infrastructure • Financial Capital • Configuration Item • “Any asset being a service component, or other item under control of Configuration Management”

34. SACM – Configuration Management System (CMS) • System used to manage the information under SACM • Details of all the component of IT Infrastructure • Maintain relationships • Configuration Management Database (CMDB) • Automated tools

35. Configuration Management System (CMS) • The CMS is the heart of Service Asset and Configuration Management • The CMS maintains one or more CMDBs, and each CMDB stores attributes of CIs, and relationships with other CIs. • The CMS also maintains several physical libraries, such as the Definite Media Library (DML) for the secure storage of CIs. Although this is a physical library, the CMS logically represent its content.

36. Configuration Management DataBase (CMDB) • Details about CIs are stored in the Configuration Management DataBase (CMDB) from which queries about the IT Infrastructure can be answered • The details of a CI that are mentioned in a CMDB include : • Unique Identifier (service tag) • Attributes (supplier, price) • Status (ordered, testing, production, archived) • History (past incidents, applied changes) • Category (hardware, software) • Relationship (is connected to, is a part of) • The scope of the Configuration Management database is defined by the area of responsibility of the IT organization • The level of detail is defined by the need for information of the IT management processes, the control of the information and the costs and benefits of a CMDB

37. CMDB & CMS • CMDB is a database only, while the CMS also includes tools • CMS maintains one or more CMDBs • CMS is used by all IT Service Management processes • CMS Components • Secure Libraries and Secure Stores • Definitive Media Library (DML) • Configuration baseline • Snapshot

38. Configuration Baseline • A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities and that can be changed only through formal change procedures. • It captures the structure, contents and details of a configuration and represents a set of configuration items that are related to each other. • Establishing a baseline provides the ability to: • Mark a milestone in the development of a service, e.g. Service Design baseline • Build a service component from a defined set of inputs • Change or rebuild a specific version at a later date • Assemble all relevant components in readiness for a change or release • Provide the basis for a configuration audit and back out, e.g. after a change.

39. Snapshot • A snapshot of the current state of a configuration item or an environment, e.g. from a discovery tool. • This snapshot is recorded in the CMS and remains as a fixed historical record. Sometimes this is referred to a footprint. • A snapshot is not necessarily formally reviewed and agreed on – it is just a documentation of a state, which may contain faults and unauthorized CIs. • One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline. • The snapshot: • Enables problem management to analyse evidence about a situation pertaining at the time incidents actually occurred • Facilitates system restore to support security scanning software.

40. Definitive Media Library (DML) • The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. • Master copies of all software assets • In house, external software house, COTS… • Scripts as well as code • Management tools as well as applications • Including licenses • Quality checked • Complete, correct, virus scanned… • The only source for build and distribution

41. Relationship between DML and CMDB

42. Definitive Spares • An area should be set aside for the secure storage of definitive hardware spares. • These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. • Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS. • These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained.

43. SACM – Roles • Service Asset Manager • Configuration Manager • Each of these is the process owner for their area • Implement policy and standards • Procure and manage finances • Agree scope, processes, and procedures • Define and procure tools • Recruit and train staff • Oversee collection and management of data • Manage audits • Provide management reports

44. ITIL SERVICE LIFECYCLE SERVICE TRANSITION – RELEASE AND DEPLOYMENT MANAGEMENT

45. Release and Deployment Management Release & Deployment Management ensures well-planned, cost-effective and properly implemented IT Service. It helps balance the customer’s demand for change and IT stability. Release and Deployment Management, deploys change into the live environment, along with responsibility for quality control during development and implementation. It provides a clear plan that guides release activities with minimal unpredicted impact to live services

46. Purpose/Goals/Objectives • Purpose : • Ensure the structured release and deployment of IT Services • Goal : • Deploy release into production & establish the effective use of the service. • Objective : • Project the line environment through the use of formal procedures.

47. Scope • The scope of Release and Deployment Management includes the processes, systems and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations.

48. Policies, principles and basic concepts • Release • A collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT services. • Release Unit • Components of an IT Service that are normally released together • Release Package / release Design • One or more release units to upgrade from “as-is situation” to “to-be situation”

49. Policies, principles and basic concepts • Release Unit • CIs that are normally released together • Typically includes sufficient components to perform a useful function. For example: • Fully configured desktop PC, payroll application • Considerations include • Ease and amount of change needed to deploy • Resources needed to build, test and deploy • Complexity of interfaces

50. Release and Deployment – Releases Approaches Concepts • Big bang versus phased approach • Phased approach can be by users, locations, functionality… • Push versus Pull deployment • Automated versus manual deployment