How To Build A Business Case For DevOps

James Roberts

Part of the “Agile ERP” series

Software is vital to the success of businesses today. Quite simply, the speed at which you can change your software is the speed at which your business can innovate and compete. If you can’t change as fast as your peers, you’re giving them an opportunity to steal market share and competitive edge. This means there’s enormous pressure on IT teams to deliver applications, infrastructure, and services quicker than ever before.

However, an accelerated pace of delivery brings significant risk if your existing tools and processes don’t adapt at the same speed. In that case, outcomes like unplanned downtime, critical application failure, and a higher cost of delivery may be just as likely as greater business agility. For many organizations, agile development and/or DevOps are a solution to this problem. These new approaches provide the means to automatically deliver change at high speed (potentially thousands of times per day for some applications) and crucially, to do so with less risk than traditional processes.

So if that’s the case, you might well ask, why isn’t every firm already doing DevOps? Well, aside from the fact that changing the way you operate can be a very sensitive topic, particularly when you’re talking about business-critical systems like ERP, in part it’s simply because change is hard. It’s never easy to shift mindsets that have been entrenched over decades, not least because while the “downside” of change is often relatively clear – particularly in terms of cost – the benefits are not always obvious before you begin.

With that in mind, a solid business case might be essential if you’re going to get the management buy-in and investment you need for the adoption of DevOps. It might be the difference between adopting a new approach and continuing with the status quo. In this blog, I’ll suggest some key steps that can help you build a compelling business case and win you the support you need to modernize how you manage enterprise applications.

1. It’s not all about numbers

Qualitative descriptions can be useful in framing your proposal in a way that resonates with the stakeholders involved. DevOps is about modernization. It’s about optimizing resources, de-risking change, and increasing efficiency by employing automation and the principles of lean manufacturing. These terms might seem vague and perhaps irrelevant to the task at hand, but using positive, forward-looking language to position your proposal can help set the right tone and bring people with you from the very start.

2. Define what you’re asking for

Realistically, adopting DevOps in any environment, including ERP, will require some level of investment. That might be a direct cost; automation software designed to enable DevOps is essential for success, and training team members in new ways of working can take significant effort. It could also be the “opportunity cost” of reallocating people away from their normal daily work. Either way, being clear about exactly what you are asking for will avoid difficult situations at a later stage and give you a starting point for any calculation of ROI.

3. Identify quantifiable outcomes

The broad principles of DevOps help to set the scene, but they won’t be enough to justify the investment you’re asking for. You need to define some tangible outcomes that you believe are relevant to your business, such as:

  • Reducing the cost of downtime. DevOps can provide more rigorous processes and improve quality, stability, and risk controls, all of which combine to significantly reduce downtime in production systems. This has a significant business impact. IDC estimates that critical application failure costs up to $1 million per hour, while Gartner uses $5,600 per minute as a benchmark cost for network downtime.
  • Delivering business value early. DevOps can decrease development cycles and enable you to deliver solutions faster, which increases revenue and strengthens your competitive edge. If you can estimate the potential value of a change (such as a new feature), then you’ll be able to indicate the additional income (or cost savings) that earlier delivery could generate.
  • Eliminating expensive manual effort. DevOps helps automate the end-to-end development and delivery process. I’ve seen firms automate 90% of the development lifecycle. That adds value in numerous ways, such as reducing errors, increasing the volume of change, and freeing team members to do additional, more valuable work.
  • Removing rework and waste. Endless loops of QA and development occur when solutions are deployed incorrectly or incompletely or the requirements are ambiguous. DevOps shifts quality left and massively increases collaboration between teams to increase development and testing efficiency. Unnecessary work in progress may also fall into the category of “waste.” Do you know how much code has been written in your systems but never deployed?

4. Add some data

To really cement your case, supplement these general outcomes with examples of what they might mean for your business. To do so, you’ll need to identify appropriate key performance indicators (KPIs) that contribute to the cost and/or efficiency of your development and delivery processes. This may not be easy. Some data might be available in the tools you use today, but much of it probably will be a “best estimate” based on discussion with members of the team. That’s OK. It’s important to remember that this process is not a science. It’s unlikely that anyone is expecting an amazingly precise cost calculation. The goal is to create a credible, understandable view of the outcomes that DevOps could deliver.

Important metrics might include:

  • What’s the volume and frequency of deployment (how many changes do you deliver and how often)?
  • What’s your cycle time (how long does it take to deliver a change from requirement to production)?
  • How many cycles of rework does a typical change go through (how many loops from dev to QA to dev)?
  • How long do approvals take on average?
  • What percentage of deployments fail?
  • How many critical production issues occur in a typical month/quarter/year?
  • How quickly can you recover if something goes wrong?

Once you have this information, you can start to quantify the improvement that DevOps may bring – for example, how many developer hours does a 90% decrease in manual effort actually make available? Ultimately, you may even be able to create an estimate of the cost of an “average” change and therefore the overall financial savings that DevOps can deliver.

5. Be clear on scope and approach

It’s important to set expectations effectively regarding the scope of the project you are proposing. If your intention is to start small and evolve as you prove out the method, make sure that’s clear; you’ll be more likely to secure the approval you need. On the other hand, if you’re starting with a large project or making a wholesale change in your team’s approach, it’s important to make sure the implications are transparent, including short-term risks that may lead to long-term gains. It’s also worth looking beyond your own area. In the ERP arena, we often find that teams looking to adopt DevOps can benefit from aligning with existing DevOps initiatives to leverage positive sentiment, knowledge, experience, and maybe even budget and resources that are already available.

Automating your way to success

Following this outline will help you put together a story that justifies the adoption of DevOps in terms of business outcomes rather than purely technical benefits. But remember: The amount of work you need to put into your business case will vary. For example, if you’re asking to start a small trial project in a company that has already adopted DevOps, maybe you won’t need a very detailed cost analysis to get management buy-in. Tailor your proposal to the people and circumstances you’re dealing with.

Once the business case is approved, you’ll be ready to start implementing the new tools and processes that will help you to successfully adopt DevOps.

If you’d like to learn more about what this might look like in an SAP context, check out our e-book, A Practical Guide to DevOps for SAP, or request a demo of Basis Technologies’ DevOps and Test automation platform.

This article originally appeared on the Basis Technologies blog and is republished by permission. Basis Technologies is an SAP silver partner.


James Roberts

About James Roberts

James Roberts is chief technology officer at Basis Technologies, responsible for driving product vision, strategy, and direction across the company’s innovative automation portfolio, and for ensuring that the engineering teams deliver world-class solutions. He has 30 years of experience in the software industry and nearly 25 years of SAP expertise working in a multitude of roles at major multinational companies.