Over the past couple of months I’ve been collating a report about DevOps, which I hope to be out in August (all being well, with a following wind). I’ve taken briefings, had interviews and conversations, and generally made a nuisance of myself. The goal was, and remains, to go beyond “DevOps, is great, come on board” evangelism, and address the simple, yet profound question: how to scale DevOps from small initiatives, towards making it work across the enterprise?
Despite my background in various areas of dev and ops, and the many reports, articles and research notes I have written on the topic, I confess to have started the process with a soupçon of imposter syndrome: what if I was to find this was a non-question: “Oh, come on, man! We sorted it. You know, these days, it just… works!”
Over the period, I have learned that my fears were unfounded; or rather, the challenges were just as big as I thought they might be (and ever were). I’ve also learned a number of lessons about the nature and reality of DevOps, which I thought I would share:
1. It’s not (just) about DevOps. Don’t get me wrong, breaking down the wall between development and operations is a worthy goal and a laudable achievement; however, it isn’t an end in itself. We’ve ended up with a lot of stakeholders trying to crowbar their own interests into the DevOps title, ending up with clunky terms like DevSecOps, whereas perhaps the focus should be elsewhere completely. To whit:
2. It is all about business value delivery. Customer-centricity, done right, gives more to customers and therefore, modelled right a greater return on investment to the business. DevOps can bring speed and responsiveness, and therefore result in more innovative, higher-value solutions. But the drivers for innovation come from the customer, by way of the business. There is not point in meeting the wrong need, however quickly.
3. Reality is the biggest bottleneck to DevOps. Channeling my inner Scooby Doo villain, DevOps would have been just fine if it wasn’t for all those pesky real world challenges. Testing and quality management, security, database and information management, governance, collaboration and so on keep getting in the way, but this is looking at things the wrong way around. To flip it, the question is, how can enterprise reality be made more efficient? This leads to:
4. Man, is there a crapload of DevOps vendors. We are in an apparent fan-out phase, in which hundreds of tools and service companies claim to have some kind of DevOps solution. They are all right, at the same time as being a symptom of, rather than a solution to the DevOps scaling challenge. We will see a massive wave of consolidation and subsumption, triggered when an enterprise-focused software company cracks the code and triggers a buying spree.
5. Cloud is cause, catalyst and now consequence of the DevOps stalemate. Speak to digital-native startups, who have built their infrastructures on the public cloud, and they wonder why DevOps is even a thing. Speak to cloud companies and they say, rightly, that a wholesale move to the cloud would enabler a simpler world in which DevOps could thrive. Speak to enterprises however, and find a continued preference for hybrid models, rendering such simple rhetoric pointless.
6. Enterprises know where they want to end up, but are stymied. Cloud and software vendors present the current smorgasbord of service options as a good thing, but the gleeful fan-out of innovation is getting in the way of enterprise progress. Companies that serve millions of people in complex ways can’t simply change everything wholesale, and would really rather the tech industry commoditised a bit — or a lot — so they could get on with becoming learning organisations without all that distraction. Which means:
7. Tech could start by turning some of that smartness onto itself. Enterprises don’t need a thousand different DevOps pipelines, enabling a thousand thousand different ways of addressing what should be a solved problem. The tech industry tells other verticals about the power of data, of automation, of machine learning of AI: it will have succeeded if it can come up with a business-led DevOps process that all organisations can bank on, and which is enough of a standard to enabled data-driven, predictive automation.
There’s an eighth point of course: it’s a crap name. I’m not a fan of changing labels willy-nilly, but the fact is, DevOps is the kind of name a techie (or two) would come up with, and what enterprises need is a technical basis upon which the business can innovate. No, no, and three times no, this should not be called BizOps or any other derivation. DevOps emerged as a touchstone, but it risks becoming a millstone.
The discipline currently known as DevOps has a way to run, as organisations learn to benefit from new ways of delivering faster. But, as the business moves into the driving seat, so it should also be given the remit to define what success looks like, and the terminology that goes with it. Watch that space.
Follow Jon Collins on Twitter.