Measuring Your DevOps Maturity

1

• Measuring Your DevOps Maturity
• Incorporating DevOps into your organization is
  not a zero-sum game. It is a journey. And like
  most journeys, it can be measured.
• When measuring your DevOps journey, you need to
  show progress as well as setbacks. Additionally,
  its critical that you make sure these
  measurements are accurate, automated, and
  visiblejust like your DevOps.
• So when it comes to measuring, where do we start?
  First, lets make sure were all talking about
  the same thing.

2

• What Is DevOps?
• When many people think about DevOps, they narrow
  the definition down to an application build
  pipeline. Whatever makes the code get from the
  developers IDE out to production in an automated
  fashion is their DevOps. But theres more to it
  than that.
• DevOps involves not just the applications, but
  also infrastructure, data, and your enterprise
  itself. Its not just about the automation and
  monitoring of those aspects, but building the
  culture of DevOps around core values.
• Given this definition, how do you measure where
  you are in your DevOps journey?
• How Mature Is Your DevOps?
• Source Enov8s 100 Agile within a Year The
  DevOps Cube
• Now that weve defined DevOps, were going to
  take a look at how to measure DevOps maturity.
  Were going to pull some concepts from Enov8s
  DevOps Maturity Block, as well as additional
  things that can help you figure out where you are
  on the journey.

3

• First, the DevOps Maturity Block identifies where
  you are with the build, deploy, and test stages
  of your application for your application, data,
  and infrastructure. By identifying where each of
  these segments are in the journey, you can see at
  a glance what areas you should focus on.

4

• And the stages can be separated into six
  sections
• Chaos There is no automation, or
  hacked-together, un-monitored scripts run loose
  on your environments. Each team does their own
  thing.
• Manual There are steps, but most include manual
  intervention. Whether its running a script or
  manually moving files around, your people are the
  process.
• Hybrid Here were starting to get some good
  automation and monitoring in place.
• OneCommand This can be seen as the easy button.
  This could mean that deploys require someone to
  approve or push a button.
• SelfService Applications, data, and
  infrastructure are self-service. If a team needs
  a new integration environment, theyre able to
  provision it themselves without much difficulty.

5

• DevOps Maturity for Applications
• The longer applications sit in a development or
  testing environment, the harder deploying to
  production will be. Requiring more manual steps
  increases the chances of human error.
• When you add uncertainty and points of failure,
  you add to the chance of something going wrong.
  This isnt the fault of bad programmers or
  individual screw ups this is probability.
• The ease with which you can move code safely from
  development to production indicates how mature
  your DevOps is. So how do you measure your
  applications maturity?
• Well, how many of the following practices do you
  have as automated components of your deployment
  pipeline?
• Builds kick off automatically based on a commit
  push or a pull request.
• Tests run automatically at all levels unit,
  acceptance, contract, and canary.
• Automated code coverage and code linters measure
  and report on your code trends.

6

• 4. Security scans search your code and
  dependencies for vulnerabilities.
• 5. Monitoring is in place, ensuring that your
  application is up and running. Proper health
  checks and error reporting provide quick
  feedback when things go wrong.
• Then once you have the proper automation in
  place, keep an eye out for DevOps deployment
  smells like different scripts for different
  environments or waiting for slow times to deploy.
  Dont let bad habits like that take away from
  your progress.
• DevOps Maturity for Infrastructure
• Have any of you worked in an environment where it
  took months to get virtual machines set up for a
  new project? Or perhaps one where changes to
  infrastructure were all done manually, making
  them prone to error?
• Or worse, have you seen changes to infrastructure
  that brought everything to a crashing halt but
  that couldnt be simply undone because teams were
  creating all this infrastructure by hand?

7

• DevOps can fix this, giving you confidence and
  repeatability where often theres been none.
• For infrastructure, look at capabilities around
  automating, streamlining, and allowing
  self-service for
• Provisioning environments.
• Vertical and horizontal scaling.
• Migrating between hosts, servers, or even cloud
  providers.
• Deploying to multi-cloud environments.
• Rebuilding infrastructure weekly or even nightly.
• DevOps Maturity for Data
• Ive seen many companies and corporations that
  like to skip the data side of DevOps.
• Its too difficult. Data has state! You cant
  automate that, they lament.
• We need stricter controls. We have to have the
  DBAs verify good design! they cry.

8

• But what really happens? The data architects fill
  out forms and diagrams. They throw requests for
  new tables and columns back at the developers
  because the requests didnt meet some
  incomprehensible and ever-changing naming
  standard.
• The DBAs wait for tickets and requests. Then they
  mindlessly execute those changes without much
  thought as to what the consequences are. And
  deployments fall behind because someone somewhere
  is waiting on a request fulfillment from the
  database team.
• Oh, and theyd better have that request executed
  at exactly the right time, or the application
  will break!
• You may suspect that DevOps can help improve this
  as well. Youd be correct.
• DevOps for data, or DataOps, has been a growing
  field of opportunity. The idea here is to find
  ways to automate changes to the data and validate
  functionality on a regular and automated basis.

9

• DevOps Maturity for Enterprise
• Now whats often missed in the understanding of
  DevOps? The effect DevOps creates in the
  enterprise as a whole.
• Good DevOps gives an overarching end-to-end view
  of not just one system, but all the systems
  currently running. DevOps cannot solve all your
  problems if you do not take a holistic view.
• As mentioned before, our measurements should be
  automated. But how do we automate something that
  traditionally took the form of a hand-crafted
  Excel report or a PowerPoint?
• Fortunately, Enov8 has you covered with its
  ecosystem dashboards. These dashboards provide
  that holistic view youve been missing. They will
  quickly show you how well youve progressed on
  your DevOps journey.

10

• Whats the Harm in Not Measuring and Improving
  DevOps?
• Youve been doing things the same way for years,
  if not decades. Sure, it takes longer to get
  things to production than it used to, but thats
  just a natural part of growing a system. Right?
• Perhaps not. Here are the two biggest risks that
  come with not checking in on your DevOps.
• Overcompensating with Manual Processes
• One thing that often goes wrong in enterprise is
  that mistakes and misses are replaced with
  additional red tape. This red tape slows down the
  release of new features and changes. It ensures
  quality by making everyone jump through 30
  burning hoops.
• Whys this bad, you ask? If we ever meet and have
  time for a chat, ask me about the horrors of
  filling out Excel forms to request a deployment
  from one environment to another. And listen
  carefully when I tell you about additional weird
  requirements.

11

• These requirements push you to specify each
  changed file and version that gets deployed
  together. Consider the paperwork involved when
  one of those program files needs a small update
  thats found in the two-week testing window.
• Prepare for me to blow your mind about processes
  created simply to make the system feel safer.
• Why do things like this happen?
• Because processes like this come out of good
  intentions. Someone noticed a flaw or bug that
  made it to production. Then instead of automating
  a solution to fix the problem, additional manual
  checks were added with the intention of making
  sure the mistake never happened again.
• Unfortunately, all this did was slow down
  development to a crawl and add frustration to
  everyones lives. Youve only added the illusion
  of safety.
• So what else is there?

12

• The Friday Afternoon Fear Factor
• Does the idea of deploying something to
  production on a Friday afternoon fill you with
  fear? Do you have a sense of dread coming over
  you when you think about all the potential
  disasters that could be lurking and jumping out
  at your customers all weekend long?
• Know that this fear is good. It is normal. But
  what you want to do next is identify where the
  truth lies beyond that fear. And then you can
  address it.
• Though if that sounds a bit too much like your
  last meditation session, lets make it more
  concrete. What automation and safeguards will
  give you the confidence to not worry over each
  production deploy?
• Start listing them out. What are the things that
  you or your team does manually after every deploy
  to production? Does your deployment process
  include manual checking, double checking and
  gaining sign off of every step? Congrats, you
  just found some great places to start your DevOps
  maturity journey!

13

• Where Do We Go From Here?
• As we all know, just because we say we have a
  culture of DevOps doesnt make it true. Adding in
  random points of automation here and there wont
  give you the big picture sense that youre on the
  right track.
• To truly realize the benefits of DevOps, you must
  take a good hard look at where youre at and then
  make the necessary changes to move your
  organization in the right direction.

14
Contact Us

• Company Name Enov8
• Contact Person Ashley Hosking
• Address Level 5, 14 Martin Place, Sydney, 2000,
  New South Wales, Australia.
• Phone(s) 61 2 8916 6391
• Fax [phone]
• Website - https//www.enov8.com

15
Thank You