I have seen far too many definitions of the term DevOps. Everyone, including myself, has their own definition. Worse, I have seen even more interpretations of what “doing DevOps” means within enterprises. Here are a few examples of what some people think DevOps is:

  • Automating infrastructure
  • Building out CI/CD pipelines
  • Writing Chef scripts
  • Creating a new silo called DevOps
  • Doing anything on AWS

All of the above-mentioned items are tasks that are common when a company embraces DevOps philosophies but by themselves are not DevOps. DevOps is much bigger than these specific tasks.

DevOps Is Not Technology

Damon Edwards once said “DevOps is not about technology. DevOps is about a business problem.” Sure, a lot of technology is used to solve business problems, but focusing purely on technology misses the point. Every year, Puppet Labs does a large survey and produces the State of DevOps report. In these reports, Puppet talks about how DevOps can contribute to making an IT organization a high-performing one. The statistics show that high-performing IT shops deliver value to the bottom line, which means increased sales, profitability, competitive advantages, and employee morale.

When I talk to clients about DevOps, I like to talk about what the client deems the desired outcomes, rather than discussing infrastructure automation. I believe the conversation should start by focusing on business outcomes before looking at technology solutions. It is highly likely that automation will play a huge role in enabling the desired business outcomes, but when automation is the initial focus before understanding the business problems, then automation becomes a crutch instead of an enabler.

DevOps Comes from Lean

DevOps takes a chapter from lean manufacturing and applies it to IT. First, you should set the technology aside and focus on identifying bottlenecks. Bottlenecks exist not only in the technology, but also in the people (culture and organization structures) and process (IT and business). A mistake I see within many enterprises is that they start with automation without removing the existing bottlenecks. The result is the automation of waste. Culture and organizational structures are often major bottlenecks. Tackling these two issues can be really challenging, especially within a culture that is not a high-trust one.

When companies focus purely on the technology aspects of DevOps, they may make some nominal improvements (or they may not), but they will not likely become high-performing IT shops. In many cases, I have seen companies form a DevOps team that becomes a new silo, just acting as a bridge between dev and ops instead of creating an environment of better collaboration between dev and ops. This is a classic anti-pattern that often results in less-than-stellar outcomes.

Think Bigger than Software

I recently spent time studying 3D printing and digital manufacturing. What I discovered is that the agility and speed that I see the cloud and the DevOps approach bringing to the large enterprise and its software generation process is very similar to what 3D printing is bringing to product engineers. The parallels between what product engineering is trying to accomplish and what we are trying to accomplish in IT are amazingly similar.

In the old days, a person would design a CAD/CAM model that would be sent off to another group (often outside of the company) to produce a working prototype. In two to three weeks, the prototype team would send the first version of the prototype back for review. The reviewers would provide feedback and request additional changes. The prototype and the CAD/CAM design would be sent back for the next iteration. This process would repeat for months, until the product owner finally was finally satisfied that the prototype was in a state to move to the next phase of production.

With 3D printing, the goal is to get feedback faster in the product lifecycle and allow for more iterations in shorter time frames. That sounds very similar to what DevOps preaches. Faster feedback loops, incremental changes, smaller changesets.

The new process works like this: A designer creates a CAD/CAM design, which is fed directly to a 3D printer. The 3D printer creates a working prototype in a few hours, as opposed to weeks. The team can immediately review the prototype and continue iterating through this process until an acceptable prototype has been built. This entire process can be completed in days instead of months, and the total cost of the process is substantially lower.

This is exactly what we are trying to achieve with DevOps within IT. Increased agility, better collaboration, faster feedback, and better results.

Focus on Business Outcomes

In the 3D printing example above, the business outcomes are many:

  • Faster to market
  • Better-quality product (due to more iterations, more accurate models, faster feedback)
  • Competitive advantage: better quality, lower price, new products get to market faster
  • Improved customer satisfaction: ability to customize, better quality, shorter cycle times to deliver new products the client desires

Many of these business outcomes are exactly what a well executed DevOps strategy can yield. If we are able to iterate quickly with more “working models” in front of our customers, we can produce software that better meets the needs of our customers. Getting faster feedback earlier in the lifecycle should also improve the overall quality and improve speed to market. Automating infrastructure and pipelines plays a huge role in enabling this, but only if the automation is designed after understanding the optimal process.

Summary

DevOps should focus on driving improved business outcomes, not on technology. Technology is an enabler. Automation is a key contributor to that enablement, but automation is not DevOps. In fact, everything we do in IT should be based on delivering better business outcomes. When we lose sight of that, IT becomes nothing more than a cost center that is a necessary evil on the balance sheet. And when that happens, management looks at ways to outsource IT to lower the cost. When IT is a business enabler and a partner in the overall company’s success, IT becomes a revenue generator and a source of competitive advantage.

2 replies on “Stop Focusing on DevOps and Start Focusing on Delivering Business Outcomes”

  1. Hello, Mike!
    Thanks for interesting post!
    I suppose that in a general way, we can determine DevOps like a specific culture/environment that serves for overall business success.

Comments are closed.