PRESENTATION GOALS

1. 2. 3. 4. Discuss and define the areas of improvement in our current service transition methods Suggest methods of refining and closing gaps Identify low-hanging fruit Gain agreement on next steps

TERMS FOR THIS PRESENTATION

Service Transition the processes of transitioning services from Design -> Build -> Run (D->B->R) Design/Engineering (D) Kevin Matsumotos team Build (B) Paul Brettons Team Run (R) Rich Oswalds Team Service(s) Projects, solutions, pods, zones, architecture, or any other design term used for any of the projects coming from Design to Build to Run MTTR Mean Time to Repair/Recovery The average time it takes us to repair/recover from a production outage or issue(1) MTBF Mean Time Between/Before Failure(s)(1)

MAPPING OUR TEAMS TO ITIL

DESIGN TEAMS GOALS

Design for MTBF High Volume Services Highly Resilient Services

BUILD TEAM GOALS

Build new Services from Design Maintain Operational Services Expand existing Services for Business Units Improve stability in Services SMEs to support the Run Team Provide feedback for improvement to Design teams

OPERATIONS TEAM GOALS

Recover from Outages Low MTTR

BUILDING BETTER PROCESSES

Adopting better processes can reduce MTTR, which will reduce the impact of outages to our customers Designing for MTBF assists us with longevity of our solutions Its the Jeep v. Rolls Royce scenario  Jeep very low MTTR  Rolls Royce very low MTBF

THE FOUR MINUTE JEEP

CURRENT SERVICE TRANSITION PROCESS

Design Build Run

Inconsistency, Resource burn & high MTTR

HOW CAN WE IMPROVE TRANSITIONS?

Build to Run  More formalized handoffs?

Design to Build

CURRENT PROCESS
Transitions from D to B and B to O are not currently repeatable process Too much tribal knowledge Structure, language and deployment methods change for each build Handoff of systems is not tracked, scored, or monitored for success/fail or any other metric

WHY IS THIS AN ISSUE?

Systems deployed inconsistently Causes longer MTTR during troubleshooting Greater impact to our customers No accountability of transitions Embarrasses all of us

GAPS IN PROCESS
Transitional processes need to be created for D to B and B to O  Includes design requirements, handoff checklists, handoff plans, formal handoff meeting and acceptance by a manager/director  Exceptions and flaws will need to be remediated by the current owner

SUGGESTED SOLUTIONS
1. 2. 3. Do nothing Identify and build transition teams with skilled staff to manage the transition process Build internal processes and adopt at least at the Communication Services level down

DO NOTHING

Continued Inconsistency & high MTTR

The BUs get fed up?

BUILD A DEDICATED TRANSITION TEAM

Pros  Dedicated staff to manage transitions  Geared specifically towards Cons  New staff expenditures  Increased time to delivery of new designs

BUILD INTERNAL PROCESSES

Pros  Smoother transitions of projects and builds to operations  Lower MTTR for outages  Greater customer satisfaction Cons  Change to our existing methods  Will take several iterations to get it right

CURRENT TEAM RESPONSIBILITIES

Run Design Build

END NOTES
(1) Definitions from several resources. See Resources page for more information

DEFINITIONS & RESOURCES

Definitions
 IEEE Std 610 - Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990  Definitions from IETF RFC1208, RFC1980, RFC4949  The Information Technology Infrastructure Library

Resources
 Origins of MTTR and MTBF Traditional Reliability Carnegie Mellon University  Pecht, M.G., Nash, F.R., Predicting the Reliability of Electronic Equipment, Proceedings of the IEEE, Vol. 82, No. 7, July 1994  Mean Time Between Failure: Explanation and Standards  http://www.kitchensoap.com/ 2010/11/07/mttr-mtbf-formost-types-of-f/