DevOps needs more perspective and humility
DevOps started as a grass-roots movement led by practitioners. The motives were pure, and focused simply on finding better ways of doing things for the good of everyone involved in software delivery.
In recent years, though, DevOps has become increasingly commercialised. Software vendors and service providers have ridden the wave of interest to sell tools and consulting. Events companies have tapped into community enthusiasm to attract sponsors and sell conference tickets.
None of this is inherently good or bad, but the increased involvement of evangelists and marketing professionals has inevitably led to emergence of repeatable narratives that are, well, constantly repeated.
One of these revolves around the notion that savvy developers have been adopting modern methods, then pushing ideas and new ways of working downstream. Devs are the heroes of this story, with conservative, protectionist and paranoid operations teams portrayed as being dragged kicking and screaming into the 21st century.
Ops as a ‘necessary evil’?
This narrative paints Ops almost as a necessary evil, only there to keep the lights on and to deploy the goodness created by Devs. Some even weave a ‘NoOps’ sub-plot into the story, suggesting that advances in cloud and serverless will render Ops professionals redundant in the not-too-distant future.
I won’t try to lay out all of the ways in which this narrative is both wildly inaccurate and potentially insulting to a group of professionals with a lot of practical experience and collective purchasing power (Ops budgets generally dwarf those of Devs). For a full discussion of this, I would encourage you to download our report IT Ops as a Digital Business Enabler.
Suffice it to say that there’s no shortage of thought-leadership and innovation in the operations domain: new architectures and service-delivery models, transformation around hybrid/multi-cloud, turning risk management into a value-creating discipline, and so on. Pull this together with everything else going on in relation to business application suites, cybersecurity, advanced comms and collaboration, information lifecycle management, etc, and it soon becomes clear that deploying and running software from in-house development teams is usually a relatively small part of the Enterprise Ops role.
The world really doesn’t revolve around developers
With this in mind, the Dev-centric narrative that we repeatedly hear from DevOps tools and platform suppliers leads at best to much eye-rolling outside of the Dev bubble. And at worst, it runs the risk of alienating some important constituencies. Whether the narrative is propagated consciously or unconsciously is secondary; more important is the fact that it actually gets in the way of achieving the overall objective, which is to get everyone working together more smoothly and harmoniously across traditional boundaries.
Taking on board different perspectives and maintaining balance is even more important when we consider DevOps in the broader digital transformation context. The introduction of new ideas and alternative ways of thinking and working is not unique to the world of software. Just as DevOps originally drew on advanced manufacturing principles, software delivery teams could learn a lot from looking at other disciplines across the business.
I remember interviewing business and finance people about 10 years ago on their understanding of service oriented architecture (SOA). While the language used was different, the principles of separating concerns and the concept of functional units working together around agreed contracts and communication protocols were very familiar. Some were amazed, in fact, that IT systems weren’t designed to work that way already – “We’ve had shared services for years!”
Just because it’s software, that doesn’t mean the ideas are new!
And so it often is when you get into conversations around Agile, DevOps, fail-fast, etc with product managers, creatives, logistics specialists, campaign planners, R&D teams and more progressive finance professionals. Once you get past the differences in vocabulary, you often find you’re talking about the same or similar ideas, and that in many cases software teams are playing catch-up.
Against this background, it’s important that as we try to integrate modern application and service delivery into the broader business, we recognise that a lot of ‘stakeholders’ might actually be more advanced in their thinking than we are in the world of software. Sure, there’s a software aspect to most significant business initiatives nowadays, but there are also typically infrastructure, logistics, creative, commercial and risk management dimensions that are equally important and require a similar level of innovation and agility.
If we zoom out to the bigger picture, software is clearly only part of the digital transformation mix. When you then consider what’s available today in terms of off-the-shelf applications and SaaS services, it also becomes clear that in-house development is in turn only part of the software discussion.
If we keep this in mind, maintain a sense of perspective, and communicate with humility, increasing the reach and impact of modern software delivery methods could become so much easier.