• Like
  • Save

Webinar: Demonstrating Business Value for DevOps & Continuous Delivery

  • 580 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
580
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Demonstrating  Business  Value  for   DevOps  &  Continuous  Delivery   Chandu Singh, OVUM Andrew Phillips, XebiaLabs | 23 April 2014
  • 2. 2 Copyright  2014.   Presenters   ▪ Chandu Singh Senior Analyst, Software – IT Solutions Ovum ▪ Andrew Phillips VP, Product Management XebiaLabs
  • 3. 3 Copyright  2014.   Agenda   ▪ Introduction ▪ Transforming IT Ops for Greater Business Value ▪ The ‘Why’ and ‘What’ of DevOps ▪ Continuous Delivery ▪ The BIG Picture ▪ Goals for DevOps & Continuous Delivery ▪ Measuring Business Value ▪ Q&A
  • 4. 4 Copyright  2014.   Using  GoToWebinar   Questions? Submit via the control panel at any time during the presentation.
  • 5. 5 Transforming IT Operations for greater business value §  Current State of IT Operations is chaotic §  What can we expect in 2014 and 2015? §  IT budgets stay flat §  Process lag among Dev, QA, Ops continues §  Release management remains a challenge §  Reasons? §  IT is always firefighting §  Not enough automation §  Fragmentation of ops
  • 6. 6 Transforming IT Operations for greater business value §  IT Ops requires a structural change §  Traditional view of IT is about keeping the lights on §  Ops teams spend a lot of time firefighting §  The rate of change has quickened, ops teams are spread too thin §  Traditional model of IT and Ops not sufficient §  Agile and lean principles can help streamline operations §  DevOps does just that
  • 7. 7 Why DevOps? – Challenges for the Business §  The changing business context §  Exposure to multiple target platforms – Self hosted, Mobile, Public Cloud §  Accelerated pace of development to cope with growing volumes §  Businesses need a handle on development processes §  IT needs to deliver value sooner, with constant or shrinking budgets §  Need to ensure optimal performance and security of production apps §  Business needs higher throughput from IT §  DevOps brings Agile practices and thinking to operations §  Helps remove slack from the value delivery chain
  • 8. 8 Why DevOps? – Challenges for IT §  The traditional separation between Dev and Ops not working §  Defects caught in production take a long time to fix in development §  Code in dev and production soon goes out of sync §  Diminishing process visibility, need for better KM practices §  High offshore attrition rate, lack of skilled resources §  The rate of handoffs has increased §  Operations can’t cope with the increased workload and ensure production stability simultaneously §  Release automation solutions help make deployments more predictable §  And provide diagnostic , troubleshooting information in case of failures §  Increasingly operators are taking on development responsibilities and vice versa §  A holistic approach to IT is needed, ITSM can serve as the glue between Dev and Ops §  Also close the loop from the end user side by integrating defect tracking with the help desk
  • 9. 9 What is DevOps? §  DevOps is Agile Operations §  DevOps goals §  Better resource provisioning for production §  Better collaboration between different teams §  Better release management §  Less production defects §  More automation §  Shorter release cycles §  Continuous Delivery §  Streamlined process from development to deployment – A pipeline! §  Improved production performance management
  • 10. 10 What is DevOps? §  Dev is agile, operations needs to be agile too! §  Integrated dev and ops §  Invest in §  People §  Processes §  Tools §  Plan for Continuous Delivery §  Reduce test backlog §  Implement test automation earlier in the lifecycle §  Templates & best practice guides §  Increase accountability, reduce handoffs
  • 11. 11 What is DevOps? – People §  Organizational structure §  Cross functional teams §  Organize for micro agility §  Move the ball together §  Reduce handoffs §  Skill development
  • 12. 12 What is DevOps? – Process §  Start early, plan ahead! §  DevOps considerations should be incorporated at the requirements stage itself §  A major chunk of the non functional requirements are indeed operational aspects of the system §  Production monitoring §  Transaction logging, metrics collection §  Security §  Target platform configuration management §  Availability
  • 13. 13 What is DevOps? – Process §  After the requirements and design stage, DevOps is about automation and collaboration §  Automate development activities such as §  Builds §  Tests §  Deployment §  Devs - Collaborate with Ops §  Look at the application end to end §  Post release §  Monitor §  Measure §  Improve through iteration §  Don’t forget – ITSM the glue! We need to close the loop from the end user side.
  • 14. 14 What is DevOps? – Tools §  What can be automated? §  Builds – Build Management, Build Automation §  Tests – Test Management, Test Automation §  Deployments – Environment Provisioning and Deployment Automation §  Release Coordination and Management §  System Configuration and Roll-Out §  Metrics Collection and Monitoring §  Collate Metrics for capacity planning §  Trend and Issue analysis §  Share metrics among teams for better collaboration §  Feedback helps improve performance §  Performance Management §  Organizations already have some pieces of the puzzle!
  • 15. 15 What is DevOps? – Tools (Cloud) §  Why DevOps in the cloud? §  Clouds can be accessed through APIs and are therefore programmable §  Infrastructure elements turn into programmable components and can be automated §  Location transparency allows scaling or node failures to be handled more effectively §  DevOps in the cloud is about automation and repeatable processes §  Automation helps you scale effectively §  Resources can be provisioned on demand §  With DevOps + Cloud your resource requirements go down §  Helps create self-healing systems §  Dynamic Dev, QA, and Production Environments §  Continuous Integration and Continuous Deployment
  • 16. 16 Continuous Delivery §  To automate the deployment of changes, new versions of software to production environments if they pass all quality checks. §  DevOps is an idea, continuous delivery is an implementable process. §  It’s a moving target for most organizations §  Aim for continuous delivery and whatever you hit will be an improvement over the status quo §  Design apps for continuous delivery – manage system state in config files §  Do UAT in production!
  • 17. 17 The BIG picture – DevOps Adoption §  DevOps will not work with the ‘hole in the floor’ approach §  Stakeholder buy-in is essential to DevOps success §  It is easy to get bogged down with definitions and buzzwords §  Understand what DevOps means in the context of your organization §  Understand why it’s required, and the problem that you are trying to solve §  Identify where the process bottlenecks are
  • 18. 18 The BIG picture – The takeaway §  To improve, you need feedback on what went wrong §  To improve faster, you need faster feedback §  Managing enterprise IT in the present context is about constantly improving/shortening the feedback loops §  Agile is for business agility §  Enabling IT to deliver sooner, and exploit opportunities within their value-frame. §  Enable IT to correct course in-flight with shorter feedback loops §  Shorter feedback loops are possible by dividing the work in manageable chunks §  Atomic accountability
  • 19. 19 Some Numbers on Release Mgmt. §  Faulty releases account for 70% of all production failures; 30% is faulty code. §  DevOps and CD help achieve faster time to market by avoiding big bang releases, and with the help of automation. Around 20% time saved. For greater benefits orgs need service virtualization during testing. §  Avoid faulty releases by 70% (see above), more importantly minimize the business impact of a faulty release with automated rollback. Restore service 10-15x faster. §  Release frequently in short increments 80-100% safer releases. NO more code freeze!
  • 20. 20 Case Study – a large global financial services company §  Company A was used to half yearly, big bang releases. Roughly 37-40% of all releases failed on first deployment. Invariably the error would be due to a manual error, such as missing config file entry, wrong path, wrong IP when moving to production from staging and so on, at times the defect would take a few hours time to locate and fix. In a few cases it would be a code error and it would take longer. §  The devs and operations team were scared of releasing code, they ran through lengthy checklists, code reviews, the whole team spent 2-3 days preparing for the release. For a 15 member team it meant wasting around 300 person-hours per release. §  With DevOps & CD (automation) the release prep time has come down to 20 minutes per release. They release more frequently, averaging 3 releases a month, an 18x increase. Faults due to manual error have been eliminated.
  • 21. 22 Copyright  2014.   Goals  for  DevOps  &  Continuous  Delivery   ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises:
  • 22. 23 Copyright  2014.   Goals  for  DevOps  &  Continuous  Delivery   ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises: The Bottom Line
  • 23. 24 Copyright  2014.   Goals  for  DevOps  &  Continuous  Delivery   ▪ DevOps & Continuous Delivery are powerful principles, but they are not organizational goals ▪ We’ve just heard about some measurable goals companies have successfully defined for their DevOps & CD initiatives ▪ Ultimately, there’s only one metric that matters for most enterprises: The Bottom Line −  But it’s surprisingly hard to gain useful information about the impact of a new feature on the bottom line if changes are always Big Bangs −  One important goal of DevOps & Continuous Delivery is thus to enable smaller changes to be made more regularly to allow for better analysis of the effectiveness of changes −  Of course, we need to have the ability to monitor business value generated by our systems in order to make this possible!
  • 24. 25 Copyright  2014.   Goals  for  DevOps  &  Continuous  Delivery   ▪ So “frequency of releases to production” and “number of changes per release” are interesting metrics to track
  • 25. 26 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Other common DevOps & Continuous Delivery goals that we see:
  • 26. 27 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality −  Can be used to measure level of team empowerment and lack of dependency on specialists
  • 27. 28 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality −  Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time −  Measures how quickly a feature or fix can get from idea to customer
  • 28. 29 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality −  Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time −  Measures how quickly a feature or fix can get from idea to customer ▪ “Idle time” in the delivery process −  Can be used to track how many time-consuming “handovers” still need to happen in the process
  • 29. 30 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Other common DevOps & Continuous Delivery goals that we see: ▪ Availability and use of “self-service” functionality −  Can be used to measure level of team empowerment and lack of dependency on specialists ▪ End-to-end throughput time −  Measures how quickly a feature or fix can get from idea to customer ▪ “Idle time” in the delivery process −  Can be used to track how many time-consuming “handovers” still need to happen in the process ▪ Duration of longest task(s) in the pipeline −  Indicator of the current biggest pain point(s) that can be tackled next
  • 30. 31 Copyright  2014.   How  Does  XL  Platform  Work  with  Others?   Change   Management/ ITIL  tools   Build,  Test,   Deployment,   Provisioning   AutomaCon   Planners,   organizers  &   communicaCon   tools       Manage  the  change   process   Orchestrate,     Deploy  &  Test   Synchronize  data   Release   team   Business     Owner   DevOps  team  
  • 31. 32 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Self-service cloud environment instantiations
  • 32. 33 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Throughput time and release “scorecard”
  • 33. 34 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Identifying “idle time”
  • 34. 35 Copyright  2014.   DevOps  &  Continuous  Delivery  Metrics   ▪ Long-running tasks and phases
  • 35. 36 Copyright  2014.   Measuring  Business  Value   ▪ Don’t forget to take a baseline before you start! −  Value Stream Mapping is a useful technique here
  • 36. 37 Copyright  2014.   Measuring  Business  Value   ▪ Don’t forget to take a baseline before you start! −  Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one −  Again, avoiding “Big Bang” helps identify which improvements are most effective
  • 37. 38 Copyright  2014.   Measuring  Business  Value   ▪ Don’t forget to take a baseline before you start! −  Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one −  Again, avoiding “Big Bang” helps identify which improvements are most effective ▪ Give changes time to settle −  There’s almost always an initial cost associated with a tooling or process change
  • 38. 39 Copyright  2014.   Measuring  Business  Value   ▪ Don’t forget to take a baseline before you start! −  Value Stream Mapping is a useful technique here ▪ Introduce changes incrementally and evaluate impacts one-by-one −  Again, avoiding “Big Bang” helps identify which improvements are most effective ▪ Give changes time to settle −  There’s almost always an initial cost associated with a tooling or process change ▪ “Both Dev and Ops are much more productive” ▪ “We reduced deployment times for weeks to minutes”
  • 39. 40 Copyright  2014.   Delivery  Automation  Platform               App  1.0  App  2.1   App  2.0   App  1.2       Dev   Test  1   Test  2   QA1   QA2   PROD   Private  /  Public  Cloud      
  • 40. 41 Copyright  2014.   Next  Steps   ▪ Get started with XL Platform today! http://go.xebialabs.com/Try-XL-Platform ▪ Learn more about XL Platform: http://www.xebialabs.com/products/xl-platform/ ▪ More Information Products: www.xebialabs.com/products Blog: blog.xebialabs.com Twitter: @xebialabs Videos: vimeo.com/xebialabs
  • 41. Thank    You!