The Language of DevOps ROI
The Language of DevOps ROI
The DevOps approach is set to reign supreme, but what factors are stopping businesses from adopting it? Often it's a lack of understanding the financial benefits.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
DevOps is clearly becoming more popular. 33% of respondents in our State of Database DevOps survey had already adopted a DevOps approach across at least some of their IT projects, and a further 47% intended to within the next two years. For the 20% with no plans to move towards this new way of working, what was the barrier most frequently cited? A lack of understanding of the business benefits. Quite understandably, getting over that hurdle of determining how this will actually help the business seems to be a key factor in adoption.
So how do you calculate the business benefit, or the return on investment, of DevOps?
It’s not as straightforward as calculating the return on investment of a new piece of hardware. DevOps is a new way of working that encompasses widespread change across people, processes, and tools. It may involve a fundamental shift in the way your teams work, prompting the need for training as well as investment in new technologies. It can take time to undergo a transformation like this, and there will likely be some initial pain to go through before you actually start to reap the benefits.
However, as the annual State of DevOps report from DORA and Puppet shows us, there are enormous tangible and intangible benefits for organizations who have adopted this approach to software delivery. Efficiencies are made through automating manual processes, reducing downtime, and minimizing the time spent recovering from failed deployments. Plus, additional value is gained as time spent on tasks like unnecessary rework or manual testing can be spent on work that delivers value to the business instead.
But what does the term ‘value’ even mean for your organization?
Before you can quantify the benefit of DevOps, perhaps it’s worth reflecting on what would be the greatest value you could add to your business. The definition of that "business value" may well depend on the nature of the organization and industry you’re in, and how that value manifests may also vary at different levels within the organization, depending on who you’re talking to and what lens they’re looking through.
DevOps Measurement Lenses
The idea of different lenses for measuring the benefits of DevOps is something David Linwood, an experienced IT Director, explored when carrying out an MSc research project on DevOps ROI. He looked at the perspective taken by three different levels of management within the typical organization – CEOs, CIOs and Team Managers – and came up with three different measurement lenses:
This is the CEO’s area of interest. What’s important to him or her, and the rest of the Board, is how will this investment ultimately lead to higher revenue and/or profitability. Whether that’s delivered through tangible cost reductions, faster speed to market, or other improvements in business performance, ultimately the CEO will be interested in the value that this change can deliver to the organization and its customers, and that value often varies according to the nature of the organization.
Preserving value is equally important. In 2015, Gartner put the average cost of a critical application failure at anywhere between $500,000 and $1 million an hour. So investments that can be proven to help minimize financial risk caused by catastrophic IT failures will quickly capture board-level attention. And that’s before you even take into account the potential reputational damage, and the subsequent impact on shareholder value, caused by high-profile incidents of downtime or data breaches.
Ingredients for Success
At the next level down, for the CIO or Head of IT, the focus is on ingredients for success. How can we put processes in place to increase the throughput of the IT department? Can we recruit and retain the skilled IT staff we need to deliver quality services to the business?
The 2016 State of DevOps report found that organizations practicing DevOps spent 50% less time on unnecessary rework and 66% more time on new work than their peers. Not only was their throughput higher but spending more time on enjoyable, value-added development also led to higher employee satisfaction levels.
As the DORA ROI guide outlines, “Retaining existing talent is more cost-effective, preserves institutional knowledge, and gives organizations an advantage by having a strong technical workforce that is engaged and continuing to learn.” If this sounds too intangible, how about measuring and quantifying the cost to the business of recruiting and training new members of staff? A study by the Center for American Progress found that the typical cost of turnover is 21% of an employee’s salary.
IT Output Performance
Down in the engine room, for team lead roles such as IT Managers or Technical Leads, the focus becomes more firmly on the output performance of the IT department or team. They care about metrics like the speed of deployment or number of new releases delivered by their teams. They’re also more interested in the ability to reduce defects and decrease downtime, or improve time to recovery, perhaps reflecting the pressure on these leaders to maintain what is a core function for the business.
Again, the State of DevOps report shows improvements across all these key metrics in high-performing organizations: 200 times more frequent deployments, 2,555 shorter lead times, 24 times faster recovery from failures, and 3 times lower change failure rate.
It’s All About Perspective
All of these factors are important because each will eventually translate into some kind of business value, but what you choose to focus on will differ depending on who in the organization you’re talking to. So, when you’re at the start of the journey and seeking buy-in, think about which stakeholder you’re talking to and the lens that they’re looking through, then talk to them in their language.
Published at DZone with permission of Kate Duggan . See the original article here.
Opinions expressed by DZone contributors are their own.