Top 5 DevOps Challenges & Solutions Part 2: Focus on Technology Leadership
People, Process & Technology
November 09, 2016

Jeanne Morain
iSpeak Cloud

Start with Top 5 DevOps Challenges & Solutions Part 1: Focus on Business

Back in June, at a CIO engagement, one Chief Technology Officer stated bluntly that the biggest challenge for DevOps was Ops. He believed the best way to have a successful implementation was to completely cut the Operations Team out of the strategic leadership discussions. One senior leader asked him how could they truly call it DevOps; without "Ops" it simply is just "Dev." This reminded me that DevOps implementations can be hindered by lack of involvement from both the business and technology leadership as the team initiates and creates the new DevOps culture.

In Part 1 of this blog series, I provided an overview of the Top 5 Challenges and Solutions the business faces when the technology team implements a DevOps Strategy. In Part 2 of the 3-part series on Challenges and Solutions for implementing DevOps, I will focus on technology leadership challenges and suggested solutions.

Challenge 1: Starting with technology solutions

One of the key mistakes repeated by technologists is focusing on the technology solutions instead of the customers' requirements. As a result, they end up with solutions that fail to fulfill the minimal requirements for the company to be successful. This has led to a commonly held belief by users that IT exists in a bubble and $1.9 billion in unused IT Projects, according to PEW Research. (2015, PEW)

IT can address this challenge by working with its business counterparts to understand the "people" and "process" aspects prior to recommending technology solutions. A user-centric service approach will also help streamline the process to distill requirements down to the minimal viable product.

Challenge 2: Maintaining silos

The political landscape of a company can significantly impact your DevOps initiative. DevOps implementations can fail to realize their full potential value if the approach is too narrow or if IT maintains the current silos instead of assessing how the new process and platform can identify and consolidate duplicate sets of compute and data.

For example, one large financial services organization reported over 20+ silos of customer information and data that existed as a result of the multiple application siloes. This created significant frustration within the company, the business, and its customers because the systems did not sync. The silos caused multiple data entries for even a simple action, such as a customer request to update their address or contact information. Through micro services, the company reduced the siloes and eliminated a significant amount of duplicate efforts by both the business and technology teams. One key requirement for DevOps success is to proactively choose to eliminate siloes of competing work and/or create new ones.

Challenge 3: Beginning with Dev and ending with Ops as an afterthought

I interviewed 50+ IT leaders for my recent book. Interviewees who stated that they tried to develop their DevOps strategy in a vacuum within Dev, while not including Ops from the outset, have failed and flailed. Over and over, by the time the Ops team was pulled in, it was too late. The Dev team already had bought into their preconceived notions regarding critical Operations functions around scalability, reliability, serviceability, and security. This caused the implementation to fail. Why? Because the operations experts that understood those areas of the process were not consulted, so they did not buy in. As a result, the implementation fell apart.

To ensure success, invite the right people to have a seat at the table. One way to achieve this is by reimagining the software development lifecycle process as one technology initiative from the CIO down. This approach will reduce the political friction that can lead to failure.

Challenge 4: Treating DevOps as a Project rather than a Culture Shift

Similar to Business Service Management, DevOps can become a point of political friction within a company with multiple teams vying to be the owner or decision maker of the implementation. This approach often fails because DevOps is a cultural shift. Exclusively cutting out one team or creating DevOps in a vacuum not only increases friction, but also introduces risk into the company environment.

From my research, I learned about a continuous integration, continuous delivery process from development having significant impact on the network performance and ISP costs. By treating DevOps as a Dev Project, they failed to have the operational support or knowledge to reduce the risk to the business. A few interviewees reported that DevOps was being treated like a project and, as such, the resources were moved to other projects when they achieved the minimal viable product. Neither the business nor developers were comfortable adopting a process without dedicated resources to maintain it.

Challenge 5: Disengaging, delegating and disconnecting from the DevOps Shift

The final challenge that came up in my interviews with IT leaders was technology leadership disengaging, delegating or disconnecting from the process. In doing so, DevOps did not catch on as there was too much resistance to the cultural shift.

Technology leadership must stay completely engaged and involved to ensure the success of both DevOps and the overarching Digital Transformation the company is going through.

Read Part 3 of the series, covering the Top 5 Technology Implementation Mistakes.

Jeanne Morain is an Author/Strategist with iSpeak Cloud

The Latest

March 23, 2017

Mature development organizations ensure automated security is woven into their DevOps practice, early, everywhere, and at scale, according to Sonatype's 2017 DevSecOps Community Survey ...

March 21, 2017

When it comes to food, we all know what's considered "good" and what's "bad". We can all understand this simple rule when eating. But for many, when it comes to software development, simple rules and advice from nutritional labels aren't always there for us ...

March 20, 2017

Monitoring and understanding what software is really doing, and maintaining good levels of software quality is increasingly important to software vendors today. Even a minor bug is capable of shutting down whole systems, and there is a real risk that development cycle pressure competes with quality assurance best practices ...

March 16, 2017

More than half (54 percent) of IT professionals surveyed indicate they have no access to self-service infrastructure, according to a new DevOps survey of 2,000 IT industry executives by Quali.This means that more than half of respondents take a ticket-based approach to infrastructure delivery, impacting productivity and increasing time to market ...

March 15, 2017

Driven by the adoption of cloud and modernization of application architectures, DevOps practices are fast gaining ground in companies that are interested in moving fast – with software eating everything - between "write code and throw it across the wall" to creating more pragmatic mechanisms that induce and maintain operational rigor. The intent behind DevOps (and DevSecOps) is quite noble and excellent in theory. Where it breaks down is in practice ...

March 13, 2017

There might be many people across organizations who claim that they’re using a DevOps approach, but often times, the “best practices” they’re using don’t align with DevOps methodologies. They can say what they do is “DevOps”, but what we’ve found is that many are actually not following basic agile methodology principles, and that’s not DevOps ...

March 09, 2017

The velocity and complexity of software delivery continues to increase as businesses adapt to new economic conditions. Optimizing and automating your deployment pipelines will dramatically reduce your lead times and enable you to deliver software faster and with better quality. Here are three more most common areas that generate the longest lead times ...

March 08, 2017

Every enterprise IT organization is unique in that it will have different bottlenecks and constraints in its deployment pipelines. With that being said, there are some common problem areas that typically produce the longest lead times in your software delivery process. Here are the most common areas that generate the longest lead times ...

March 06, 2017

The findings of an independent survey of IT leaders, application developers and database administrators, conducted by IDG Research for Datical, indicate that database administrators are unable to keep up with the pace and frequency of database changes caused by the accelerated pace of application releases, thus creating a bottleneck and delaying digital transformation initiatives. An overwhelming number of databases administrators (91 percent) and application development managers (90 percent) cited database updates as the cause for application release delays ...

March 02, 2017

A "Boost Caboose" is a secondary engine pulled on a trailer for the explicit purpose of increasing the output of the primary engine. In many ways, DevOps is its own form of Boost Caboose for application of agile methodologies within the modern software factory and SDLC/ADLC processes ...

Share this