Evolution of service transition

David Wheable, Forrester & itSMF USA, @DavidWheable

Stuart Rance, Optimal Service Management, @StuartRance

Tweeting today? Please follow #ITSMSummitQuestions? Submit them via the question box on your screen

The Evolution of Service Transition

David WheableDavid is a principal consultant within Forrester's Infrastructure & Operations practice. He provides research-based consulting services to I&O Professionals, helping them leverage Forrester's proprietary research and expertise to meet the ever-changing needs and expectations of their stakeholders. David specializes in helping clients create effective and efficient strategies for their IT Service Management challenges including integrating cloud services, bring your own device (BYOD), and mobility.

Stuart RanceStuart is a strategist, consultant, trainer and author with an international reputation as an expert in IT service management. He has worked with a wide variety of clients in many countries, helping them use service management to create business value for themselves and their customers. Stuart is the author of ITIL Service Transition, 2011 edition and the ITIL Glossary, 2007 edition, as well as many ITSM pocket guides.

2

3

What– Support rate of change needed by the

business and minimize any negative impact

– Your people are your greatest assets

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 and

baselines

Important Principles ofService Transition

4

Activities in Service Transition

Tran

sitio

n pl

anni

ng a

nd

supp

ort

Chan

ge

man

agem

ent a

nd

chan

ge e

valu

ation

Rele

ase

and

depl

oym

ent

man

agem

ent

Serv

ice

valid

ation

an

d te

sting

Serv

ice

asse

t an

d co

nfigu

ratio

n m

anag

emen

t

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 releaseDeploy

releaseDeploy 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

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

Key Steps in Service Transition

6

• Faster development cycle• Faster deployment cycle• Faster testing cycle

Faster go-to-market

The call of the hour is for SPEED

7

What does this change?– Deployment of a new solution

typically takes hours 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

– Changes and releases tested before deployment

Service Transition for Cloud Services

8

Either as a way to improve existing IT processes . . . . . . or as a way to support new internal stakeholders (such as product

development leadership)

“We were jaded with our traditional waterfall approach using fixed contracts. Our business requirements are changing so rapidly, we

needed an approach with far greater feedback loops.”

(SVM professional in the utilities sector)

. . . which is causing increased interest in Agile development

methodologies

9

What is Agile?― A development methodology― Small, frequent releases – minimum functionality to meet a customer need― Each release typically delivered by a cross-functional team in a period of 1 to 4

weeks What does this change?

― Service Transition 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

impact― Changes and releases tested before deployment

Service Transition and Agile

10

For Agile development: Testing needs to be done continuously, early,

and fast!

Integration and integration testing start early on; test data fed continuously, performance testing can’t be done only at the end.

Source: January 15, 2013, “Consistent Performance In Agile Teams Must Include Testing” Forrester report

End-to-end integration

11

What is DevOps?– A movement within IT that is driven

by a need to improve the collaboration between development and operations

What does this change?– Operations staff involved earlier in

the lifecycle– Development staff involved later in

the lifecycle– Requires significant ITSM process

automation What is the same?

– Support rate of change needed by the business and minimize any negative impact

– Changes and releases tested before deployment

DevOps is a True Collaboration of Development and Operations

12

Engage In Seven Habits To Achieve Highly Successful

DevOps

Source: September 2013 “The Seven Habits Of Highly Effective DevOps”

13

What is Continual Integration?– Each new software component is

automatically and immediately tested and incorporated into a build

What is Continual Deployment?– Each new software component is

automatically and immediately deployed into production

What does this change?– Release lifecycle must be automated– Test environment near-identical to

production What is the same?

– Support rate of change needed by the business and minimize any negative impact

– Changes and releases tested before deployment

Continual Integration and Continual Deployment

14

Automate end-to-end testing as part of continual integration / deployment― Continually refine and improve the automated testing as you learn about real

failures (exploratory testing)― 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 failures― You can’t predict “black swan” failures so learn to cope with them

Use Chaos Monkey and other members of the Simian Army― Intentionally cause random failures to ensure that your solution really is anti-

fragile (http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html)

How Do You Do Testing In This New World?

15

What Testing Are We Doing?

“Which of the following testing and release management practices does your development team currently use?”

(Select all that apply)

Unit testing

Exploratory testing

Performance/load testing

Automation/regression testing

Continuous integration with multiple weekly builds

58%

20%

38%

30%

32%

Base: 698 North American, European, and Asian professional software, internal IT, game developers, and consultants; Source: Forrsights Developer Survey, Q1 2013

16

What is the same?– Support rate of change

needed by the business and minimize any negative impact

– Changes and releases tested before deployment

What is different?– Tools, processes,

organisation, culture, attitudes, agility …

Got the message?

17

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 business

change Better responsiveness to changing

business needs Lower risk for IT enabled business

change Higher rate of successful implementation

for IT enabled business change

Why bother? What’s in it for you?

RiskSpeed ofchange

Changesuccess

18

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 don’t 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

What changes should you make to your processes?

19

Further Reading

20

David WheablePrincipal [email protected] @DavidWheable | LinkedIn Profile

Stuart RanceITSM Consultant, Trainer, [email protected] Twitter @StuartRance | LinkedIn Profile

Thank You