DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Business of DevOps » What is DevOps’ Business Value?

What is DevOps’ Business Value?

By: Christopher Little on June 2, 2016 5 Comments

Intro: DevOps is About Business Performance

Recent Posts By Christopher Little
  • DevOps is Dead! Long Live DevOps!
  • Why Is There No DevOps Manifesto?
More from Christopher Little
Related Posts
  • What is DevOps’ Business Value?
  • 9 Open Source DevOps Tools We Love
  • Nurturing a Developer-Centric Culture
    Related Categories
  • Blogs
  • Business of DevOps
    Related Topics
  • DevOps advantages
  • DevOps ROI
  • payback
Show more
Show less

It is important understand that DevOps philosophically has a system-level view of a business’ performance. You don’t hear this much—it’s more difficult to write about than, say, the latest tech, but it’s always there under the covers.

Screen Shot 2016-05-25 at 5.35.08 PMAnd, granted, the frequent focus for DevOps grassroots discussions is about tooling, about tech, about software pipeline—the “IT” in “ITSM,” so to speak. That’s usually because all of the people in those discussions have Dev or Ops or related functions as a job and already know all-too-well the business runs on the work they’re responsible for. You’ll see this at any DevOps Days you ever go to.

DevOps/Cloud-Native Live! Boston

As should be clear to everyone: All businesses today are in the IT business. This is regardless of what business they think they’re already in. DevOps is born from a disruptive crucible where the world of business morphed from being “do X” to “do X via computing” (i.e., a bank is no longer a bank, it’s now an IT shop with a banking license).

This is where newcomers can mistake the forest for the trees: The heart of the DevOps movement is unrelenting focus on the “SM” in “ITSM.”

Yes, automation gets involved. And rightfully gets a lot of discussion because it is such a huge force multiplier. However, other DevOps 101 beginner’s basics such as, “Have the developer carry a pager,” clearly are about bigger issues than which configuration automation tool you use.

The numbers I will be reviewing here aren’t new. They aren’t mine. I often get the feeling when discussing these numbers with people that they aren’t getting what these numbers mean, in business context. How huge a powerhouse DevOps drives. So I’m going to try to explain a bit and try to put it all in context.

So What is the Value to Business from DevOps?

I wanted to set the stage a little so that we can properly discuss DevOps return on investment (ROI) in context of every business is in the IT business. The fundamentals of business performance are pretty crisp. We all get lost in new shiny and new toys.

New shiny toys are the best.

Yet DevOps as a philosophy is bigger.

To be blunt, practicing DevOps as a philosophy gets you the latest, actionable answers to fundamental business questions:

  1. How do we improve product delivery to our customers?
  2. How do we change product more quickly to better satisfy our customers?
  3. How do we recover after failing our customers?
  4. How do we get paid faster by our customers?

All of these directly impact sales, revenue growth, profitability, product line and business viability, customer satisfaction—all of which hScreen Shot 2016-05-25 at 5.36.32 PMave direct correlation back to investment in the business.

I’m going to use Puppetlabs 2015 industry survey and work from remarkable folks such as Gene Kim, Jez Humble (Continuous Delivery and Lean Enterprise), Nicole Forsgren, plus Mary and Tom Poppendieck. I’m pulling from these few for this ultra-specific focus on ROI, but there’s a lot of excellent other sources and material for potential ROI explanations out there.

So let’s answer our questions.

1. How Do We Improve Product Delivery to our Customers?

The fact is, our product isn’t doing anything valuable until our customers are using it. It isn’t making us any money. It isn’t making them any happier. It only does and can do that when we’ve actually produced it, put it into production, and gotten it into the customers’ hands.

And DevOps-practicing companies do this at the rate that is unparalleled. Some of this is a result of that strong DevOps tendency to use automation as a multiplier, and some of it is a holistic view toward facilitating hand-offs and team collaboration. All of it, however, is DevOps.

Studies show these DevOps companies have an almost supernatural advantage of 30x the deploy frequency of their non-DevOps peers. Put it another way, if you’re not embracing DevOps against someone who is, they can on average do what you do but do it 30 times faster than you. 30x.

That is, if your business is in a footrace, you’re up against The Flash. Good luck with that.

2. How Do We Change Product More Quickly to Better Satisfy Our Customers?

The best product features are the ones the customers actually use. So, you focus on features they like (or want to have) based on their usage and fit. This frequently involves a little A/B testing on a subgroup and increasing it to larger groups until it’s everyone. It involves speed of offering as a way of measuring improvements.

Amazingly, as it turns out, companies that adopt current DevOps practices have radically positive advantages here on changing product.

I’m going to cite the simplest metric I’ve heard of. There’s a truly nifty test devised by Mary Poppendieck. It’s super simple. It gets you instant insight into the velocity of your product development pipeline at your company.

Answer this basic question: How long does it take your organization to put a single, new line of code into production?

For many companies I know of, the answer will be in units of months. Months. For DevOps-practicing companies, the answer often is as long as a couple of weeks to as short as an hour. Months versus hours?

That is a devastating difference in competitive advantage. If your competitor takes months to deliver something to its customer that you can deliver in an hour … But wait, what if it’s your company that takes the months and the competitor that takes the hour …

They’ve even quantified the difference. The DevOps-enhanced companies have a 200x faster lead time over their non-practicing peers.

So, not only do DevOps companies iterate in production far far more quickly, they can move to production even faster than that.

3. How Do We Recover After Failing Our Customers?

There’s always some joker in a crowd who will say, “Well, don’t fail the customer in the first place.” I’ve encountered this point-of-view in executives who haven’t ever programmed or really understood how computers compute. Those are the 100 percent-uptime folk and they don’t get it.

That’s not real world. You will fail; your front-end systems will fail. Some failures will even be catastrophic. Focusing on the meantime between failure (MTBF) is an old hardware-oriented way of thinking. It’s out of date and dangerous in this new age. It’s how we measured the durability of car parts or hard disks or plumbing. (A handy ACM article from Facebook on Fail at Scale is always a good read.)

Embracing the notion that you will fail—and that you should even practice failing—is a key mental step to focusing on meantime to recovery (MTTR). MTTR is how quickly are you back up and running after that failure that will occur has occurred.

And DevOps-savvy companies are amazing here as well, averaging a 168x reduction. That is, on average they are 168 times faster at recovery than their non-DevOpsian peers.

And what about those failures caused by changes, whether they be configuration or application related? The so-called “change success rate”?

The number there for DevOps enabled is astounding, too. There is a 60x improvement in change success rates. So not only do these companies make changes faster, more frequently, with better recovery, they do so with a phenomenally better change record.

4. How Do We Get Paid Faster by Our Customers?

This last one is subtle because it’s the snowball-rolling-downhill accumulation of all the previous DevOps factors at play. Basically, the business life cycle at work.

(I’m not going into “paid” versus “recognizing revenue,” as recognizing revenue means more than getting paid and there are a bunch of accounting rules around that in the software industry. Nor am I going into the difference between purchased versus SaaS/CapEx versus OpEx. It’s an important topic to understand around revenue models but outside the purview of this.)

It basically is gated like this, reverse-chronological order of importance for an ongoing business:

  1. You get money after you bill.
  2. You bill after you deliver benefit.
  3. You deliver benefit after you ship.
  4. You ship after you’ve made the product.
  5. You get money to make product.

DevOps-embracing companies iterate thru steps 1 thru 4 of this cycle day in and day out, as we’ve reviewed above, at a pace that will ruthlessly crush all competitive laggards. I mean, flatten.

The rates of change allowed by DevOps practices support such rapid acceleration away from the old norm. It’s startling.

So, I suppose I’m saying not only can your company adopt DevOps changes, I’m telling you that you must. Even better, adopt and you’ll probably thrive.

And since I’m talking about modern business, a Deming tax:


P.S.: What about those corporate tales of “DevOps failures” I hear about?

Over the years I hear the odd pundit or company executive dismiss DevOps as a unicorn thing or something that older, established organizations with years of built-in (anti) patterns of behavior can’t adopt. Or they claim they are in a sui generis industry like ahem banking where, well, they’re going to claim they can’t change because … you know, stuff.

At a big analyst conference a couple of years ago I heard how there are many examples of “DevOps failures” at clients’ firms. In every case I heard about, however, the failure turned out to be unrelated to anything DevOps. They turned out to be related directly to poor analyst advice, or woeful execution, or simple gross misunderstanding.

I’m not going to name names or shame them. I’m just going to say it’s incorrect in every case I’ve seen to cite “DevOps” as “the failure.” When you hear anyone talk about a DevOps failure, dig into it. It won’t be there in the end; it’ll be something else that actually derailed the effort.

Most businesses are still command-and-control model orgs where you find a range of managers, mostly process-oriented, who are micro- to macromanagers. And you have fiefdoms. And the customer is rarely in the room. Culture plays a big role here.
If your culture is healthy, you optimize for your people, for your customers and for achieving good customer results with the teams of people who are organized to do that. Curiously, if you do this, based on surveys, your company gets great and also becomes a great place to work!
Now, that’s DevOps thinking at work.

Screen Shot 2016-05-25 at 3.34.32 PM

Filed Under: Blogs, Business of DevOps Tagged With: DevOps advantages, DevOps ROI, payback

Sponsored Content
Featured eBook
The State of the CI/CD/ARA Market: Convergence

The State of the CI/CD/ARA Market: Convergence

The entire CI/CD/ARA market has been in flux almost since its inception. No sooner did we find a solution to a given problem than a better idea came along. The level of change has been intensified by increasing use, which has driven changes to underlying tools. Changes in infrastructure, such ... Read More
« The Cultural Divide
DevOps: Shift Left to Reduce Failure »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Modernizing Jenkins Pipelines With CD Automation
Tuesday, May 17, 2022 - 11:00 am EDT
Applying the 2022 OSSRA Findings to Software Supply Chain Risk Management
Tuesday, May 17, 2022 - 1:00 pm EDT
Getting Mainframe and IBM i Data to Snowflake
Tuesday, May 17, 2022 - 3:00 pm EDT

Latest from DevOps.com

Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil
May 16, 2022 | Vladi Sandler
Why Data Lineage Matters and Why it’s so Challenging
May 16, 2022 | Alex Morozov
15 Ways Software Becomes a Cyberthreat
May 13, 2022 | Anas Baig
Top 3 Requirements for Next-Gen ML Tools
May 13, 2022 | Jervis Hui
Progress Expands Scope of Compliance-as-Code Capabilities
May 12, 2022 | Mike Vizard

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The State of Open Source Vulnerabilities 2020
The State of Open Source Vulnerabilities 2020

Most Read on DevOps.com

Agile/Scrum is a Failure – Here’s Why
May 10, 2022 | Richi Jennings
How Waterfall Methodologies Stifle Enterprise Agility
May 12, 2022 | Jordy Dekker
How to Secure CI/CD Pipelines With DevSecOps
May 11, 2022 | Ramiro Algozino
Update Those Ops Tools, Too
May 11, 2022 | Don Macvittie
Progress Expands Scope of Compliance-as-Code Capabilities
May 12, 2022 | Mike Vizard

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.