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:
