During this webinar, we’ll discuss the “how” to help you get started or unstuck, and scale DevOps success across your business. Join us to see where you are in your evolution, how to get to the next stage, and to dig deeper into key findings like these: - In a DevOps evolution, there are many paths to success, but many more to failure. - Start with the practices that are closest to production; then address processes that happen earlier in the software delivery cycle. - Automating security policy configurations is mission-critical to reaching the highest levels of DevOps evolution.

1. How to start, scale and succeed
Presented by Nigel Kersten, Michael Stahnke and
Peter Bestel

2. About the authors
Alanna Brown
@alannapb
Nigel Kersten
@nigelkersten
Michael Stahnke
@stahnma
Andi Mann
@andimann

3. Today’s speakers
Nigel Kersten
Puppet
@nigelkersten
Michael Stahnke
Puppet
@stahnma
Peter Bestel
Diaxion
linkedin.com/in/peterbestel/

5. 2018 State of DevOps Survey
● 3,000+ respondents
● Better global representation
● Translated in French, German,
Japanese and Malay
5
Survey responses by region
Over the past 7 years, we’ve gathered 30,000+ responses from around the world,
making the State of DevOps Report the largest and most comprehensive study on the topic of DevOps.

6. Roles, departments, teams

7. We want to hear from you!
● How did you expand DevOps success beyond a single team? What worked
and what didn’t?
● How do you collaborate with ITSM and ITIL in this new DevOps world?
● What’s hard with about automating incident response in your organization?
● How did you get executive buy-in? If you’re an executive, what do you need to
know to support your team as they adopt DevOps practices?
● How do you make sure your organization is doing monitoring and alerting the
right way?

8. Key findings
8
● In a DevOps evolution, there are many paths to success, but even more that
lead to failure.
● Executives have a rosier view of their DevOps progress than the teams they
manage.
● Start with the practices that are closest to production; then address processes
that happen earlier in the software delivery cycle.
● Cross-team sharing is the key to scaling DevOps success.
● Automating security policy configurations is mission-critical to reaching the
highest levels of DevOps evolution.

9. In a DevOps evolution,
there are many paths to
success, but even more
that lead to failure.
9

10. 5 Stages of DevOps Evolution

11. 5 Stages of DevOps Evolution
11
Stage 1: Normalization
Application
development teams
use version control
Teams deploy on a
standard set of
operating systems
Stage 2: Standardization
Teams deploy on a
single standard
operating system
Build on a standard set
of technology
Stage 3: Expansion
Individuals can do work
without manual
approval outside team
Deployment patterns for
building apps/services
are reused
* Infrastructure changes
are tested before
deploying to production
Stage 4: Automated
Infrastructure Delivery
System configurations
are automated
Provisioning is
automated
* System configs are in
version control
* Infrastructure teams
use version control
* Application configs
are in version control
* Security policy
configs are automated
Stage 5: Self-service
Incident responses are
automated
Resources available
via self-service
* Applications are
rearchitected based on
business needs
* Security teams are
involved in technology
design and
deployment
Stage 0
Monitoring and alerting are configurable by the team operating the service
Reuse deployment patterns for building applications or services
Reuse testing patterns for building applications or services
Teams contribute improvements to tooling provided by other teams
Configurations are managed by a configuration management tool
* These practices are highly correlated with the stage.

12. Stage 0: Build the Foundation
12
• Monitoring and alerting are configurable by the team operating the service
• Reuse deployment patterns for building applications or services
• Reuse testing patterns for building applications or services
• Teams contribute improvements to tooling provided by other teams
• Configurations are managed by a configuration management tool

13. Stage 0: Monitoring and alerting are configurable by team
operating the service
24xmore likely to always enable
configuration of monitoring and
alerting

14. Stage 0: Reuse deployment patterns for building applications
or services
23xmore likely to always reuse
deployment patterns for building
applications or services

15. Stage 0: Reuse testing patterns for building applications or
services
44xmore likely to always reuse
testing patterns for building
applications or services

16. Stage 0: Configurations managed by configuration
management tool
27xmore likely to always manage
configurations using a
configuration management tool

17. Stage 0: Contribute to other teams’ tooling
44xmore likely to always contribute
to other teams’ tooling

18. Stage 1: Normalize the Technology Stack
18
Stage Defining Practices Contributors to Success
● Application development
teams use version control
● Deploy on a standard set of
operating systems
● Build on a standard set of
technologies
● Put application configurations in
version control
● Test infrastructure changes before
deploying to production
● Source code is available to other
teams
1

19. Stage 2: Standardize and Reduce Variability
19
Stage Defining Practices Contributors to Success
● Deploy on a single standard
operating system
● Build on a standard set of
technologies.
● Reuse deployment patterns for
building applications and services
● Re-architect applications based on
business needs
● Put system configurations in version
control
2

20. Stage 3: Expand DevOps Practices
20
Stage Defining Practices Contributors to Success
● Individuals can do work
without manual approval
outside team
● Reuse deployment patterns
for building applications and
services
● Infrastructure changes are
tested before deploying to
production*
● Individuals accomplish changes without
significant wait times
● Post-incident reviews occur and results
are shared
● Build on a standard set of technologies
● Teams use continuous integration
● Infrastructure teams use version control
● Service changes can be made during
business hours
3

21. Stage 4: Automate Infrastructure Delivery
21
Stage Defining Practices Contributors to Success
● Automate system
configurations
● Automate provisioning
● Application configurations
are in version control*
● Automate security policy configurations
● Resources made available via self
service
4

22. Stage 5: Provide Self-Service Capabilities
22
Stage Defining Practices Contributors to Success
● Incident responses are
automated
● Resources available via self-
service
● Re-architect applications
based on business needs*
● Security teams are involved
in technology design and
deployment*
● Security policy configurations are
automated
● Application developers deploy testing
environments on their own
● Success metrics for projects are visible
● Experiences and lessons are shared
externally
● Provisioning is automated
5

24. Cross-team sharing is the key
to scaling DevOps success.
24

25. Sharing and DevOps evolution

26. Executives have a rosier view
of DevOps progress than
the teams below them.
26

28. Start with the practices that are
closest to production, then
address processes that happen
earlier in the software delivery
cycle.
28

29. Automating security policy
configurations is a critical
practice at the highest levels
of DevOps evolution.
29

30. DevOps Ingredients
DevOps enablement involves:
We all need to be on the same journey for it to work, we need to constantly question the “why do we do it
that way” and consider “how can it be done” to enable the realisation of the business outcome to realise the
business benefit that we anchor the program around.
DevOps
Transformation
People
ProcessTechnology

31. What are the common approaches to DevOps
• DevOps seems to be implemented in one of three ways. Each can be successful but this does
depend on the organisation maturity and leadership across a number of aspects
• However one approach is seen as the most successful
The directive – we
now do DevOps
Everyone does
DevOps
Incremental
DevOps*
• Top down directive
• Large project
• Large change
• Agilifall
• High failure rate
• Takes a long time
• Cost upfront
• Mandate to do leads to free
for all
• Everyone does it differently
• Multiple approaches
• Not optimised for the whole
• Multiple tools
• Expensive in the long term
• Lack of experience and total
capability
• Start small
• Just in time & incremental tools
• Choose for success
• Bring one dev & selected ops
team together
• Most successful
• Can be frustrating for others
not involved
• Success breeds success
Diaxion’s Approach

32. Customer to Customer delivery – process map – DevOps needs to
consider
Requirements
& Architecture
Business requirements
Operations requirements
Architecture
requirements
Security requirements
Process architecture
System architecture &
design
Security
Build &
procurement
Software development
Infrastructure
provisioned & configure
Database & packages
build
Process build – business
and technology
Environment definition
Security validation
Integration and
acceptance
Functional integration
Process integration
Operations integration
Functional QA
User QA
Security scanning
Production
delivery
Operations validation
Change delivery
Deployment
Application support
Business support
Infrastructure support
Customer acceptance
Release
Customer Request
Who is the customer that
represents business value creation
Customer enabled
Able to deliver to
the business
Approvedproject
Deliveredvalue
It is important to process map the business outcome from the real
customers perspective

33. Diaxion – Our Approach to Incremental DevOps
Roadmap
Identify, automation, integration and tool chain requirements
Optimise the process maps
Process map to the user stories
Identify user stories for the business outcomes
Identify business outcomes & “what’s in it for me” for each group aligned to
business outcome

34. • DevOps Target State / Target state Operating model
• Process mapping and optimisation
• DevOps Kickstart
• DevOps Health Check
• DevOps professional services / development
• DevOps mentoring
Sydney Office
Ph: +61 (0)2 9043 9200
Melbourne Office
Ph: +61 (0)3 9036 8900
Sales information – sales@diaxion.com
Diaxion DevOps Services

35. Questions
35

36. 36
Get your copy
info.puppet.com/Diaxion-Puppet-State-of-DevOps-Report