evolution of service transition hp

8/12/2019 evolution of service transition hp

1/16

The Evolution ofService Transition

Stuart Rance / November, 2013

Twitter: @StuartRance

Email: [email protected]


2/16

Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2

Important Principles of Service Transition

What

Support rate of change needed by thebusiness and minimize any negative impact

How

Changes are packaged into releases

Changes and releases tested before

deployment

Changes reviewed and authorized before

actions are initiated

With what?

CAB and authorization levels

Change and release windows

SACM, definitive media library andbaselines


3/16


Survey

Do you have a CAB?

Do you make changes as fast as your customers want?

Does change ever have a negative impact on your customers business?

Do you have a release management process?


4/16


Activities in Service Transition

Transition

planningand

support

Change

managementand

changeevaluation

Rele

aseand

deployment

management

Service

validation

andtesting

Serviceasset

and

configuration

management

Evaluate,

then

authorize

transition

Plan

transition

Plan

release

Evaluate,

then

authorize

release

planning

Evaluate,

then

authorize

release build

and test

Test components,

release package,

operational, user and

service acceptance

Evaluate,

then

authorize

release

check in

Build and

test release

Check components

in / out

Evaluate and

authorize

release

deployment

Evaluate and

authorize

release

deployment

Evaluate, then

authorize

release

deployment

Deploy

release

Deploy

release

Deploy

release

Review

and close

release

Evaluate,

then

review

and close

change

Review

and close

transition

Check baseline

release in/out

Verify

deployment

Early life

support

Check SDP

in / out

Evaluate,

then

authorize

SDP

check in

Update

CMS


5/16


Key Steps in a Service Transition

Release and deployment

management:Release and deployment planning

Release build and test

Deployment

Review and close

Change authorization at each step

Configuration Management System

updating at each step


6/16


Service Transition for Cloud Services

What does this change?

Deployment of a new solution typically takeshours rather than weeks

Much more use of standard changes and

request fulfilment

Changes to the cloud infrastructure

managed separately to changes to specific

environments

What is the same?

Support rate of change needed by the

business and minimize any negative impact


deployment


7/16


Agile

What is Agile?

A development methodology

Small, frequent releasesminimum

functionality to meet a customer need

Each release typically delivered by a cross-

functional team in a period of 1 to 4 weeks


ST must support frequent small releases

Automated testing integrated into s/w

lifecycle

What is the same?

Support rate of change needed by the

business and minimize any negative impactChanges and releases tested before

deployment


8/16


DevOps

What is DevOps?

Collaboration between dev and ops

Faster deployment, so ops is not a

bottleneck


Operations staff involved earlier in the

lifecycle

Development staff involved later in the

lifecycle

Requires significant ITSM process

automation

Requires significant cultural change

What is the same?Support rate of change needed by the

business and minimize any negative impact


deployment


9/16


Continual Integration and Continual Deployment

What is Continual Integration?

Each new software component isautomatically and immediately tested and

incorporated into a build

What is Continual Deployment?

Each new software component is

automatically and immediately deployed into

production


Release lifecycle must be automated

Test environment near-identical to

production

What is the same?Support rate of change needed by thebusiness and minimize any negative impact


deployment


10/16


How do you do testing in this new world?

Automate end-to-end testing as part of continual integration / deployment

Continually refine and improve the automated testing as you learn about real failures

Test deployment and backout as part of the automated testing

Run game days

Simulate failure modes and rehearse your responses

Design anti-fragile solutions

Expect failure, design solutions that will continue to operate despite these failuresYou cant predict black swan failures so learn to cope with them

Use chaos monkey

Intentionally cause random failures to ensure that your solution really is anti-fragile


11/16


Got the message?

What is the same?

Support rate of change needed by thebusiness and minimize any negative impact


deployment

What is different?

Tools, processes, organisation, culture,

attitudes, agility


12/16


Why bother? Whats in it for you?

IT

Faster time to value for IT projects

Increased success rate for IT projects

More agile IT projects that can adapt to

changing circumstances

Lower risk for IT change

Increased job satisfaction for development

and operational personnel

Increased business satisfaction with IT

Increased availability of operational IT

services

Business

Faster implementation of businesschange

Better responsiveness to changing

business needs

Lower risk for IT enabled business

change

Higher rate of successful implementationfor IT enabled business change

Adoption of agile and devops can lead to enormous benefits for IT and the

business

Risk Speed of

change

Change

success


13/16


What changes should you make to your

processes?There are no quick and easy answers

Make sure you understand the real business need for change (agility and stability)Talk to your counterparts in development and understand their perspective

Simplify your processes, and remove steps that dont add enough value

Integrate processes from requirements through projects and development to operations

Automate everything that you sensibly can, but only where things are simple and well

understood

The biggest changes are not to processes, but to attitudes, behaviour and

culture


14/16


Service Management Core ValuesSee http://smcongress.squarespace.com/
http://smcongress.squarespace.com/http://smcongress.squarespace.com/


15/16


Further Reading


16/16

Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Thank you

[email protected] @StuartRance

evolution of service transition hp

Documents