Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

• Part 1 was an overview/introduction.
• Part 2 covered service strategy.
• Part 3 covered service design.

This post continues by looking at the topic of the third stage in the ITIL service lifecycle: service transition.

Service Transition

Service transition is concerned with moving from service design to operation:

• Plan and manage service changes with efficiency.
• Successfully deploy the new or changed services.
• Make sure that the service changes meet the agreed requirements.
• Educate people with the appropriate knowledge and information about services and assets.
• Manage risk.

Benefits include:

• Enable more accurate cost, timing and resource requirements.
• Make it easier for people to adopt and follow.
• Reduce delays due to unexpected clashes and dependencies.
• Improve expectation setting for all stakeholders.
• Ensure that new or changed services will be maintainable.
• Improve control of service assets and configurations.

ITIL defines the following Service Transition processes, which are expanded upon in the rest of this post:

• Transition planning and support.
• Change management.
• Knowledge management.
• Service asset and configuration management (SACM).
• Release and deployment management.
• Change evaluation.
• Service validation and testing.

(the last of these are not discussed in detail for ITIL Foundation level.)

Transition Planning and Support

Focuses on the transition of the service, not the service itself. Co-ordinate resources, plan for them, make sure requirements are met, coordinate activities across service teams.

“To provide overall planning for service transitions and to co-ordinate the resources that they require.”

Terms:

• Release Policy.
  • Service assets with people, each with responsibilities for handover and acceptance of the release:
  • 3 types:
    • Major release – new functionality, maybe removing tactical changes from the past.
    • Minor release – small enhancements, fixes.
    • Emergency release – updates (usually relating to security).
  • Make sure Service Knowledge Management System (SKMS) is up-to-date.
  • Understand Service Acceptance Criteria (SAC).
• SDP Lifecycle
  • All the information including service charter, budgets, timescales, definition and design of releases, making sure everyone has what they need to succeed.

Change Management

Unexpected change is often received negatively – by managing change we can keep people happy.

“To control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption of IT services.”

Change is the addition, modification or removal of anything that could have an effect on the IT services.

One set of study materials I used referred to an Adventures of Ace, DBA comic strip by Steve Karam where multiple changes are causing issues that are hard to track down. It’s a good example of the issues that poor change management can introduce.

Terms:

• Change Advisory Board (CAB):
  • Group of people who assess, advise on and authorise changes.
• Emergency CAB (ECAB):
  • CAB for emergency changes.
• Request for Change (RFC):
  • Formal request for a change to be made.
• Change Model:
  • Approach to managing change, e.g. based on impact:
    • Normal change (follows all the steps of the change process)
    • Emergency change (needs to be implemented right away)
    • Standard change (pre-approved, rarely need additional authorisation); low risk, common procedure (work instruction) – e.g. new employee account, laptop, etc.; password reset; etc.
• Change Record:
  • Details of the change lifecycle (actions taken)
  • For both accepted and rejected changes
  • Change Proposal:
    • Overall view of the change to be introduced. High level description, details of change, business case, implementation schedules, etc.

Remediation planning:

• Ensuring there is roll-back plan to go to the previous milestone in the change.
• Not all changes are reversible so there may be another plan to move around problems.

The Change Manager is the person who administers RFCs, prepares RFCs for CAB/ECAB; authorises/rejects changes based on CAB advice.

Knowledge Management

Does everyone know what’s going on?

“To share perspectives, ideas, experience and information; to ensure that these are available to the right place at the right time to enable informed decision; reducing the need to rediscover knowledge.”

Goals:

• User, service desk, support staff and supplier understanding of the new or changed service.
• Awareness of the use of the service and the discontinuation of previous versions.
• Establishment of the acceptable risk and confidence levels associated with the transition.

Terms:

• Data, Information, Knowledge and Wisdom (DIKW) Chart:
  • Data is just the facts (e.g. logs from monitoring tools).
  • Provide context to become information (e.g. in documents, email) – need to manage to find and reuse (e.g. to deliver service). Who, what, when, where?
  • Knowledge is based on past experience, ideas, values, etc. – dynamic and context-based for decision-making. How?
  • Wisdom can be thought of as “applied knowledge” – create value through correct and well-informed decisions. Why?
• Service Knowledge Management System (SKMS):
  • Contains information needed to manage services
  • Includes Configuration Management System (CMS), which itself contains the Known Error Database (KEDB) and Configuration Management Database (CMDB)
  • Also includes:
    • Staff – experience/skills.
    • Suppliers – abilities.
    • Users – education.

Service Asset and Configuration Management

“To ensure that the assets required to deliver services are properly controlled and that accurate and reliable information about those asses is available when and where it is needed.”

Ensuring all configuration items are configured appropriately and that relationships are known.

Terms:

• Service Asset:
  • Any resource or capability of a service provider.
• Configuration Item (CI):
  • Any component or service asset that needs to be managed to deliver a service (with associated scope).
• Attribute:
  • Information about the asset: serial number, capabilities, location, etc.
• CI Type:
  • Ways to classify configuration items (hardware, software, personnel, etc.)
• Component:
  • Smaller piece of a larger environment
• Configuration Baseline:
  • Configuration that has been set and agreed upon in change management.
  • Starting point for changes, or target to roll back to in remediation.
• CMDB and CMS:
  • Store information about Service Assets
• Relationship:
  • Connection between CIs – e.g. an application relationship to a server.
  • Between CIs in scope and out of scope (e.g. between PSTN and PBX)
• Verification and Audit:
  • Making sure information is up to date and accurate.
  • Formalised check.

SACM activities – not a cycle – these are interconnected:

• Planning:
  • Define objectives, processes, procedures, scope, naming conventions, types, etc.
• Identification:
  • Inventory of what/where systems exist.
  • Creation of baselines.
  • Control:
    • Information placed in CMDB and modifications are controlled/authorised.
    • Change Management will help with this.
  • Status Accounting:
    • Reporting (during and after transition).
  • Verification and Audit:
    • Constantly ensuring items are recorded, up-to-date and have no unapproved changes.

Release and Deployment Management

What is coming when?

“To plan, schedule and control the build, test and deployment of releases. To deliver new functionality required by the business while protecting the integrity of existing services.”

Includes all of the processes, systems, functions to help package, build test and deploy release into service operation (live use). Works hand-in-hand with service validation and testing (see below).

One set of study materials uses an analogy of a film release: which is created, written, filmed – then released. Planning – which cinemas, what date, when is the red carpet premier, etc. – are all part of release and deployment management.

Terms:

• Deployment:
  • AKA Rollout
  • Activity responsible for movement of new or changed hardware/software/documentation to the live environment
• Release:
  • Change to IT service that has been built tested and deployed together.
• Release Package:
  • A set of configuration items that will be built, tested and deployed together as a single release.
  • Get from current baseline to target baseline
• Release Record:
  • The record that defines the content of the release.
  • Relationship with all configuration items affected by the release
• Release Unit:
  • The components of the service that are released together. e.g. hardware, software and associated end-user documentation.
• Build:
  • Number to refer to the configuration items that create the IT service being deployed.
  • May be a date/number.
• Definitive Media Library (DML):
  • One or more locations where authorised versions of software are placed (may include licenses, documentation, etc.)
• Release Policy:
  • Formal documentation that defines the strategy for releases (from service design).
  • Governing policy document for release and deployment.
  • What constitutes major or minor releases, deliverables, remediation policy for rollback, how/where releases are documented, etc.?

Overview:

• Service design has release policy.
• Start putting together release packages.
• Service validation and testing to make sure release packages look OK (e.g. soft release).
• Release.
• Remediate if necessary.

Deployment options:

• Parallel (big bang).
• Phased.

Four phases:

1. Release and Deployment Planning.
2. Release Build and Test:
   • To DML.
3. Deployment:
   • With change management authorisation.
4. Review and close:
   • Experience, feedback, lessons learned, etc.

Change Evaluation

(Not covered in ITIL Foundation.)

Once changes have been deployed, how are they working out? Goes hand-in-hand with Change Management.

Service Validation and Testing

(Not covered in ITIL Foundation.)

Make sure all is working. Goes hand-in-hand with Release and Deployment Management

Wrap-up

The next post in this series will follow soon, looking at service operation.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.