'We already do that, we’re just OG* enough to not call it DevOps'

When your finance guy is like, c'mon...

At this point in the innovation curve for something like DevOps it’s fashionable to start asking “Where's the Return On Investment?”

Answering that question is always tedious. For the hopeful, starry-eyed practitioner, spitting up the ROI figures is akin to the irrelevant water-carrying and wood-chopping trials imposed by a kung-fu master. Except instead of cold rice with snow-white topknots, it’s dreary spreadsheets with pearly toothed finance flacks.

If you’re lucky, your organisation will be dead-set on taking on that “survival is not mandatory” mind-set, ignoring questions like ROI. But, most everyone else has to fill cell range C45:G60 with all that water and wood.

First, go drink

Your first inclination will be to crack jokes about flossing and Blockbuster. “What’s the ROI on flossing, you ask? Well, do you like having teeth?” You’ll follow up with erudite commentary on all the Blockbusters out there who were rearranging the deckchairs on the RMS ROI as it descended into the icy depths.

This is not helpful. Find yourself some colleagues, get a few pints, and have a laugh play-acting this out. Once you’re back from second breakfast, try some more helpful approaches.

What is this “ROI” you speak of?

When finance and management interrogators ask about “ROI” and “business cases,” I find that they’re mostly asking three questions:

  1. Will this fit in the budget?
  2. Are we paying too much?
  3. Will this change actually work?

Sometimes they’re asking all three questions, sometimes just the first two. Sometimes they’re using you to practise their Cenobite impersonation with implements scrounged up from about the cube-farm. More likely, they’re asking at least one of these three questions.

Will this fit in the budget?

Of all the ROI questions, this is the easiest to answer. If you know the budget, you just need to figure out how you’ll meet or come under it. When looking at DevOps, this means you’ll first establish the baseline cost of following the “old” way, like staff’s pay, tooling, and the expected cost of fixing screw-ups. Then model how DevOps concepts such as "two pizza teams" and "reducing release cycles" will lower your costs.

If your teams spend less time communicating with other teams, there’s less time in meetings, clicking up presentations, and coordinating what to do after the meetings. Communication is more effective and efficient if you’re all on one, small team.

You want your product teams spending 90 per cent plus of their time on product, but they’re probably spending more like 20 to 30 per cent. Fewer, silo’ed teams will result in fewer errors caused by hand-offs between teams. Meanwhile, DevOps’ smaller batches of code and weekly release cycles will increase the resilience of your applications (faster time to recover) and the productivity of your software (as you iteratively release, observe the use of, and improve your software’s usability).

Cost-cutting? It's possible...

If you want to pull out the trimmers, also look at staff reductions. Several large organisations I’ve spoken with have drastically reduced their operations and QA staff after modernising their software development and delivery approaches.

You can dress this up by saying those “resources” will be re-allocated to “more high value activities,” but if you’re slotting in a huge amount of automation and pushing routine testing to the product team you may find yourself with a sizable thumb-twiddlers' budget.

When fitting into an assigned budget, your ROI answer is on the subject of “doing more with less.”

Are you paying too much?

We all like a good deal, and can agree that getting fleeced is a poor outcome. You’d like to know you’re not overpaying. With a process change like DevOps, the tough question is “paying for what?” There are costs associated with modernising your software approach like buying new tools and hiring consultants (or “coaches”) to help change your organisation.

When it comes to tools - which usually means software, SaaSifed or otherwise - you’re talking procurement negotiating and producing a proof of concept. There’ll be alternatives for your development toolchain, for where you run your software (public cloud or on-premises), fees for middleware you use, and support and maintenance costs.

There are no easy answers, just models and competitor matrixes to work over. The raw tools here are standard technical tests to prove out the alternatives and the track records of other users, good and bad.

You might also ask if an outsourcer can do it more cheaply than your organization. Answering this question requires more of an assessment of the your organisation’s willingness to change, and not only the staff, but management as well. The change is not easy; executives I’ve spoken with estimate that anywhere from 30 to 70 per cent of people “won’t make it”.

Will this actually work?

You’ve crafted up numbers for a business case, horse-traded your way to a good deal, and ensured that your people can pull it off. And seemingly, true to Larman’s Law, people keep insisting on more justification.

Other than table-flipping your way into a new job, I’ve found three useful tactics here:

  1. Other people’s success, first hand - doubt about success tends to revolve more around “we already do that, we’re just OG enough to not call it DevOps” and “we’re not good enough.” Occasionally (and always in comments from you, dear El Reg readers) there’s the cry of “it’s an Augean Stables’ worth of offal.” While there’s no end of success stories when it comes to DevOps, rather than sending an email full of links that’ll never be read, arrange actual meetings between your doubters and outsiders who’ve been successful with DevOps.
  2. Hide - creating a “skunk works” is a tried and true method to bootstrap a new process, ignoring the haters in dry-clean creased dark denim. If you fail, there’s massive risk. But if you succeed, you’ve demonstrated that the new way is effective and to be trusted. Someone might even thank you.
  3. Start small - do a series of small projects to prove out the new process. These can’t be “science projects” and instead need to be something that’s small, yet important to your organization. In doing these little projects, you’re building up credibility for the new process and also learning how to do it.

What’s the ROI on ROI?

Finally, you should assess your own return on your time spent on cleaning out the stables. Will it be worth your time, personally and professionally, go to all these meetings and hustle up justifications for all the naysayers? Ideally, the answer is yes, of course, that’s my job even! But carefully look at your situation, the political climate in the office, your chance of success, and the pay off you’ll get. If you’re on the wrong side of that Deming quote, it’s best to enjoy the deck-top orchestra while you find elbow your way into a life-boat. ®

* Original Gangsta. Man, why does the CFO have to talk like that?

Similar topics

Broader topics

Narrower topics

Other stories you might like

  • VMware claims ‘bare-metal’ performance from virtualized Nvidia GPUs
    Is... is that why Broadcom wants to buy it?

    The future of high-performance computing will be virtualized, VMware's Uday Kurkure has told The Register.

    Kurkure, the lead engineer for VMware's performance engineering team, has spent the past five years working on ways to virtualize machine-learning workloads running on accelerators. Earlier this month his team reported "near or better than bare-metal performance" for Bidirectional Encoder Representations from Transformers (BERT) and Mask R-CNN — two popular machine-learning workloads — running on virtualized GPUs (vGPU) connected using Nvidia's NVLink interconnect.

    NVLink enables compute and memory resources to be shared across up to four GPUs over a high-bandwidth mesh fabric operating at 6.25GB/s per lane compared to PCIe 4.0's 2.5GB/s. The interconnect enabled Kurkure's team to pool 160GB of GPU memory from the Dell PowerEdge system's four 40GB Nvidia A100 SXM GPUs.

    Continue reading
  • Nvidia promises annual datacenter product updates across CPU, GPU, and DPU
    Arm one year, x86 the next, and always faster than a certain chip shop that still can't ship even one standalone GPU

    Computex Nvidia's push deeper into enterprise computing will see its practice of introducing a new GPU architecture every two years brought to its CPUs and data processing units (DPUs, aka SmartNICs).

    Speaking on the company's pre-recorded keynote released to coincide with the Computex exhibition in Taiwan this week, senior vice president for hardware engineering Brian Kelleher spoke of the company's "reputation for unmatched execution on silicon." That's language that needs to be considered in the context of Intel, an Nvidia rival, again delaying a planned entry to the discrete GPU market.

    "We will extend our execution excellence and give each of our chip architectures a two-year rhythm," Kelleher added.

    Continue reading
  • Now Amazon puts 'creepy' AI cameras in UK delivery vans
    Big Bezos is watching you

    Amazon is reportedly installing AI-powered cameras in delivery vans to keep tabs on its drivers in the UK.

    The technology was first deployed, with numerous errors that reportedly denied drivers' bonuses after malfunctions, in the US. Last year, the internet giant produced a corporate video detailing how the cameras monitor drivers' driving behavior for safety reasons. The same system is now apparently being rolled out to vehicles in the UK. 

    Multiple camera lenses are placed under the front mirror. One is directed at the person behind the wheel, one is facing the road, and two are located on either side to provide a wider view. The cameras are monitored by software built by Netradyne, a computer-vision startup focused on driver safety. This code uses machine-learning algorithms to figure out what's going on in and around the vehicle.

    Continue reading

Biting the hand that feeds IT © 1998–2022