DevOps or DevOops?

A decades-long history of IT request backlogs and user frustrations were what led to the emergence of DevOps in the first years of the 21st century. The promise of DevOps was that users would be more directly involved with IT in the development of new applications, and that a continuous collaboration between users and IT would guarantee that applications would meet user requirements better and launch into production sooner.

Together with its sister methodology, Agile, DevOps has made this dream come true to a degree -- but like any emerging technology and process, DevOps has also had its hiccups.

As IT continues to expand DevOps use, here are six ongoing challenges that DevOps presents:

1. Unfamiliar tools

There are a plethora of DevOps tools that do everything from generating and automating test scripts to monitoring application performance and assisting with application builds.

Each of these tools requires training and/or retraining of IT and possibly end users. In the process, developers and users must also learn the quirks and the limitations of these tools. Meanwhile, former “tried and tested” tools languish on the sideline. This can create staff apprehension and slower DevOps deployments.

2. Lack of standards and processes

DevOps methodology totally turns traditional waterfall application development upside down. Consequently, it’s critical to think through what the new DevOps processes and guidelines will be, and to define them for both IT and end users before DevOps work is undertaken.

For instance, what universal set of DevOps tools will everyone use? How will these tools be applied in DevOps work? How will security and governance be guaranteed before applications are deployed? What is an acceptable level of quality that an application must attain before it is ready for deployment in production? And are there areas of manual checks that still need to be performed?

3. Underestimating the degree of continuous collaboration that is needed

The promise of DevOps can’t be achieved if users and IT fail to work continuously alongside each other in every phase of DevOps. This means active user participation with IT in application definition, design, development, testing, deployment, and maintenance.

Unfortunately, the calculus for this degree of user collaboration hasn't changed much over the years. End users tend to work with IT at the beginning stages of app definition, design, testing, and even deployment -- but once applications are deployed, user participation tends to fall off.

Users and their managers need to commit to an active role (and reserve more user time) for application development and support in the DevOps environment. If they can’t do this -- and stick with it -- it might be better for the organization to pursue DevOps adoption less vigorously.

4. Lack of business adoption

The beauty of DevOps applications rests in their ability to continuously change and to adapt. The question is: Can users in the business change with them? Retraining might be required. In some cases, pockets of user resistance might emerge.

Like other IT, DevOps applications must be assessed for the value that they return to the business. If the users in the business can’t keep up with the rate of change in DevOps rapid deployments, DevOps should be reevaluated as a strategy.

5. Shortcuts on quality

Not long ago, I visited a company that had launched an internal portal on its intranet. Only about 40% of the portal was working, and even in these “working” instances, bugs were continually being discovered.

This was a DevOps deployment, and the users felt that the inherent value of the portal outweighed its imperfections. They were content to work with an application that only worked partly, and to focus on continuously improving it until it reached a full level of maturity.

If there is agreement between users and IT to deploy applications like this, there isn’t a problem.

But half-developed applications are not ok if they are mission-critical, or if the end users who rely on them are customers or business partners.

DevOps automated testing tools simplify quality assurance tasks and shorten QA time, but these tools are still generic. They can't understand the uniqueness of a company’s IT infrastructure or existing applications base.

If a DevOps application is mission-critical, system professionals in IT who understand the end-to-end applications landscape should be involved in QA.

6. Misunderstanding what DevOps can and can’t do

DevOps initiatives don't have to fail. Organizations just have to take the time to carefully evaluate where DevOps works well -- and where it doesn’t.

What we know is that DevOps is great for developing web-based and ad hoc applications, and even applications that serve in significant production roles when IT and end users actively collaborate. However, DevOps has its limitations when it comes to developing mission-critical applications that require substantial amounts of careful integration with an existing code base.

Careful thought (and manual checkouts) should also be given to any DevOps application that is targeted for end customer or outside use. These applications must meet rigorous quality, security, and governance standards, and they must work flawlessly every time.

What to Read Next: