DevOps: Ten Years Later and Ten Years More

By JP Morgenthal & James Moscariello

This year marks ten years since the initial DevOps Days event in Ghent. Interest and popularity of this movement have grown significantly over the past four years, due heavily in part to the results of Puppet’s “State of DevOps” reports and subsequent research provided by “Accelerate”, written by Forsgren, Humble, and Kim.

While skepticism for any new approach, method, etc. in IT is normal, the compelling empirical evidence put forth by these publications is impressive and worthy of the attention of both IT and the business that they support.

But despite the fanfare and considerable investment, DevOps adoption still challenges most enterprises. Experts enumerate a myriad of reasons explaining why businesses are still unable to achieve the goals outlined in the aforementioned publications. With so many potential points of failure, creating an effective strategy to fix or implement DevOps can be daunting.

To make it easier to get to a state of DevOps, we draw on seven years of DevOps experience to summarize where most companies are falling short in adoption, then paint a picture of an ideal DevOps future state. We then provide DevOps GOLD as a template for thinking through your organization’s current state and crafting a strategy that will be effective in getting you to the ideal future state.

Ten Years Later

Our efforts to uncover issues with DevOps adoptions started by exploring why teams place such high emphasis on tooling. It turns out that the technologies deployed by DevOps pros are the easiest to observe and the easiest to “order up”, so to speak. Culture and organizational design are much harder to define, design, and measure, so simply put: People focus on tooling because it’s easier.

Unfortunately, over four decades of IT projects we have learned that technology is not usually the most impactful lever of IT projects, but rather the focus on people, processes, and organizational design drive IT project success.

Early emphasis on tooling results in exactly what we would expect: Each project produces its own unique primary automation layer. These one-off pipelines become the new technical debt. Each need unique care, and best practices and solutions cannot be leveraged across pipelines.

And while one might assume that the increased levels of automation would result in more time for improvement and adaptation, these pipelines become ineffective over time because those who can provide the care and solutions needed are moved to other projects to facilitate learning, or leave the business altogether for new opportunities.

Ultimately, the ability to automate the path from creation through production deployment is heralded as a success and all involved claim their DevOps badges. Thus, companies often hastily proclaim DevOps victory having only implemented continuous integration and deployment technologies without having addressed the more critical underlying human elements of a DevOps program, which would empower them with the agility needed to adapt to the rapid and ever changing needs of their business over the long term. Which is the whole point of DevOps. Meanwhile, the pattern does not become pervasive to the organization and the organization is not moved closer to the goal of agility and adaptability.

Having now worked with dozens of businesses on DevOps adoption for the past seven years, we find the following to be the most common foundational issues:

Organization-wide goals are not sufficiently defined or are misaligned.

DevOps journeys often start with a single ambitious and motivated team. These teams attempt to engage the rest of the business, but often find the rest of the business to be non-responsive, usually as a result of unclear or misaligned goals. In short, the current organizational configuration or strategy are not driving shared accountability and, hence, represents a considerable hurdle to success. Additionally, in Accelerate, the authors put forth the vision of a “high-performance software delivery and operations” organization. This is an audacious, long-term goal. Businesses starting their DevOps journey need more succinct near-term goals so they can properly align their metrics and targets of their efforts.

Businesses have not baselined their current state.

We can all do better, but many businesses cannot differentiate between perceived issues and real issues. Hence, DevOps becomes the answer to a problem that doesn’t exist and, thus, leads to disappointing results.

Ignoring the human-side of IT change.

Business problems are the calculus of individual employee problems. To address business problems, and to deliver the perfect product or service, we must start with the individual in mind, which is often a huge culture shift, running counter to command and control and technology-first organizations. Encouraging calculated risk taking and experimentation is another huge hurdle. These are people-centric challenges that CI/CD pipelines don’t solve. 

Vanity improvements while root cause issues persist.

Are you addressing a root cause, or just a symptom? If you address symptoms, you are likely to feel dissatisfied with DevOps, but only because you have not actually implemented DevOps.

Focusing on DevOps technology rather than DevOps outcomes.

Most businesses are starting their DevOps efforts focused on tooling and continuous deployment pipeline technologies. This produces one-off, unintegrated solutions resulting in multiple pipelines developed along project or divisional boundaries. If the localized pipeline works, the business has only succeeded in shifting costs from promoting software into production to pipeline maintenance, while the human-centric flow improvements that DevOps produces remain viscous. In this case, the business has spent money, implemented a new technology, but failed to deliver an ROI that would justify the project.

With these in focus, it becomes clear that businesses are having difficulty adopting and scaling DevOps because it’s a multi-layered, human-centric, technology-enabled endeavor that is instead approached through a singular-layer, technology-centric lens. Moreover, the layers are not clearly defined in a way that enables businesses to design an effective strategy given their current skill makeup and organization configuration.

As an example, consider this: A business hires individuals that have a specific skill set and provide a specific function for the business. These individuals will still be doing these same jobs with the same skills tomorrow. Even if you reconfigure the entire organization, they will just be doing it in a different group, maybe for a different manager. A successful DevOps adoption must recognize this reality from the start. That is, you can reconfigure the seats on the bus, but that probably won’t make the bus go faster.

If you want the bus to go faster, you may consider upgrading the engine, which would likely require training for the person maintaining your current engine, or, more unfavorably, you may need to replace them with someone already well-versed in maintaining the new engine. Instead of replacing them, you may decide not to upgrade the engine, instead opting to keep the bus running as-is with the same team as a higher priority over going faster. Not only is this suboptimal for your team, but others in your company depending on you may believe your decision impedes with their goals to make the bus go faster.

DevOps: Ten Years Forward

Before we explore ways of simplifying DevOps adoption, it is helpful to look at how adoption now will affect our ability to adaptable and agile in the future. As we see it, DevOps is just a pitstop on the way to a much more important milestone for businesses. It’s an early stage development that enables complete management of complex ecosystems of software.

The ultimate goal of DevOps is to be able to rapidly release software into production so that we can focus on making changes as often as needed, without having to worry so much about the complex ecosystem we are deploying into. This allows us to introduce change to systems quickly and safely while also affording us the opportunity to easily measure the impact of each change before introducing the next. Change and adaptation become easier.

Embodied in DevOps are the principles of sustainability, speed, quality, measurement, repeatability, and resiliency. It is a critical foundation to another trend that is simultaneously occurring that embodies microservices, event subsystems, sensors, triggers, and actuators. Software is evolving to mirror the real world (e.g., Digital Twin).

If we cannot make changes to the complex ecosystem with a high-degree of confidence that we will not disrupt it, or that our changes can easily be undone, returning the ecosystem to a healthy condition, then we cannot reach this milestone. And this milestone is where businesses will become most adaptable to the conditions in which they supply their products and services.

Another point of consideration is that most mid- and large-sized enterprises have considerable investment in software that is monolithic and requires conservative approaches to modification.

It is likely that over time, the core business functions provided by this software will become smaller. These smaller packages will then be connected by a communications mesh that sends messages between “atomic” packages to complete a task, similar to how brain cells are connected by axons and dendrites as the message-mesh network. If a bad actor is introduced into the mesh (consider a tumor’s impact on the brain), there will be a high likelihood of failure. If the actor is small and isolated, it will be easier to restore full functionality, quickly.

Hence, DevOps is not about getting faster today, it’s about shaping the nature of the business to be adaptable tomorrow. It is foundational. Taking this into consideration, we put forth the following approach to DevOps adoption.      

DevOps GOLD: A Template for Enterprise DevOps Adoption

You are probably wondering, “Ok, so what the heck do I do about it?”

DevOps GOLD (Figure 1) provides a systematic framework for thinking through the various drivers of successful DevOps implementations. It recognizes that DevOps adoption is comprised of multiple layers containing tasks/outcomes that can happen in serial or parallel. GOLD also recognizes that DevOps adoption must be considered through multiple lenses within the organization, each with its own incentives for success.

Figure 1: DevOps GOLD- Source: JP Morgenthal

The items aligned to each domain of GOLD are examples, not a complete list of all the considerations that a business will undertake in adopting DevOps within that domain, but it does help to formulate a pattern of the way to organize a DevOps adoption approach within the business. Let’s explore how GOLD can be used to better help an organization increase their likelihood of success with DevOps adoption.

DevOps success must start with a clear understanding and statement of the goals (G), as these align our Logistics (L) and will identify the appropriate leaders in the Organization (O) to engage. Additionally, goals cannot be abstract or too large, they must be specific, such as “we desire to reduce post-deployment failure to 0%” or “we desire to decrease the time it takes to bring a new capability to market to four weeks or less”, and should be attainable in the near term (3-6 months). Goals must also be tied to business outcomes rather than solution or task focused.

Finally, once we have our G, O, and L, we can assess our Devices (D) relative to the mission. By “devices”, we mean the capabilities or enablers needed to deliver the goals. Devices includes technologies, products, methodologies, and processes. Aligning everyone on the G, O, and L makes coalescing on a common set of Devices much easier.

Another way to view GOLD is as answers the following questions:

• What do we want to achieve?
• Who is going to lead and who is going to execute the necessary activities?
•  How are we going to get from current state to goal state?
• What tools do we need to help us transition and operate in the goal state?

While these can be answered on a micro level (e.g. a single project) business agility afforded by shifting to DevOps is only likely to happen if these questions are answered at a macro level. Specifically, we see GOLD as being able to address the earlier stated hurdles to adoption in the following ways:

Organization-wide goals are not sufficiently defined or are misaligned.

GOLD starts by stating the business’ Goals both clearly and succinctly so that they can be agreed upon by the business as a whole and so that everyone understand the priorities.

Businesses have not baselined their current state.

By performing value-stream mapping and specifying the Logistics needed to achieve your goals businesses can gain insight into the challenges to achieving their goals and start to identify the real issues that need to be addressed.

Ignoring the human-side of IT change.

The Organization track in GOLD requires a focus on the organizational structures and policies that are needed to achieve the stated goals. This includes defining the environment most conducive to success and the recommended changes required to implement.

Vanity improvements while root cause issues persist.

The Logistics track helps quantify if the program is on track and leading to the stated goals. Vanity improvements without addressing underlying causes will not move the needle in a positive direction.

Focusing on DevOps technology rather than DevOps outcomes.

GOLD is a holistic program that helps businesses to address multiple layers of DevOps adoption requirements and challenges approaches that lead with technology-centric change.

A whole book could be written regarding the nuances, strategies, and details of how to leverage the GOLD approach for successful DevOps adoption, but the purpose of including it here was to quickly illustrate DevOps as a multilayered approach that requires commitment across the organization to become more adaptable to changes to external forces by starting with goals that allow the business to grow into the next phase of existence, which is complex ecosystem management driven by software.

Conclusion

Once businesses properly identify the long-term goals afforded them by adopting and maturing DevOps concepts in their own business, they will find it easier to find support within the organization and suffer far less resistance. Today, many outside of IT have no clue what DevOps is or why it is important. However, we do think most outside of IT would agree that software is increasingly driving and affecting how business is conducted, and they see the impact of changes and the associated risks that come with this paradigm shift.

For many businesses DevOps is strategic to the degree that they believe it holds some promise of squeezing more out of IT. However, it should be considered a foundational change toward being able to support a complex software ecosystem that will enable them to rapidly adapt to threats and opportunities in a way that minimizes downside risk.

About the Authors

JP Morgenthal

JP Morgenthal is CTO, Application Services and Distinguished Technologist for DXC. He is an internationally renowned thought leader in the areas of digital transformation, modernization, integration, and cloud computing. JP has served in executive roles within major software companies and technology startups. Areas of expertise include software strategy & architecture, application development, infrastructure and operations, DevOps, microservices and IoT. He routinely advises C-level executives on the best ways to use technology to derive business value. JP is a published author with four trade publications with his most recent being “Cloud Computing: Assessing the Risks”. JP holds both a Masters and Bachelors of Science in Computer Science from Hofstra University.

James Moscariello

James is a Digital Transformation Principal with DXC Technology. He is a determined, adaptive, and disciplined leader with an ability to learn highly technical material quickly. He excels at creating cultures of innovation and bringing teams of experts together to produce creative, high-value solutions to persnickety problems. He is comfortable in both the business strategy and the detailed execution levels of a discussion and knows how and when to move between the two in order to solve a problem.