04 The Balance of DevOps, Have You Found The Implementation Roadmap for DevOps #

Hello, I’m Shi Xuefeng. Today, let’s talk about the implementation roadmap for DevOps.

In the business field, there is a classic book called “Crossing the Chasm,” which proposes the “Technology Adoption Life Cycle Law.” For the high-tech industry, its importance is comparable to Moore’s Law.

In simple terms, this law describes the five stages a new technology goes through from birth to mass adoption. These five stages correspond to the categories of innovators, early adopters, early majority, late majority, and laggards. This law indicates that the development of technology is not linear and requires a period of incubation before crossing the chasm to be accepted by the masses and become mainstream in the industry.

Of course, the so-called new technology of DevOps is not destined to have a smooth landing within the enterprise. So, in this case, have you found the implementation roadmap for DevOps?

Since the first DevOpsDays conference was held in China in 2017, DevOps has officially entered the fast lane of development in the country. From a relatively unknown new technology concept to its vigorous development in various industries, with the intense collision of various ideas and practices, the principles and values of DevOps have become deeply ingrained.

From this perspective, DevOps has successfully crossed the chasm of technological development and entered the early majority phase from the early adopter stage. This also means that more and more companies are starting to try DevOps.

At the end of 2017, a set of survey data from Forrester showed that nearly 50% of the surveyed companies stated that they have introduced and are implementing DevOps, 30% of the companies expressed intention and plans to start this work, and only 1% showed no interest in DevOps at all. It can be said that 2018 is the year when enterprises truly land DevOps.

However, just like when you are heading to an unknown destination, you need navigation to help you plan the route, provide real-time positioning, and prompt you in case of unexpected situations to reconsider the route, enterprises also face similar problems in implementing DevOps. The enterprise itself has difficulty determining the current status of DevOps, objectively assessing the level of DevOps-related capabilities, identifying the biggest bottlenecks faced at present, and having expectations for phased achievements in implementing DevOps…

Looking back at the development history of the entire IT industry, new ideas and new technologies always go hand in hand with standardized models and frameworks.

I believe that the maturity of any technology is marked by the stability of its models and frameworks. Because when technology crosses the initial chasm and faces the masses, it is difficult to achieve large-scale promotion and healthy development without a set of models and frameworks to help the masses keep up with the pace and find the right direction.

For example, in the field of software development, the CMMI model (Capability Maturity Model Integration) and ITIL model in the operation and maintenance industry have long been renowned in their respective fields. They have even been regarded as guidelines and behavioral standards by practitioners in various fields, becoming a benchmark for measuring capabilities.

I have participated in a CMMI rating project in a large telecommunications equipment company in China before. Even when there was great business pressure, all departments would prioritize support for anything related to the rating project. This shows that the entire company attaches great importance to this certification and rating project.

So, the question is, in the process of DevOps continuously maturing as a new idea and technology, are there similar models and frameworks that can guide the transformational efforts of enterprises in implementing DevOps?

The answer is yes, and there are many. As long as you search for keywords like DevOps framework and model on Google, you will see a lot of results. Especially some well-known foreign companies, such as Atlassian, CloudBees, CA, etc., almost all have their own models and frameworks to help enterprises identify their current DevOps capabilities and improve them.

I have participated in the development of a DevOps capability maturity model led by the China Academy of Information and Communications Technology under the Ministry of Industry and Information Technology. This model covers all aspects of software delivery, including agile development management, continuous delivery, and technical operations. At the same time, it also includes content that corresponds to application architecture design, security, and organizational structure.

Moreover, for enterprises developing DevOps tools, the system and tool models are more biased towards platform capabilities and can be slightly organized to be used as platform requirements input to the development team. Currently, many companies are practicing DevOps based on this model. The following graph shows the overall framework of this model. If you are promoting the implementation of DevOps within your enterprise, you can refer to it.

Steps and Principles #

With so many models and frameworks in the industry, can we just choose one and follow it directly? Of course not.

After all, the current situation, competitive pressures, and market competition vary among different enterprises. The organizational structure, strategic goals, R&D capabilities, and resource investments also differ significantly. There is no standardized path that everyone can follow. For example, in the financial industry, it is difficult for a large-scale bank with tens of thousands of employees to compete on the same stage as a small commercial bank with hundreds of employees.

Therefore, when referring to models and frameworks, I believe we should try to follow the following steps and principles:

1. Identify Gaps

From the perspective of “the way, method, technique, and tool,” the maturity models and frameworks of DevOps are at the “method” level. They represent a complete set of methods for implementing DevOps, acting as a strategic map. The most important thing is to establish a comprehensive understanding of the areas and capabilities involved in implementing DevOps.

By benchmarking against models and frameworks, we can quickly identify the weaknesses and gaps currently faced by the enterprise and establish a baseline of the current capabilities state. This baseline can be used to compare the effects achieved after improvements.

2. Set Goals

The core of digital transformation is to optimize software delivery efficiency. By benchmarking against models and frameworks, enterprises need to clarify what the biggest bottleneck is that affects the further improvement of software delivery efficiency, what the current major pain points are, which capabilities improvement will help the enterprise achieve its predetermined goals, etc. At the same time, based on the current situation of the enterprise, it is necessary to identify the results of benchmarking gaps and identify which ones are truly effective and which ones can be quickly filled through platform capabilities.

For example, for a company that provides CRM software, although containerized deployment has many advantages in areas such as environment management and deployment releases, it is not the current core bottleneck that urgently needs to be solved. Therefore, it should not be included in the improvement list in the near future.

Through a situation analysis, enterprises can focus limited resources on high-priority tasks, identify improvement goals, and the expected effects to be achieved after the improvements. These effects should be objective and quantifiable, such as reducing the environment preparation time by 50%.

3. Focus on Capabilities

Models and frameworks are a collection of capabilities and practices, represented by the “technique” level in the way, method, technique, and tool framework. Therefore, when applying models, the focus should be on the capabilities themselves, rather than purely comparing numbers and results.

For example, the case of Amazon deploying 23,000 times a day is frequently mentioned as an example. This number is indeed amazing, but if we think about it, do all enterprises need to achieve such a high deployment frequency? For example, a client application can be built in a few minutes, but when it comes to building large-scale system software, it may take several hours. So, how long does it take to meet the standards?

We cannot only focus on the achievements of these star companies and ignore our own needs. Therefore, the correct approach is to identify the capabilities needed based on the set goals, introduce practices that match these capabilities, continuously strengthen the practices, and thereby improve the capabilities themselves.

4. Continuous Improvement

Models and frameworks themselves are not fixed; they need continuous iteration and updates, just like DevOps. In addition, as can be seen from this year’s DevOps State of the Report, the proportion of elite-level organizations has quickly increased from 7% in 2018 to 20% in 2019, indicating that the overall industry capabilities are continuously improving. This puts higher demands on the software delivery capabilities of enterprises.

Well, these are the steps and principles I have summarized for enterprises to apply DevOps capability models and frameworks. As a systematic engineering, DevOps also requires a comprehensive implementation method. Only by combining methods, practices, and tools and promoting them comprehensively can we achieve results.

To help you better understand the implementation process of DevOps, I have posted a classic Deployment Gravity diagram.

As can be seen, when the frequency of software releases evolves from once every 100 days to 100 times a day, adjustments need to be made to branch strategies, testing capabilities, software architecture, release strategies, infrastructure capabilities, and database capabilities. For example, the branch strategy needs to shift from long-term branches to feature-based trunk development mode, and the architecture needs to continuously decouple and become more service-oriented. In actual applications, enterprises may involve even more areas because these are just technical issues, and organizational culture is also indispensable.

Case Study #

Finally, I would like to share a case study of a client I previously worked with to improve their operations.

When I first started communicating with this client, they were all over the place and struggled to stay focused. Due to strict organizational boundaries, whenever we discussed a particular aspect, they would bring in the corresponding staff to talk about it. It was only after hearing from everyone involved that we could piece together the complete picture of the project. I believe this is not an isolated case and that many companies face similar challenges.

Therefore, we introduced the capability maturity model and conducted a comprehensive assessment of the client’s existing capabilities based on the model. We identified over 100 problems and more than 40 gaps. The chart below is a summary of the overall assessment, although some data has been processed.

Next, I communicated with the client about these identified gaps and focused on setting improvement objectives and specific action items for the initial phase. During these discussions, I realized that due to the uniqueness of the client’s industry or certain objective constraints, some issues were not immediate priorities for improvement. As a result, we narrowed down the improvement items to 30, identified their interdependencies, and set expected targets. For example, the client previously took about two weeks to set up an environment, and to enhance overall delivery capability, we aimed to complete this process within one week.

Once we had the improvement objectives and expected outcomes, we analyzed the key capabilities that constrained the efficiency of delivery. Continuing with the previous example, the core issues were the complexity of the environment setup process and the lengthy approval process. The existing setup process involved the development team preparing a deployment requirements document that detailed the necessary environment and version information. However, this document was always outdated because the software functionality relied on constantly updated environments, yet no one maintained the document. This is why people often say that documents become obsolete.

After identifying the core capability as “automated environment management,” the team decided to adopt infrastructure as code practices to address this issue. I will explain the specific technical details later, but for now, you only need to know that by transforming the environment configuration instructions documented into configurations maintained in a dedicated version control system, the initialization of the base environment could be completed within minutes.

Improving the approval process, on the other hand, was a non-technical issue related to workflows and organizational aspects. Once everyone realized that these approvals to some extent hindered the increase in release frequency, they proactively improved the existing process. They implemented different levels of approval for different environments, enabling completion of any single approval request within a day.

Through these optimizations, the time required for environment preparation significantly reduced from the initial two weeks to two days, resulting in a noticeable improvement. Subsequently, the team identified new gaps, set new targets and expected outcomes, and proactively addressed them, entering a stage of continuous improvement.

From this, we can see that the practice of DevOps and the capability framework model complement each other. The practice of capabilities defines the roadmap and priority sequence for DevOps implementation, while the capability model guides the implementation of various supporting methods. The practice of capabilities always aligns with the value delivery direction of the enterprise, and the accumulation and sedimentation of the capability model enables the enterprise to handle various future challenges with ease.

Regarding ITIL and CMMI, these legacy frameworks are also evolving alongside the DevOps trend. For example, ITIL, represented by its focus on process compliance, recently released its fourth version. Let’s take a look at some guiding principles from ITIL V4, including: “Focus on value, focus on the current state, interactive processes and feedback, collaboration and visualization, automation and continuous optimization, simplicity principles, and focus on practice.”

Doesn’t it sound a bit like DevOps? It is worth noting that DevOps will not completely overturn ITIL; it will only optimize existing processes as much as possible while ensuring compliance. DevOps injects methods of flow, feedback, and continuous learning and improvement into ITIL from a holistic perspective to continuously optimize the enterprise’s value delivery process.

Summary #

In summary, today I introduced to you the gaps that the development of new technologies and new ideas needs to face, and the capability models and frameworks are indicators of the maturity of these technologies and ideas. The same applies to DevOps. When facing numerous models and frameworks, enterprises need to base themselves on their own situations, identify differences, set goals, focus on capabilities, and continuously improve the efficiency of software development and delivery. The implementation of DevOps requires a comprehensive implementation framework to achieve all-round capability improvement through the interaction of models, methods, capabilities, and practices.

So far, we have provided an overall introduction to the basic concepts, core values, implementation methods, and roadmaps of DevOps, helping you establish a macro-level concept of DevOps. Next, we will delve into the details, especially for each core practice. I will introduce the underlying concepts, implementation steps, and the required capability models, and guide you step by step in implementing DevOps.

Thought-provoking Question #

Finally, here’s a thought-provoking question for you: What do you think is the relationship between CMMI, ITIL, and DevOps? How can enterprises balance multiple framework models?

Feel free to share your thoughts and answers in the comments section. Let’s discuss and learn together. If you found this article helpful, please feel free to share it with your friends.