Building a winning DevOps business case

Author: John Jeremiah

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.

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.

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.

Read full article:

You may also like...

Leave a Reply