DevOps celebrated its 10th anniversary in 2018, which is a long enough life cycle in the tech industry. Despite the relative maturity of DevOps, the DevOps philosophy still shuns even the most well-known and resourced organizations. A shocking Gartner report shows that 75% of DevOps projects fail to achieve their goals.
Why is DevOps failing at such a high rate? What are the common challenges that organizations face in implementing DevOps concepts? How can these challenges be overcome?
This article addresses these issues and provides enterprises with replicable strategies to improve the success of DevOps initiatives.
1. Resources are incorrectly configured
Resource allocation is a challenge for DevOps. Integrating development and operations teams alone does not produce an effective DevOps team. A significant number of DevOps teams lack subject matter experts, which severely affects the team’s ability to deliver on the promise of DevOps.
First, generalists in different techniques such as application development, optimization, and monitoring are not as effective as specialists. This wastes valuable time and ultimately slows down DevOps delivery.
Furthermore, DevOps teams work best when they minimize unscheduled work. Without dedicated resources to work on specific DevOps problems, teams are forced to assign complex problems to non-subject matter experts. This will disrupt their work schedule and make the team inefficient. More importantly, the increasing workload of this type of talent will lead to employee burnout and potentially derail the entire DevOps program.
DevOps speeds up feature releases, updates, and time-to-market only when there is a dedicated person to handle the problem. As a result, organizations must identify key application technologies and development processes that can be optimized through DevOps and assign specialized skills to these specific areas.
Optimal resource allocation is critical to the success of a DevOps plan.
2. Misplaced responsibilities
DevOps brings together teams with disparate goals to work in an “unstable” environment. Developers mainly care about innovation, stable operations teams, QA teams that perform perfectly, and so on. Of course, there is bound to be friction and conflict between these teams.
To make matters worse, the goals, responsibilities, and priorities of a DevOps team are often not clearly defined at the top. That leaves a lot of room for ambiguity. Teams that are used to working in isolated islands without worrying about dependencies regress to their old ways of working, negating all efforts to achieve seamless collaboration.
Getting the team to think outside the box is the biggest challenge before changing the leader. Therefore, DevOps works best when teams are made up of interdisciplinary resources. Operations-minded developers who are not shy about stepping out of their comfort zone often are needed to lead DevOps initiatives to success.
Organizations often overcome these challenges by clearly describing DevOps goals, priorities, and responsibilities. More importantly, they assign full responsibility for the success of DevOps tasks. Each team member is responsible for the success of DevOps’ end-to-end tasks. When their individual performance is measured by the overall success of the team, the silos automatically disintegrate and collaboration multiplies rapidly.
3. Process fragmentation
Not many DevOps leaders realize, or at least realize, that DevOps is very fragmented. Despite its maturity, DevOps is not particularly suited to SMB software development and delivery models. DevOps has long been primarily a large enterprise initiative. As a result, small and medium-sized businesses that engage with DevOps find themselves in a bind.
DevOps works by automating most of the tasks involved in the software development life cycle. However, there is no tool, process, or resource that can achieve this. DevOps teams must use different tools to automate different aspects of their operations. There are great tools for automating components such as continuous integration, infrastructure provisioning, testing, source control, and so on. However, these tools are not integrated with each other (of course, they can be integrated with tools, such as ZTF, which Bridges the gap between ZTF and Jenkins throughout the DevOps continuous integration, continuous testing, and continuous deployment phases of the DevOps life cycle).
Getting these different tools to communicate with each other requires a lot of resources that most organizations are unable or willing to allocate. For this reason, DevOps teams are often forced to use limited automation capabilities, which is the opposite of DevOps.
Efficient DevOps teams divide their time between executing tasks and automating them. Without automation, transactional work builds up, resulting in employee burnout, process delays, deteriorating responsiveness, and poor delivery.
Enterprises can avoid these problems by developing a clear DevOps strategy that specifies the organization’s DevOps goals, identifies processes that can be automated, and deploys resources to achieve those goals. These goals should be matched with resource allocation, and this realistic approach to defragmentation will help businesses simplify and automate processes that are important to them.
4. Lack of proper metrics
The lack of appropriate metrics is both a process challenge and a people challenge. Kpis and metrics go a long way in communicating your organization’s priorities and expectations to the DevOps team. As discussed earlier, there is an ongoing conflict between stability and deployment time in DevOps teams. Should we rush delivery at the expense of stability, or should we focus on stability and delay delivery? How did you start prioritizing one goal over another?
Metrics provide clear and precise direction for teams to prioritize different goals. While the value of these metrics may vary from business to business, the metrics themselves are universally relevant to all DevOps teams. Here are some metrics that organizations must define when communicating DevOps goals to their teams:
● Deployment frequency ● Deployment time ● Change failure rate ● Automatic test pass rate ● Number of faults after each release ● Defect escape rate ● Detection time expired ● Function usage ● End user experience ● Service impact ● Deployment failure
5. Cultural shift
Resistance to change will be the biggest obstacle to DevOps’ transformation. DevOps attempts to shift control from separate teams and their leaders to a single, multi-departmental organization within an organization. Naturally, such attempts can be interpreted as an erosion of decision-making power.
Further, it’s not all about control. The leadership role of DevOps is quite different from the traditional IT role. In general, IT leaders must have the expertise to mentor, support, and advise employees on a variety of technologies. In a DevOps environment, this is not the case. DevOps employees work in an unstable and fast-moving environment. Mistakes are common, and the consequences can be catastrophic. It’s easy to understand why employees are worried about the DevOps process.
Thus, the primary role of leadership is to create nurturing conditions that give employees greater freedom and protect them from the frustrations of rapid experimentation. In addition, the leader’s job must be focused on identifying successful patterns for DevOps and replicating those patterns to extend transformation across the organization.
A top-down approach attempts to redefine the role of leadership, give DevOps teams more freedom to experiment, and ensure their stability, which is critical to overcoming cultural inertia.
“Cultural change cannot be implemented — stakeholders across the organization must be united in supporting the necessary cultural changes required for successful DevOps adoption. It includes executives and leaders within different groups. It’s not just technical adoption. To succeed, business, operations, IT, finance and others must commit and build trust.”
Ian Willoughby, Vice President and Chief Architect, Cloud Solutions
6. DevOps cannot be extended
Too often, early DevOps successes turn into failures. The best-performing DevOps teams are swamped with more projects, which can quickly become a bottleneck for project delivery, not to mention the increased stress and decreased productivity that comes with it.
One obvious way to solve this problem is to expand the DevOps team. That, however, is easier said than done. DevOps specialists require very different skills than developers or engineers, making them difficult and expensive to hire.
Some organizations overcome this challenge by embedding a DevOps specialist on each development team. Their role is to streamline their teams’ delivery chains while coordinating with DevOps specialists in other departments. However, this approach often breeds inconsistencies and collaboration among teams. One way to address these new issues is to borrow from open source practices and use an internal source code approach.
Teams must have powerful collaboration tools that enable them to code, publish, and collaborate from anywhere in the world. Finally, replace the traditional project-centric approach with a robust, decentralized “product-centric” delivery model.
“Devops-driven change needs to have a compelling purpose first. Then, successfully measuring change requires communication, collaboration and commitment across the organization.”
Qasim Khan, Senior Vice President – Business Information Officer, Bank of America
7. Security cannot be merged
On the surface, DevOps and security seem to be in complete conflict. While DevOps is all about speed and continuous delivery, security emphasizes extensive testing and fail-safe. However, businesses are slowly realizing that DevOps integrated with security can help them patch vulnerabilities, release updates, and respond to cyber threats faster than ever before.
Currently, DevOps faces three obstacles in integrating security into its process: slow development, endless security standards, and threats to visibility.
Finally, threat visibility can be improved by making security data available to all team members and making it easy for them to report. SIEM dashboards tailored to the roles and responsibilities of each team member can provide threat visibility to DevOps teams to a large extent. To be effective, a reward system based on shared performance goals can be established.
Every organization’s DevOps plan will encounter complex obstacles specific to that organization. However, focusing on the cooperation and stability of team members can ensure success by reducing internal resistance and turning potential sources of inertia into changes in leadership.