Evolution of service transition
Download as PPTX, PDF4 likes3,887 views
The document discusses the evolution of service transition in IT service management, emphasizing the importance of agility and collaboration through methodologies like Agile and DevOps. Key principles include minimizing negative impacts from changes, the necessity of automation in testing and deployment, and the need for continuous integration. The authors advocate for adapting processes and culture to improve responsiveness and success rates of IT projects.
Evolution of service transition
- 1. David Wheable, Forrester & itSMF USA, @DavidWheable Stuart Rance, Optimal Service Management, @StuartRance Tweeting today? Please follow #ITSMSummit Questions? Submit them via the question box on your screen The Evolution of Service Transition
- 2. David Wheable David 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 Rance Stuart 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 of Service Transition 3
- 4. Activities in Service Transition 4 Transition planningand support Change managementand changeevaluation Releaseand 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. 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 5
- 6. • Faster development cycle • Faster deployment cycle • Faster testing cycle Faster go-to-market The call of the hour is for SPEED 6
- 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 7
- 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 8
- 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 9
- 10. For Agile development: Testing needs to be done continuously, early, and fast! 10 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 11
- 12. Engage In Seven Habits To Achieve Highly Successful DevOps 12 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 13
- 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? 14
- 15. What Testing Are We Doing? 15 “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? 16
- 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? 17 Risk Speed of change Change success
- 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? 18
- 20. David Wheable Principal Consultant dwheable@forrester.com Twitter @DavidWheable | LinkedIn Profile Stuart Rance ITSM Consultant, Trainer, Author StuartR@rances.net Twitter @StuartRance | LinkedIn Profile Thank You 20
Editor's Notes
- #4: Provide the context and background to Service Transition. Introduce key concepts and terminology.
- #5: Set the context on what goes on with Service Transition. This should be positioned at the current ITIL 2011 Edition POVDO NOT discuss this slide in detail, but ensure the audience know this diagram from the book is an example of one possible flow through the ST processes, and that other flows may be appropriate for other types of transition
- #6: The previous diagram is complex and difficult to assimilate – reinforce the key steps
- #8: Key discussion points:Authorisation levels and RACIThe role of standard changes and request fulfilmentCI type and instance distinction – test the type but deploy the instance (+ examples)The need to consider both the physical and virtual aspects
- #10: Note: We talk about Continuous integration in later slideEssential to test backout plans in a really good test environment that is very close to productionFix-forward or back-out.BoS story – CA Scheduler backout without having tested/documented/automated the backout resulted in a major loss of business reputationWaterfall and v-model. How this relates to business analysis and requirements
- #12: These are Stuart Rance definitions, but I find it very helpful to distinguish these things. Some people will describe DevOps as including everything in this slide set, but it is helpful to distinguish the different aspects.Agile is a development methodologyDevOps is an organisational and cultural approach (ABC)DevOps supports Agile very well, but can also be used with Waterfall or any other development methodologyDevOps is often associated with continual deployment (see next slide) but that is technology not org and cultureFull copy of the ops environment available to the development team not just ops staffEarly life support is much more important – call a developer out at 2am – makes it real makes developers code for ops “Build to run”Large organisation where part of their change management process is they rate change requestors on the success of their change requests
- #14: These are technology that support Agile and DevOps – but they are NOT Agile and DevOpsContinual Integration supports Agile – could be used with waterfall too depending on circumstancesContinual Deployment supports DevOpsAudience question: What is the maximum rate at which it is possible to deploy releases?
- #15: Environment must be “change resilient”TDD = Test Driven Design / Development. Developers create the test first, then the code. Both are required for check in.
- #20: The Phoenix Project - Gene Kim, Kevin Behr and George SpaffordAntifragile - Nassim Nicholas TalebThe Lean Startup – Eric RiesKanban – David J AndersonContinuous Delivery - Jez Humble and David Farley