Devops 3.0 Puts Management into Focus

As the world becomes fully digital, many global and national enterprises are at risk. There still are awkward behemoths whose customer service and internal communication fail to deliver constituent value in the digital domain. But, there is now a convergence between traditional devops and agile management which I call Devops 3.0. The question is, can this new merged management philosophy chart a better digital transformation course?

Devops 3.0 is important because it gives winning companies the power to dominate in the digital domain. To create this dominating Internet presence, corporate teams must align internal management practices with agile management techniques and devops tooling. To see how managing devops lets companies win in the digital domain here is a quick overview of devops history.

DevOps 1.0 – Breaking Barriers with Continuous Delivery

DevOps was originally conceived in 2007 to break through information technology (IT) organizational barriers. This stems from the nature of corporate IT. Companies need a working relationship between app production teams and in-house or contracted teams who maintain private data centers. These interfaces are fraught with friction and generate barriers to success, which include political battles and poor communication. The DevOps 1.0 era was launched by people who strove to obliterate the unnecessary barriers put up by both camps.

DevOps 1.0 was a success because it created new ways of working that went around traditional barriers. It improved the quality of communication and decision making between all project stakeholders.

Infrastructure as Code

DevOps 1.0 grew in power as cloud computing made it easier for a developer to spin up new IT infrastructure. In the early 2010’s, Docker accelerated DevOps 1.0 by creating deployment artifacts that behave like self-contained virtual machines. Today, Docker containers are the main artifact type generated by DevOps 1.0 build automation processes.  

Jenkins emerged as the first free open-source software (FOSS) implementation of a DevOps 1.0 command server in 2012. Jenkins uses web hooks and scripting agents that automatically compile and link source code into an artifact. Artifacts are then continuously delivered to a production environment. Jenkins is still a leading pipeline orchestration system and command server in 2021.

Jenkins-driven continuous delivery accelerated development, which enabled technology companies to update their cloud native apps faster. Companies delivered small changes to an app continuously. This allowed them to see how audiences reacted to small changes in an app. This allowed technology companies to use continuous delivery to learn more about the psychology of their users.

DevOps 1.0 emerged as a transformational force in the technology industry. Guided by its old motto of “Go fast and break things,” Facebook used continuous delivery to fine tune their products. Facebook, and other app developers, grew their markets by learning how to addict users to their app. They used continuous integration to experiment with small incremental changes to amplify desired user behavior.

DevOps 2.0 – Engineering Job Description

DevOps 1.0 as practiced by technology companies evolved into a new set of job functions that I call DevOps 2.0. This was done as the need for online system integration services spread globally throughout the 2010’s.

After seeing how Silicon Valley used DevOps 1.0 to dominate the Internet with innovative apps, big organizations around the world started using the same tools. DevOps 2.0 blossomed when corporate IT teams started using software used by Netflix, Uber, Airbnb, and Twitter. Eventually many organizations began to effectively copy how Silicon Valley delivered cloud native applications.

The increased interest in cloud native computing and DevOps 2.0 ignited an explosion of FOSS projects. This created new communities and companies to support pivotal projects like Jenkins, Apache Kafka, and Kubernetes. By the mid-2010’s enterprises had access to many of the cloud native goodies that Silicon Valley still uses to build and deliver technology products.

In 2021, most big enterprises now use bits and pieces of cloud native computing and DevOps 2.0 to improve their existing enterprise apps and delivery techniques. The demand for a “DevOps Engineer” that assembles the FOSS bits and pieces needed for a solution is stronger than ever.

It seems like the original idea of DevOps 1.0, which was to give developers continuous delivery tools, has changed. Today, most corporate DevOps Engineers no longer perform any coding or development activities. Instead, they provide a service within app production teams by using implementation skills in cloud native computing.

Devops 3.0: Managing the Transformation

According to a July 6, 2021, webcast, RBC Wealth Management, one of Salesforce UK’s favorite reference accounts, has 26 heterogeneous systems integrated into a Salesforce 360 customer data platform. This Salesforce implementation gives 5,000 employees of RBC Wealth Management a real time, personalized, task-specific, and up-to-date view of customers!

We have all seen these wonderful Salesforce demos. It continues to an employee describing how they “easily” integrated information from multiple enterprise systems. A single Lightning page delights us with API integrations via MuleSoft. And, ultimately this shows how the company delivers value and delights a customer.

Complex management challenges like RBC Wealth Management confront more Salesforce customers everyday. Chief among their concerns is the ability to align IT and Salesforce platform activity with delivering organizational value. Organizations need better ways to manage and measure app production teams that ensure that platform, personnel, nd partner investments are properly plotted.

To chart the way forward, organizations need a unified view of devops and agile which I call Devops 3.0.

Agile Has Won

The pandemic has inspired quick adoption of new management practices. Many these are centered around the Japanese Kanban board and process flow management practices. The shortcut term “agile management” now descrbes this management philosophy.

That is where Devops 3.0 comes in. It expands how to think about agile app program management from the project to the enterprise level.

Objectives and Key Results

In the last decade, agile management has demolished some traditional corporate structures because agile doesn’t respect traditional hierarchical communication structures. Agile organizations create ad hoc and permanent teams to deliver Objectives and Key Results (OKR). This methodology finds its roots in the “management by objective” techniques that started in Japanese manufacturing factories in the 1960’s.

Based on scientific methodologies, OKR-driven management seeks to create measurable outputs in the process that achieves a key objective, which is also measurable. For example, Salesforce app production projects could have an OKR like “Deliver a field service app that improves service rep response times by 30%.”

Just like how the term “devops” is now an overly generic way to refer to enterprise application delivery, the term “agile” has evolved to represent the management techniques inspired by the Kanban board and other OKR-related topics.

The general concept of “devops” and “agile” is becoming somewhat blended as well. Devops and agile share the philosophies of continuous delivery and user testing, enhanced communication, and advanced project management tools.

Devops 3.0 Delivers Value Streams

Orchestrating solutions like RBC Wealth Management’s requires a meta level of organization to project management. To meet big-company management requirements, more Japanese management techniques related to Kanban have emerged. These techniques are called value stream mapping and value stream management.

Focusing on process analysis, Value stream mapping starts at the app production team level. It assesses the way elements within a complex project interact to achieve an operational objective.

The value stream mapping process generates a graphical product called the value stream map. Planners create maps that describe current and desired value stream maps. Doing so provides a guide for process improvement. Also, these diagrams often seem a little strange. It is because they retain the same iconography and symbols used in the original Toyota value stream maps. I hope that we see more adaptations of these symbols for digital app production teams.

Value stream management is the “devops automation harness,” or the tools and practices that measure the ongoing dynamics of individual value streams. To become more widespread, value stream mapping and management tools need to be integrated directly into a Devops 3.0 platform.

Practical Agile Strategy

The concept behind Devops 3.0 is popular because it aims to give app production teams practical tools that deliver organizational value. Now, with value stream maps and the automation harness of value stream management, teams now have the technology to measure if they are going in the right direction. This creates a virtuous feedback cycle that drives organizations to maximize value for their constituencies.

Practicing Devops 3.0 is exciting because the tools and techniques to guide multiple app production teams towards maximizing organizational value are now available. Indeed, some of the Top 5 Salesforce Devops Vendors now offer value stream management capabilities, and some of the leading agile management vendors are crossing over to Salesforce.

The Build vs. Buy Dilemma Continues

For most Salesforce platform owners, sadly, there is no easy road to attaining the benefits of Devops 3.0. In fact, any practical path to integrating management practices with enterprise app delivery is a long bumpy road, filled with many potholes and detours along the way. Do not underestimate the complexity of undertaking any technical or managerial renovation program.

Here are some of the risk factors to consider. Do you depend on a single vendor to deliver a full stack solution? Or do you want to build your own Devops 3.0 solution from the bottom up? Can a consultant help you to develop and staff new technical roles? Be wary of a consultant who loves just one of the Top 5 Salesforce devops vendors.

Since we are talking about management, implementing Devops 3.0 has additional risks which often get to the heart of organizational culture. Including, how do you create organizational alignment with your efforts? Do you have the right executive buy offs? Can you be the one to shatter corporate barriers?

It is time for corporate leaders to take steps that align teams with digital transformation efforts. Here are some steps to consider:

• Make process observability a key corporate value.
• Seek to implement governance by getting better metrics from the processes that deliver value for your constituencies.
• Set up a Center of Excellence or Agile Management Center to distribute common Devops 3.0 practices.