The evolution of devops from ‘Kumbaya’ to value

We’re nearly 10 years deep in the devops movement. On the one hand, a great deal has been accomplished. On the other, many organizations still have a long way to go.

4 software engineering

As a technologist who has spent most of my career in the Silicon Valley scene, I’m used to the kind of progress that can put the “next big thing” out of fashion the very same day it was conceived. Maybe I’m exaggerating, but the New York Minute has nothing on the San Francisco Second — a moment in time where innovations and ideas start and end. It can be hard to keep up with, and in many ways is a false reality.

Although the news, analysts and our own passion as technology professionals live in that fast-paced world where everything changes daily, the actual adoption of technologies and the pace of most of the world’s largest organizations moves much slower. In reality, it can take decades for a giant retail chain to modernize data storage for example or can take years for banking applications to update security features. Why do the breakthroughs happening every day at startups in the Bay Area, Austin, Boston, Denver or other tech hubs take so long to spark change in the practices of IT departments at the enterprise level?

Change is a process, it’s never automatic —  well, unless we’re talking about devops. Automating change is a byproduct of devops done right. Let’s look at the evolution of devops as a software development and delivery practice. On one hand, the movement has evolved steadily during the last few years. But, let’s not forget about reality — are organizations moving as quickly as the thinking behind the movement? Have the innovations introduced by the devops tools ecosystem made a difference in the way large companies conduct business? In some cases, yes, and in other cases not so much.

To get a proper gauge on where enterprises are with modernizing software development to be more collaborative, efficient and open, let’s look at the origin of the devops movement. Ernest Mueller gives a great in-depth summary of the definition and history of devops in this blog post. In the early 2000’s industry luminaires began to emphasize that, as Agile practices became more effective, the need for end-to-end visibility, collaboration and management of both software development and IT operations became apparent. The idea was to create collaborative, connected environments where software change could happen rapidly, even automatically, and hang-ups could be avoided by inherent feedback loops.

By 2009, devops gained in popularity, adoption and enthusiasm, much like the agile movement.  Much of the emphasis in the early days of devops was on empathy and teamwork. Tools and solutions began popping up quickly in the following years as teams looked to automate manual processes and bring greater visibility to developers into how their code was implemented by operations teams, allowing for earlier collaboration.

Of course, these solutions made sense and the movement kept calling for greater efficiency, better quality software and faster release cycles.

Just two years ago the devops movement focused primarily on point tools and solutions. The idea was that if organizations could automate processes and use feedback loops to increase software quality and speed, companies would be more responsive to customer needs.

Now, among many technical professionals — the ones living in the fast-paced world I mentioned — devops is a given. The emphasis has moved from the possibilities embracing devops could achieve and now looks closely at the cold hard ROI. The devops movement has lately come to center on business value.

The question is no longer, what could devops do for me? It is now: We’ve adopted devops, how do we know it’s working?

Let’s contrast this progress of the devops movement with the progress of organizations worldwide. The answer is not simple, in fact, devops adoption at the enterprise level is a wide spectrum.

I encounter large organizations like Etsy or Adobe that have made innovative strides in devops. I also talk to many organizations that have large monolithic systems and do not want to change the way things are done for anything in the world. Companies that fall in the second camp may be just as large and influential as the companies I mentioned first that are knocking it out of the park with devops.

The truth is devops is just one of many roads leading to the same place. Where? The answer is simpler than you might think. devops, agile, ITIL, Waterfall, CI/CD are all methods leading to…a happier customer. No matter what your approach, success is measurable, and the software industry is now placing an emphasis on the actual ROI of devops investments made in the tools and point solutions adopted within the last few years.

One of the emerging ways to evaluate the value of devops — even for organizations who have not evolved with the devops movement — is to look at value streams and measure software delivery success through this Lean management approach. I’ve discussed Value Stream Management before, and its use in measuring business value.  In fact, the devops community is now following suit, with new sets of metrics and KPIs as a means of increasing the quality of products and speed of delivery.

My colleague Eric Robertson, VP of product engineering here at CollabNet, has written extensively on reaching devops success through Value Stream Management. As he says, improving the flow of work through the value stream changes how you deliver value to customers, and if the devops movement is about anything, it’s about change.

It’s been a wild ride watching devops grow over the last few years from a collaboration and empathy movement to a methodology that’s focused on analytics, measurement and value.

We’re nearly 10 years deep in the devops movement. On the one hand, a great deal has been accomplished. On the other, many organizations still have a long way to go. While it’s easy to get caught up in the “next big thing,” and the latest shiny objects or trends in tech, it’s important for vendors to focus on what is important to enterprises—delivering value to customers. When you start with the value stream it doesn’t matter what development methodology you ascribe to, we are all working toward the same goal.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Spring 2018 digital edition of CIO magazine