DevOps or DevOops?

It was the decades-long history of a buildup of IT demands and user frustrations that gave rise to DevOps in the early years of the 21st century. DevOps’ promise was that users would be more directly involved with IT in developing new applications, and that continuous collaboration between users and IT would ensure that applications would better meet user requirements and start production sooner.

Along with its sister methodology, Agile, DevOps has somewhat fulfilled this dream – but like any emerging technology and process, DevOps has also faced its hurdles.

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

1. Unfamiliar tools

There are a plethora of DevOps tools that do everything from creating and automating test scripts to monitoring application performance and helping to build applications.

Each of these tools requires training and/or retraining of IT and possibly end users. In the process, developers and users must also know the quirks and limitations of these tools. Meanwhile, earlier “tried and tested” tools languish on the sidelines. This can lead to employee concerns and slower DevOps deployments.

2. Lack of Standards and Processes

The DevOps methodology completely turns traditional waterfall application development on its head. Thus, it is important to think about what the new DevOps processes and guidelines are, and define them for both IT and end users before embarking on DevOps work.

For example, what is the general set of DevOps tools that everyone will use? How will these tools be applied in DevOps work? How will security and governance be ensured before applications are deployed? What acceptable quality level must an application achieve before it is ready for production? Are there areas of manual examination that still need to be done?

3. Reducing the degree of continuous cooperation required

The DevOps promise cannot be fulfilled if users and IT fail to consistently work hand in hand at every stage of DevOps. This means the user’s active participation with IT in defining, designing, developing, testing, deploying and maintaining applications.

Unfortunately, the account of this degree of user cooperation hasn’t changed much over the years. End users tend to work with IT in the early stages of application definition, design, testing, and even deployment – but once applications are deployed, user engagement tends to decline.

Users and their managers need to commit to an active role (and reserve more user time) for developing and supporting applications in a DevOps environment. If they can’t do that — and stick with it — it might be better for the organization to pursue DevOps adoption less aggressively.

4. Not embracing business

The beauty of DevOps applications is their ability to constantly change and adapt. The question is: Can the users at work change with them? Retraining may be required. In some cases, pockets of user resistance may appear.

Like other IT, DevOps applications must be valued for the value they bring to the business. If users in a company cannot keep up with the rate of change in rapid DevOps deployments, DevOps must be re-evaluated as a strategy.

5. Quality Shortcuts

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

This was a DevOps deployment, and users felt that the portal’s inherent value outweighed its flaws. They were satisfied with working with an application that works only partially, and focus on improving it continuously until it reaches full maturity.

If there is an agreement between users and IT to publish apps like this, then there is no problem.

But undeveloped applications are not OK if they are mission critical, or if the end users who depend on them are customers or business partners.

DevOps’ automated testing tools simplify QA tasks and shorten QA time, but these tools are still generic. They cannot understand the uniqueness of the company’s IT infrastructure or the existing application base.

If the DevOps implementation is so important, then systems professionals in IT who understand the end-to-end applications landscape should be involved in QA.

6. Misunderstanding what DevOps can and cannot do

DevOps initiatives do not have to fail. Organizations just have to take the time to thoroughly assess where DevOps are doing well – and where they are not.

What we do know is that DevOps is great for developing web-based and custom applications, and even applications that play important production roles when your IT department and end users are actively collaborating. However, DevOps has its limitations when it comes to developing mission-critical applications that require a great deal of careful integration with your existing code base.

Careful consideration (and manual checkouts) should also be given to any DevOps application that is targeted at the end customer or for external use. These apps must meet strict quality, security, and governance standards, and they must work flawlessly every time.

What to read next:


Leave a Comment