Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Intro: DevOps is About Business Performance
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.
And, 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.
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:
- How do we improve product delivery to our customers?
- How do we change product more quickly to better satisfy our customers?
- How do we recover after failing our customers?
- 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 h
ave 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?
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:
- You get money after you bill.
- You bill after you deliver benefit.
- You deliver benefit after you ship.
- You ship after you’ve made the product.
- 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.
