We’ve written a ton of content about how to unlock the value of frequent deployments for your database as well as applications, from improved coding patterns to strategies for architecting smaller deployments. But the multi-million-dollar question for you and your business is something else entirely: what is the real business value of frequent deployments?
That’s the question I’m going to address in this series of three posts. The answer will help you frame the kind of investment your organization should make into large-scale process changes while also setting achievable, quantifiable goals.
Top-down initiatives often set vague or unrealistic KPIs that get filtered down to IT teams in such a way that there is no urgency to actually pursue them. Likewise, bottom-up initiatives can get bogged down in technical details to the detriment of the teams promoting them because once the project reaches the C-suite, the benefit to the business is unclear.
Uncovering the business value that technical and business stakeholders can agree upon – and the targeted metrics it will take to unlock this level of value – is the best way to ensure that projects don’t stall and goals are met. Everyone needs a finish line.
But how do you quantify that value? It’s not an easy task, but it’s very worthwhile to generate an estimate to get visibility into how much additional revenue your business is not capturing … or whether you’re wasting time thinking about it because it won’t bring back much value at all.
We know, for example, the best practices that enable reliable, low-friction releases, so we can predict where the impact will be felt with a high level of certainty. Those same best practices will have knock-on effects in three layers down the chain that can dramatically alter your bottom line:
- Hard costs
- Recouped time
- Faster time to market
In this post, I will focus on hard costs and the easily identifiable savings that can be identified because they are easy wins that can be achievable at any organization.
Hard costs and frequent deployments
Hard costs are the quantifiable costs related to your current process: developer time wasted on manual tasks, time wasted on reworking failed deployments, the time it takes your DBAs and release team to deploy to production (particularly if this is an event that requires dozens of people pulling an all-nighter every couple of weeks), etc. Simply put, hard costs are inefficiencies that can be minimized, resulting in cost savings for the business.
Another hard cost commonly overlooked when considering value is downtime. This risk is often the reason teams don’t release whenever they want to and it is expensive no matter who you are. Releasing frequently while also limiting and/or eliminating risk is a key variable to understand. Pure developer velocity is useless if it’s causing more complications down the line.
To determine the value obtained from hard cost savings, consider the following questions:
- How many developers do you have and what is their average salary?
- How many hours per week do they waste on laborious, manual tasks?
- Similarly, how many hours per week do they spend reworking errors in code following a failed deployment?
- How many hours per month are spent on releases?
- How many hours are wasted manually compiling audits?
- How much does downtime cost per minute, and how many minutes a year do you experience downtime?
Hard costs may seem burdensome to quantify at first, but the work pays off when you define what they mean to your organization’s bottom line.
In the next part of this series, I’ll walk through recouped time – the result of identifying, lowering and/or eliminating your hard costs – and the business implications of it.
Want to understand more about the value of frequent deployments?
- Read the blog post: DevOps 101: Unlocking the value of frequent deployments
- Watch the webinar: How to unlock the value of frequent deployments
Was this article helpful?