Proponents of adopting a complete DevOps approach to application delivery and deployment often note that DevOps includes a change in culture. And not just a change in lateral change in culture—improvements in the way teams across (and within) silos communicate and collaborate—but also horizontal change that permeates every aspect of the organization, from the top down.
That change means more than sharing information, it means sharing the right information. And in the case of convincing business stakeholders and even executive leadership that DevOps is the right approach to succeeding in this fast-paced, API and app economy, that means communicating its impact as it relates to their primary concerns.
Surveys such as Puppet Labs’ State of DevOps has done an excellent job of providing insight into the operational impact of DevOps. We’ve seen improved mean time to recovery (MTTR) and shorter lead times required. If you’re familiar with these measurements, then said improvements no doubt provide an excellent reason to at least begin adopting DevOps.
But what about executive and business leadership? They’re likely no more impressed by an improved MTTR than you are by a 10 percent reduction in average handle time or improved call resolution rate. To get buy-in from business and executive IT stakeholders, we have to provide proof of positive impact in their metrics. CA Technologies illustrated this divide in its DevOps Jigsaw survey, in which 86 percent of respondents consider “business stakeholder education” important, and yet only 33 percent have completed.
Communicating the benefits of DevOps in a meaningful way to non-technical people is an important part of that educational process. That could mean translating MTTR to dollars saved by reducing downtime, or improvements in app performance (response times) translated into productivity increases or reduced abandonment rates. That means focusing as much on measurement after delivery as it does measurement of delivery. It means crossing the chasm (and I know it’s a big chasm, trust me) between marketing and IT to understand abandonment and conversion rates and how they relate to performance and availability. It means making connections between IT metrics and business impacts and being able to connect the two and educate business leaders on how DevOps will or can make a difference.
It means, at a minimum, showing a direct and positive correlation between DevOps and a more agile IT environment and the metrics that consume the lives (and dashboards) of executives and business stakeholders. You don’t have to necessarily do the math for them (though that would be nice if you could), but being able to connect the dots between operational and business metrics should be considered minimum viable effort. And it’s a good place to start the process of affecting the cultural transformation required to sustain the benefits of a DevOps approach.