How DevOps lost its way -- and how to bring it back

Government software development is at a critical inflection point. Many developers are still working remotely and will likely continue to do so for the foreseeable future. Meanwhile, IDC forecasts that 500 million software applications will be built over the next five years.

If ever there was a time the flexibility and agility of DevOps was needed, it is right now. Unfortunately, this savior of software development is stumbling under the weight of surging expectations, a rapidly changing environment and, most of all, a massive glut of tools.

Indeed, DevOps is a far cry from where it was when it first began. When the concept of DevOps was introduced in the late 2000s, its intention was to bring together developers and operations managers to accelerate development and innovation rapidly. Yet while DevOps does create an environment conducive to digital operations, shorter development cycles and greater agility, the practice has gotten far more complicated over the past few years as developers take on more responsibilities, like cloud migrations, systems integrations and security. As a result, some DevOps processes have slowed to a crawl -- the antithesis of what made DevOps great in the beginning.

The sheer number of DevOps tools developers have at their disposal is largely to blame. Some analysts estimate that teams use, on average, between 20 to 50 different DevOps tools. Certainly, many of these tools are necessary given the explosion of high-impact technologies like artificial intelligence, multicloud, edge computing and the internet of things -- their adoption having been accelerated by open-source technologies that spur innovation and, ideally, collaboration. Yet many of the tools do not work together, causing developers to spend a significant amount of time switching between different applications for a single project.

No one wanted this from DevOps -- and it’s hardly the atmosphere that government agencies need right now, when they are tasked with delivering citizen services quickly and cost effectively. They cannot afford growing technological complexities, siloed teams, fragmented communications and other obstacles.

How did we get here, and how do we get back to streamlined and efficient DevOps processes?

Too many tools, too much context switching, too little visibility

DevOps began to get weighed down the moment it became successful. That’s when many companies started developing solutions for specific DevOps needs, particularly agility, resiliency and security. They built solutions to ensure applications met service-level agreements around performance and uptime. Then, they built solutions for security management, continuous integration and delivery and so much more.

Developers use many of these tools simultaneously, sometimes in short increments and for a single project. This can result in “context switching” -- a productivity-killing practice that denotes interrupting workflows by continually switching between multiple tasks. Context switching undermines efficiency by creating legions of distracted and less focused developers who lose 20% of their productive time when switching between two projects. Estimates show context switching costs the U.S. economy about $650 billion annually.

Finally, the volume of tools makes it difficult for developers and operations managers to have complete visibility into a wide range of software development processes, from sprint planning and release management to incident resolution and retrospectives.

Lack of visibility makes it harder to understand which tools and teams work with others. It also leads to a lack of control and makes it tough to tell who’s using what solution for which purpose, diminishing collaboration among teams. For instance, one person could be using a solution like Confluence to document and update incident response procedures, while another team could be using PagerDuty to escalate incidents as they occur.

These seemingly smaller issues can add up to bigger challenges when agencies face critical issues, like resolving potential software code vulnerabilities or provisioning infrastructure. In these situations, everyone must be on the same page and working in tandem. If not, agencies not only risk slowing down their application development cycles, they also risk introducing potential security breaches.

The need for a DevOps central command center

To ensure developers and operations managers continue to be aligned across the DevOps process and that development remains secure, agencies must simplify the process as much as possible. But how does one simplify something that has grown so overly complex? After all, each DevOps tool has unique value and most cannot simply be removed from an agency’s ecosystem.

The answer lies in bringing those tools -- and the people who use them -- together under a central and unified interface. Much like an agency may monitor and control security threats from a single dashboard, organizations should create centralized hubs where developers can access an arsenal of DevOps tools. They can see and choose the solutions they need at any given time to enable a more efficient and agile development and deployment environment.

The hubs can also act as conduits for communications and collaborations. A message or idea posted on a particular board or channel can get automatically routed to the hub, allowing others to view and respond to the post without looking for the originating board or channel. Communication and collaboration can become more natural and fluid -- just as was initially intended with DevOps.

Consider this a DevOps central command center. Like a mission control center, it provides a central location where developers can work together unimpeded to carry out tasks and coordinate on projects. It consolidates tools, minimizes the need for context switching and provides greater visibility into how tools work together and who’s using them for what purpose. Most importantly, it brings DevOps back to its original intent: unifying teams and facilitating collaboration for faster and more effective software development.