You are here

Building a winning DevOps business case

public://pictures/John-Jeremiah-Technology-Evangeslist-HP.png
John Jeremiah, Evangelist, GitLab

Any new idea, innovation, or invention must start with a solid business case, and DevOps is no different.

You've heard the positive buzz about DevOps — and so has your management — but you can't build a business case on buzz alone. Why should your organization invest in the changes required to adopt DevOps? Here's how to answer that question and build a winning DevOps business case.

 

[ Learn how value stream mapping can improve your DevOps workflow. Download this GigaOm Research Byte report today. ]

Set the stage for a strong DevOps case

Software is changing every business by driving innovation and disruption, as Marc Andreessen eloquently explained in his now-famous 2011 treatise, "Why Software is Eating the World." To understand this, decision makers can simply look to disruptions in the retail, transportation, and hospitality industries created by software-driven innovation from Amazon, Uber, and Airbnb. The speed at which software can change and deliver innovation is now the speed at which the business — and your competitors — can innovate.

The principles of lean manufacturing and continuous improvement aren't just for manufacturing anymore. These concepts apply in almost all business settings today. Focusing on work in progress (WIP) and the constraints in your delivery life cycle is a powerful lever. The problem is that if you're optimizing development but can't deliver software to the end user, you're not delivering value. By looking at the end-to-end value chain and paying attention to bottlenecks and waste (also known as "muda" in agile software development circles), you can make improvements that dramatically improve cycle time, quality, and the bottom line.

DevOps is applicable to more than just the Web development team. It's an approach that influences the speed of delivery for many business systems, including mobile apps for your customers and field employees. As Geoffrey Moore points out in his 2010 white paper, systems of engagement need to be much more responsive and evolve quickly, while systems of record don't have the same need for rapid change. It's simply not realistic to expect financial systems or enterprise resource planning systems to change rapidly.

[ Learn what separates successful DevOps initiatives from unsuccessful ones in this new August 27 EMA research webinar. ]

Drive home the benefits

Focus on business value. Applications exist to generate business value. What value does your application deliver, and can you quantify it? How much revenue will it generate every hour? DevOps is about accelerating the delivery of software and business innovation, so you must understand and explain how accelerating business innovation will increase revenue.

Software may be eating the world, but rework is choking software. Consider how much time and effort your teams spend finding and fixing mistakes and errors, then put a number on it. As you improve delivery processes using a DevOps approach, you find mistakes earlier and eliminate the rework required to correct defects and errors late in the life cycle. You improve the quality of software while reducing wasted effort, freeing up capacity for more innovation to deliver greater business value. Consider how much of your development, quality assurance, and operations time you spend just finding and fixing things, and present the numbers to bolster your case.

Quantify the cost of downtime. Once you've quantified the business value of your application, calculate how many outages and disruptions you've had in production in the last year. Translate that downtime into dollar losses, then describe how DevOps will stop the bleeding while improving stability and performance in production systems.

Stress how automation delivers efficiency and accelerates delivery across the application development life cycle. With a DevOps model, you can optimize and increase the capacity of delivery teams. Evaluate your developers, build managers, testers, and system admins to determine how much extra capacity you'll gain as you implement automation across the DevOps delivery chain. After you've done that, show how you plan to you use that capacity to produce greater business value.

Explain the competitive risk of business as usual. Your competition is actively innovating and trying to disrupt your business. Identify the risks DevOps presents to your organization when competitors adopt this approach. Could they go to market first with a new feature that takes away your business's market share? How much revenue will it cost the business while your team struggles to catch up and implement a competitive response?

Get to the bottom line

DevOps can have a major impact on your bottom line, but if you don't build a DevOps business case to accelerate software delivery and accelerate business innovation before your competitors do, you may not have a bottom line at all.

You can't justify DevOps because it feels good. You must build a DevOps business case to sell your plan and gain business alignment, funding, and a timetable to enable the transformation. If you haven't already started to evaluate where to should start your DevOps pilot, now is the time. You and your business can't afford to wait.

 

[ Get Report: The Journey to Enterprise‐Scale DevOps: Becoming DevOps Determined ]