Seven Main Obstacles to Adopting DevOps

DevOps celebrated its 10th anniversary in 2018, a long enough life cycle in the technology industry. Although DevOps is relatively mature, DevOps philosophy is still avoiding even the best-known and resourceful organizations. A shocking Gartner report shows that 75% of DevOps projects fail to achieve their goals.

Why is the failure rate of DevOps so high? What are the common challenges faced by the organization when implementing the DevOps concept? How to overcome these challenges?

This article will address these issues and provide replicable strategies for companies to improve the success rate of their DevOps plans.

1. Non-standard Resource Allocation

Resource allocation is a big challenge in DevOps. Merely integrating the development and operation and maintenance team can not produce an efficient DevOps team. A disproportionately large number of DevOps teams lack subject matter experts, which severely impacts the team's ability to deliver on the promise of DevOps.

First, generalists engaged in different technologies such as application development, optimization, and monitoring will not be as efficient as experts. This will waste valuable time and eventually slow down the delivery of DevOps.

In addition, DevOps teams are most productive when they minimize unplanned work. Without dedicated resources to deal with specific DevOps issues, the team is forced to assign complex problems to non-subject matter experts. This will undermine their work plan and make the whole group inefficient. More importantly, the increasing workload of such talents will lead to the exhaustion of employees and may derail the entire DevOps plan.

DevOps speeds up release, update, and release times only if a dedicated team of people handles the issues. As a result, enterprises must identify key application technologies and development processes optimized through DevOps and assign specialized skill talents to specific areas.

Optimal resource allocation is critical to the success of the DevOps program.

2. Dislocation of Responsibility

DevOps brings together teams with different goals and works in an "unstable" environment. Developers are mainly concerned about innovation, stable operation and maintenance team, QA team with perfect performance, etc. Of course, there must be friction and conflict between these teams.

What's worse, senior management often does not clearly define the DevOps team's goals, responsibilities, and priorities. This leaves a lot of room for ambiguity. Teams accustomed to working in silos without worrying about dependencies will revert to the original way of working, negating all efforts to achieve seamless collaboration.

Before changing leaders, getting the team out of the mindset is the biggest challenge. Therefore, DevOps works best when the group is composed of interdisciplinary resources. Developers with operation and maintenance thinking are not ashamed to often go out of their comfort zone. This is an urgent need to lead DevOps to success.

Organizations often overcome these challenges by clearly describing DevOps's objectives, priorities, and responsibilities. More importantly, they assigned full responsibility for the success of the DevOps mission. Each team member is responsible for the success of the DevOps end-to-end task. When the team's overall success measures their performance, the silos automatically decompose, and collaboration increases rapidly.

Source：graph

3. Process Fragmentation

Not many DevOps leaders realize, or at least realize, that DevOps is very fragmented. Although DevOps has matured, it is not suitable for SMB software development and delivery models. DevOps has long been primarily a significant enterprise initiative. For this reason, small and medium-sized businesses engaging with DevOps find themselves in a bind.

DevOps works by automating most of the tasks involved in the software development lifecycle. However, there is no single tool, process, or resource to achieve this. DevOps teams must use different tools to automate different aspects of their operations. There are great tools to automate individual components like continuous integration, infrastructure provisioning, testing, source control, and more. However, these tools cannot be integrated (of course, they can also be integrated with tools, such as ZenTao ZTF, which bridges the gap between ZenTao and Jenkins, and runs through the DevOps life cycle of DevOps, such as continuous integration, continuous testing, and continuous deployment. ).

Making these different tools communicate with each other requires a lot of resources, which most organizations are unable or willing to allocate. For this reason, DevOps teams are often forced to use limited automation functions, which is the opposite of DevOps.

Efficient DevOps teams allocate time between tasks and automated tasks. Without automation, transactional work increases over time, which results in employee burnout, process delays, poor responsiveness, and poor delivery quality.

Enterprises can avoid these problems by developing a clear DevOps strategy, which specifies the organization's DevOps objectives, determines the processes that can be automated, and deploys resources to achieve these objectives. These goals should be matched with resource allocation. This realistic approach to defragmentation will help enterprises simplify and automate processes that are important to them.

4. Lack of Appropriate Metrics

The lack of appropriate metrics is both a process and a personnel challenge. The KPI and metrics have helped communicate the organization's priorities and expectations to the DevOps team. As discussed earlier, stability and deployment time remain in conflict with the DevOps team. Should delivery be rushed at the expense of stability or focus on delayed delivery? How did you start to prioritize one goal over another?

Indicators provide a clear and precise direction for the team to prioritize different goals. Although the value of these indicators may vary from business to business, these indicators themselves are generally relevant to all DevOps teams. The following are some indicators that enterprises must define when communicating Devops objectives to the group:

● deployment frequency

● deployment time

● change failure rate

● the automatic test pass rate

● number of faults after each release

● defect escape rate

● the time for detection is up

● function use

● end-user experience

● business impact

● deployment failure

5. Cultural transformation

Resistance to change will be the biggest obstacle to DevOps transformation. DevOps attempts to transfer control from a fragmented team and its principals to a single multi-departmental organization within the organization. Naturally, such an attempt can be interpreted as an erosion of decision-making power.

Furthermore, it’s not all about control. The leadership role in DevOps is very different from the traditional IT role. In general, IT leadership must have the professional skills to guide, support, and advise employees on various technical aspects. This is not the case in a DevOps environment. Employees in DevOps work in an unstable and fast-growing environment. Mistakes are common, and the consequences can be catastrophic. It’s easy to see why employees worry about the DevOps process.

Therefore, the primary role of leaders is to create training conditions, give employees a higher degree of freedom and protect them from the setbacks caused by rapid experiments. In addition, the leader's work must focus on identifying successful models of DevOps and replicating these models to expand the transformation throughout the organization.

A top-down approach tries to redefine the role of leadership, giving DevOps teams more experimental freedom and ensuring their stability, which is essential to overcoming cultural inertia.

"Cultural change cannot be implemented - stakeholders across the organization must unanimously support the necessary cultural change required for the successful adoption of DevOps. It includes executives and leaders in different groups. This is not just technical adoption. To succeed, business, operations, it, finance and others must commit and build trust."

Ian Willoughby, Vice President and Chief Architect of Cloud Solutions

6. Unable to Extend DevOps

Many times, the success of early DevOps programs often turns into failure. The best performing DevOps team is inundated by more projects, which will soon become a bottleneck in project delivery, not to mention the subsequent increase in pressure and decline in productivity.

An obvious way to solve this problem is to extend the DevOps team. However, it is easier to say and difficult to do.DevOps experts require skills from developers or engineers and are both difficult and expensive to hire.

Some organizations overcome this challenge by embedding a DevOps expert in each development team. Their responsibility is to simplify the delivery chain of their teams and coordinate with DevOps experts in other departments. However, this approach often breeds inconsistencies and collaboration problems between groups. One way to solve these new problems is to learn from open source practice and use an internal source code method.

Teams must have powerful collaboration tools that enable them to code, publish, and collaborate from anywhere in the world. Finally, we should replace the traditional "project-centered" approach with a robust and decentralized "product-centered" delivery model.

"DevOps driven change first requires a compelling purpose. Then, to successfully measure change, it requires communication, collaboration, and commitment throughout the organization."

Qasim Khan, Senior Vice President-Business Information Officer, Bank of America

7. Cannot merge the security

Source：graph 2

On the surface, DevOps and security seem in total conflict. At the core of DevOps are speed and continuous delivery, while security emphasizes a broad range of testing and error prevention. However, enterprises are realizing slowly that DevOps integrated with security can help them patch vulnerabilities, release updates, and deal with network threats faster than ever before.

DevOps now faces three hurdles in integrating security into its process: slow development, endless security standards, and the threat to visibility.

Finally, you can increase the visibility of threats by providing security data to all team members and making it easy for them to report. The Siem Dashboard, tailored to the roles and responsibilities of each team member, provides a significant degree of threat visibility for the DevOps team. The team can establish a reward system based on common performance objectives to make it effective.

Each organization's DevOps program encounters complex obstacles unique to that organization. However, focusing on the cooperation and stability of team members can reduce internal resistance and turn potential sources of inertia into changes to the leadership to ensure success.