ITIL v3 Foundation Certification Notes: Service Transition [2]

[ITIL® v3 Foundation Notes] Other processes of the Service Transition phase for the ITIL® 4 Foundation Certification exam are covered here, including: release and deployment management, knowledge management, service asset and configuration management, transition planning and support. The purpose, objectives, and scope of the processes and their importance in the Service Transition lifecycle stage are addressed.

Transition Planning and Support Process

• a key process for Service Transition
• covers the interface between service transition, project management and business engagement
• needs to work with
  • Technical Management Function: provides resources for managing the infrastructure
  • Application Management Function: provides resources for managing applications
• Purpose: to plan and coordinate the transition activities across different processes at a high level with coordination of resources and capabilities (availability and schedule)
• Objectives
  • plan, coordinate and monitor resources and various parties for the transition and associated activities within the budget and timeframe
  • establish new requirements for management information systems and tools and other management systems
  • ensure repeatable processes (a framework) are adopted during transition of different services
  • identify and manage risks according to organization risk management framework
• Scope
  • plan future transition needs
  • maintenance of policies and standards
  • provide transition guidance and plan for achieving business goals
  • coordinate and prioritize resources for multiple transition needs
  • review and improvement current process and plan for future transition needs
• Not including the detailed plans for building, testing and deployment

Service Asset and Configuration Management Process

• control over the assets under IT management in an efficient and effective manner
• Purpose of SACM: to ensure the control of IT assets for services by having an accurate record of the assets and their relationships and configuration
• Objectives
  • ensure proper management of IT assets through identification, recording (with historic data) and control (verification)
  • manage the integrity of configuration items (CIs) which are controlled by change management
    • an item of infrastructure that is managed to deliver a service
    • all configuration items are service assets, but not vice versa (e.g. knowledge of technician is asset but not configuration item)
  • create a configuration management system
    • holds all information about CIs and their relationship
    • may make use of automatic tools to capture the data
    • four layers: Presentation, knowledge processing, information integration, data
• Scope
  • all configuration items (CIs)
    • identify and apply control to elements of the infrastructure that are to be managed as service assets
    • baseline, maintain and control through change management all CIs with a configuration management system (CMS) in configuration management databases (CMDBs)
  • any interfaces with internal and external configuration items (e.g. shared assets), e.g. license management
• Activities
  • Management and planning
    There is no standard template for determining the optimum approach for SACM. The management team and Configuration Management should decide what level of Configuration Management is required for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a Configuration Management Plan. Often there will be a Configuration Management Plan for a project, service or groups of services, e.g. network services. These plans define the specific Configuration Management activities within the context of the overarching Service Asset and Configuration Management strategy.
  • Configuration identification
    • Define and document criteria for selecting configuration items and the components that compose them
    • Select the configuration items and the components that compose them based on documented criteria
    • Assign unique identifiers to configuration items
    • Specify the relevant attributes of each configuration item
    • Specify when each configuration item is placed under Configuration Management
    • Identify the owner responsible for each configuration item.
  • Configuration control
    Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world. No CI should be added, modified, replaced or removed without an appropriate controlling documentation or procedure being followed.
  • Status accounting and reporting
    Each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or CI in that state. There will typically be a range of states relevant to the individual asset or CIs. A simple example of a lifecycle is: development or draft — approved — withdrawn. The way CIs move from one state to another should be defined, for example, an application release may be registered, accepted, installed or withdrawn.
  • Verification and audit
    The activities include a series of reviews or audits to:
    • Ensure there is conformity between the documented baselines (for example, agreements, interface control documents) and the actual business environment to which they refer
    • Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure
    • Check that release and configuration documentation is present before making a release
• Definition of Terms
  • Service Asset – any resource or capability that could contribute to the delivery of a service
  • Configuration Item – a service asset that needs to be managed in order to deliver an IT service
  • Configuration Record – a set of attributes and relationships about a CI in configuration management databases (CMDBs)
  • Configuration Model – a model of the services, assets, and infrastructure of each configuration item and their relationships to each other for planning and decision use
• One of the most crucial factors is to define the level of detail required to manage configuration items successfully
• Categories of CI suggested by ITIL® include:
  • Service Lifecycle CIs – documents that provide information on the plans and requirements for the services, including costs and benefits
  • Service CIs – service capability and service resource assets; service model, package, etc.
  • Organization CIs – documentation relating to organizational policies or standards
  • Internal CIs – internal assets such as software or hardware
  • External CIs – external customer requirements and agreements
  • Interface CIs – documentation relating to end-to-end service provision across multiple service providers
• Definitive Media Library (DML)
  • consists of a number of software libraries or file storage areas (physical or electronic), which are managed and kept separate from the live, test, or development storage areas
  • stores master copies of versions that have passed quality assurance checks
  • requires policies for retention, security, backup, archive, etc.
• Definitive Spares
  • spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment
• Configuration Baseline
  • the configuration of a service, product or infrastructure that has been formally reviewed and agreed on
• Snapshot
  • the current state of a configuration item or an environment
  • snapshots are recorded in the CMS and remain as fixed historical records

Knowledge Management Process

• control over the assets IT manages in an efficient and effective manner
• Purpose: to ensure timely retrieval of relevant ideas, perspectives, experience, and information to the correct audience for informed decision making (facilitate reuse of knowledge)
• Objectives
  • improve decision making by providing correct and timely information
  • reuse of knowledge for efficiency and effectiveness
  • maintain a service knowledge management system (SMKS) 
    • [definition] SKMS is a set of tools and databases that is used to manage knowledge, information and data. The SKMS includes the configuration management system, as well as other databases and information systems. The SKMS includes tools for collecting, storing, managing, updating, analyzing and presenting all the knowledge, information and data that an IT service provider will need to manage the full lifecycle of IT services.
    • manage the data and information
    • includes sources such as the service portfolio, definitive media library, information in SLAs, OLAs and contracts, budgets, cost models, and service improvement plans, error information, etc.
  • gather, store, analyze and share knowledge
• Scope
  • the management of data and information across the service management processes
  • share of information with customers and users
  • NOT including the detailed collection and maintenance (in Service Asset and Configuration Management)
• Data-Information-Knowledge-Wisdom Structure (DIKW)
  • data – raw facts, e.g. date and time of incidents
  • information – data in context, e.g. average time between incidents
  • knowledge – apply experience (the tacit experiences, ideas, insights, values and judgements of individuals), context, and understanding to the information analysis, e.g. average time between incidents increased by 10% when a new service is introduced
  • wisdom – apply the knowledge with common-sense judgement / contextual awareness for improvement or better results, e.g. the increase in average time between incidents is due to poor documentation

Release and Deployment Management Process

• Purpose: the build, test, and deployment of the release is successfully delivered with minimal adverse impact to business and other services
  • to ensure the process is planned, scheduled and controlled
• Objectives
  • to define and agree on deployment plan with stakeholders
  • create and test release packages
  • maintain the integrity of the release packages (store in definitive media library)
  • ensure the new / changed services meets utility and warranty needs
  • capture lessons learned
  • ensure knowledge transfer to users and IT staff (support and operation)
• Scope
  • the processes, systems, and functions required to deliver a release into production
  • build, ensure testing and deploy the release to the utility and warranty requirements
  • handover of service to operation teams
  • manage all CIs and things related to the release
• Release Policy
  • should be defined for the release of each service / group of service
  • specify the types of releases that need to be controlled e.g. major release, minor release, emergency release
  • outlines the roles and responsibilities, use of definitive media library, customer expectation, acceptance criteria, authorization requirements, criteria for handover, etc.
• Four Phases of Release and Deployment
  • Release and Deployment Planning – begins with planning a release and ends with change authorization to create the release
  • Release Build and Test – the release package is built, tested, and checked into the DML, end with authorization to include the package in DML
  • Deployment – deploy the package from DML and handover of service to operation, early life support might be needed for faster response and knowledge transfer
  • Review and Close – capture lessons learned and address issues
• Big bang versus Phased
  • Big-bang option – the new or changed service is deployed to all user areas in one operation. This will often be used when introducing an Application change and consistency of service across the organization is considered important.
  • Phased approach – the service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled roll out plan. This will be the case in many scenarios such as in Retail Organizations for new services being introduced into the stores environment in manageable phases.
• Push and Pull
  • A push approach is used where the service component is deployed from the centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users – either in big-bang or phased form – constitutes ‘push’, since the new or changed service is delivered into the users environment at a time not of their choosing.
  • A pull approach is used for software releases where the software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing or when a user workstation restarts. The use of ‘pull’ updating a release over the internet has made this concept significantly more pervasive. A good example is virus signature updates, which are typically pulled down to update PCs and Servers when it best suits the customer, however at times of extreme virus risk this may be.
• Automation versus Manual
  • Whether by automation or other means, the mechanisms to release and deploy the service components should be established in the release design phase and tested in the build and test stages of the new or changed service. Automation will help to ensure repeatability and consistency. The time required to provide a well designed and efficient automated mechanism may not always be available or viable. If a manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error prone. Too many manual activities will slow down the release team and create resource/capacity issues that affect the service levels.

Other Processes of the Service Transition

• Service Validation and Testing Process: to ensure the service will perform as specified and be designed through service strategy and service design through testing and validation with customers
• Change Evaluation Process: to check the predicted performance against the actual performance achieved by the new or changed service

Conclusion: ITIL® v3 Foundation Service Transition

This ITIL® 4 Foundation Certification study note discusses a number of management processes for Service Transition: transition planning and support, knowledge management, service asset and configuration management, release and deployment management. The purpose, objectives and scope of the processes are also included. These processes work together to allow the release of services into operational environment in a controlled manner, with minimal disruption to business.

Next, we will touch upon the fourth process of ITIL® — Service Operation in the following study notes.