You can't DevOps everything, kids. Off the shelf kit especially
Waterfalling for the, er, 'boring' stuff
Comment Hey, psst. Come over here, I have a secret to tell you. My fellow DevOps hoodwinkers would cement-shoe me for saying so, but you don't always need to do the DevOps. In fact, in many cases, it's likely a waste of effort. Let's start walking this way, briskly, now – I think I see some pink and chromatic blue fade-tipped Thought Lords and Ladies coming down the hallway towards us. They look like they're ready to do a blameful pre-mortem.
I'm sorry, I COTS hear you!
There's of course a trick to such a claim like "most of the time DevOps isn’t valuable": if you widen the aperture of projects to all things IT does, it turns out all these notions of DevOps and, often, agile have little effect as you get closer to packaged software. In my experience, and the admission of most of those ill-intentioned scowlers gaining ground on us in this hallway – ah, let's duck into this closet here – unless you're writing and running your own custom software, there's little benefit to transmogrifying yourself to DevOps.
If you're not the type who stocks your outhouse with copies of the Harvard Business Review, relishing each issue like some wheel of rare cheese, you might think about this as a distinction between commodity IT and strategic IT. Commodity IT (sometimes called "utility") is the huge bucket of IT used to keep the lights on. This type of IT has little to no effect on your organization's uniqueness and are not those things you do differently than competitors that makes your customers stick with you. Here, we have things like desktop management, supply-chain management, order management, payment processing, payroll – you know, "the back office" and most of ERP. Back when companies hadn't digitized all of this yet, putting it in place was world changing, to be sure. But, now they're just table stakes.
It's little wonder that most of these functions, then, are serviced by what used to be called commercial off-the-shelf software (COTS). Any CIO worth their salt will have been moving most of those COTS to software as a service (SaaS) in recent years to fully suck out the costs and hassles of keeping the commodified IT up. We certainly see that in the huge, year-over-year, shift of spending from COTS software to SaaS. (Oh, and you're supposed to have reduced the amount of duplication across such systems back in the early 2000s – so you already have that done... right?)
Does something like DevOps, or even, agile really matter for managing COTS and SaaS? Sure, the ability to deploy changes more rapidly, while at the same time reducing defects, and then getting that rapid feedback loop in place to perfect how your service is helping out the business – yeah, that'd be awesome. But doing anything that's even remotely a shade of DevOps has some basic requirements.
There's some hope that you can apply DevOps to your enterprise applications, the DevOps Report says, "as long as they are architected with testability and deployability in mind." Further: "Continuous delivery can be applied to any system, provided it is architected correctly," which feels close to saying: "So long as your software doesn't suck, it won't suck." The point being, very few of the hulking ERP systems and other packaged software stacks out there were written to be testable and deployable as a DevOps approach would demand. In those cases, you can feel free to do the DevOps, but it likely won't do you any favours.
"What of agility?" you ask, though. If agility is understood as the ability to add new capabilities to your software quickly, well, friend, bring a thick neck. When it comes to the ability to customize COTS, there's copious rope you can start lashing around your neck. Without the software being written to easily and rapidly change and upgrade, you're going to quickly customize yourself into a hole, sealed over with an avalanche of incompatibility once new versions of the software are released.
The advice – which we all know, but rarely follow – when it comes to third-party software is to change it as little as possible. In fact, to not change it all and, instead, change yourself. As software design guru Martin Fowler puts it: "My view is that for a utility function you buy the package and adjust your business process to match the software." And then he gets mighty close to joining the cement-shoe set when he suggests a pragmatic deal with this IT. Since The Business often wants to customize the IT rather than itself, "usually this is politically infeasible, so the workaround is to put a low-grade software team to work on it. Provide enough care to avoid catastrophe, but otherwise you don't need a high-grade team."
When does one waterfall?
It'd be easy to say that the answer, then, is that DevOps should be applied to all custom-written software. Perhaps. A more nuanced way of dividing up your portfolio would be to group those services and applications that are brand new, that are driving innovation and growth in your organization, and those that are, really, static and never going to change. Diagnosing the first is easy, and are the scope that any DevOps hustling assumes. It's misdiagnosing the second that's the grey area of successful DevOps shelfware, legacy quicksand, and falling behind competitors.
To put it in the vernacular of the agilistas, when does one waterfall? In all likelihood, not often. It's very rare that custom-written software can just sit and stay the same, never changing, living out a static life. Without even worrying about the marketer's siren-call of BUSINESS DISRUPTION that drives you to update your software, just the cycle of new user interfaces and integrations every five to ten years – client/server, the web, mobile, wearables, voice – will whip you in the face like a Belmont if you're not nimble enough.
Waterfall will serve you well if the requirements for your software never change, and are fixed. It's like making a circle of salt around your house: it'll keep the trolls out, for sure, but that's a lot of salt to blow if it turns out that trolls, actually, don't exist.
DevOps all you want, but make sure there's still pizza in the box
When sorting through new IT methodologies – and definitely reading my Friedman-on-valium typing – it's important to keep your eye on the actual "business". It's the old maxim we all too often forget: use the right tool for the job. For much of your IT portfolio, DevOps isn't the best tool; SaaS and Fowler's low-grade lot for political chaff will probably do. It's easy to leap into the chute and start DevOpsing all the things.
You'll hear all the DevOps and cloud-native vendors saying: "You're now a software company! Nah! You must be a software company, for as writ in the book: 'Survival is not mandatory'." Getting good at software is clearly important, but focusing on the right strategic projects is key. Don't waste your precious DevOps resources on the back-office and commodity IT. ®