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.

22. 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:

23. 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

24. 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!

25. 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

26. 26 Copyright
2014.
DevOps
&
Continuous
Delivery
Metrics
▪ Other common DevOps & Continuous Delivery goals that we see:

27. 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

28. 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

29. 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

30. 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

31. 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

32. 32 Copyright
2014.
DevOps
&
Continuous
Delivery
Metrics
▪ Self-service cloud environment instantiations

33. 33 Copyright
2014.
DevOps
&
Continuous
Delivery
Metrics
▪ Throughput time and release “scorecard”

34. 34 Copyright
2014.
DevOps
&
Continuous
Delivery
Metrics
▪ Identifying “idle time”

35. 35 Copyright
2014.
DevOps
&
Continuous
Delivery
Metrics
▪ Long-running tasks and phases

36. 36 Copyright
2014.
Measuring
Business
Value
▪ Don’t forget to take a baseline before you start!
− Value Stream Mapping is a useful technique here

37. 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

38. 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

39. 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”

40. 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

41. 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

42. Thank
You!