This article is a summary of our 3D Podcast – Episode 106: “Business Value and Justification for DevOps.”
We in the DevOps world know that the adoption of the principles exercised in DevOps lead to quicker response times, more reliable products, higher availability, and lower long-term costs for organizations both in the private and public sectors. But, it isn’t always so easy to get management on board with the changes that must occur in order to see the benefits. In this podcast and article, we focus on how to convince upper management that their organization should adopt DevOps. Nirmal Mehta joins the podcast to discuss ways of explaining the business benefits of DevOps to C-level management.
Educating C-Level about the Benefits of DevOps
For an organization to go forward with a DevOps environment, it is important that the C-level of management understand how DevOps improves their organization. Part of the process of educating C-level is showing that the concept of DevOps matters not only to management but also to the organization as a whole and to its individuals is important.
This education begins by talking about the business benefits an organization can experience through using DevOps principles. By connecting each benefit to an actual situation in the organization where expectations are not being met, you can make it more real and tangible and less theoretical to management.
Let’s review some of the benefits of DevOps for clients and customers. These are the benefits that you need to tie to your specific business in educating management.
Quicker response times
A main component of DevOps is the automation of processes and tests. Through automation, you reduce the time required to get to deployment. This means you can make changes quickly in responding to business customers. Being able to make fixes or develop additional features fast means more satisfied customers and fewer costs for the organization in the long-run. Both of these are goals C-level managers view as very important.
In our podcast, Nirmal describes an actual occurrence where an entire system that monitored production was inadvertently wiped out. In an environment without DevOps, this would have taken days to diagnose and correct, as well as incurring tremendous stress for everyone involved. But, in their DevOps organization, because of the automation and technology in place, the situation was corrected in 20 minutes with barely any effect at all.
Another anecdote Nirmal shared noted a situation where the development time was greatly reduced due to DevOps. The client had been taking as long as 160 days, sometimes up to a year, to develop new features. By virtue of a DevOps environment, that time was reduced to 4 weeks. Imagine the satisfaction of the client when they experienced turnaround this quickly.
Giving examples such as these from a real-life DevOps environment paints a picture for management to begin to understand this important benefit and how it can improve their own organization.
Removing as much risk as possible affects operations in a very big way. Through both constant identification of the goal(s) and automation, DevOps enables an organization to reduce the risk of fails and problems. Automation is the pathway to lowering the risk because it eliminates the need for manual changes. It allows operations to move away from constantly responding to emergencies and move toward a monitoring stance. The operations staff is under middle pressure from business users and customers as well as support. Reducing stress and time for operations in making sure all is well has strong business value.
Through identifying the goal (“true north”), an organization can make every decision with that goal in mind. In this way, all decisions drive to the goal which eliminates waste in time and money. The ability to focus on what is important allows the organization to stay lean and efficient. Efficiency in the production process not only saves costs in the long run but also ensures that the customer is satisfied.
Reliability and high availability
DevOps ensures that the organization’s systems and applications are highly reliable and available. This capital goes a long way in meeting expectations and customer satisfaction. Having reliable systems that are always available reduces the stress on highly skilled employees. Reduction of stress can result in retention of staff and an environment that is focused on continual improvement.
Challenges in the Public Sector
There are many challenges in both the public and private sectors that affect development and operations and can make affecting change difficult. Over the last few decades, we’ve seen outsourcing, insourcing, reshaping, and reformation in the private sector and the government space in a way that has made many organizations’ systems disjointed and extremely inefficient.
In the podcast, Nirmal describes a project he was involved with that is a real example of DevOps providing business value. In this example, the GSA had 12 large monolithic operations and each was owned by a different contractor and separate operations teams on with different contractors. Each of the 12 had different management. The amount of waste and redundancy in the infrastructure was vast. Nirmal’s company was hired to consolidate all operations into a common services model for the GSA. Many organizations, just like the GSA in this example, need to transition to a common platform and shared services for efficiencies, and DevOps allows them to do so.
Selling by Tying to Customers’ Pain Points
Leadership and business users don’t like pain. By showing them how to alleviate some of their pain points, you get them to see what life can be like in a DevOps environment. So, first, you need to get data that will back up your reasons. You must do your research here. By gathering information that identifies their pain points and the associated costs you have the facts to convey their current, painful situation. What are the current costs and what is the cost of automation on the front-end? This can be a hang-up for many stakeholders, so you need to be able to show the savings long-term to the organization.
Here are some questions to get you started:
- How long does it take to get a new feature deployed?
- What is the life cycle of the sales cycle?
- What is the response time for fixes, features, or applications?
- What do these response times cost now?
Examples that show benefits to the organization illustrate the reduction of time and money. Such scenarios as automating deployments for a test environment or automating deployments for a sales demonstration can be shown to management to get your points across.
Infrastructure as code is an aspect of a DevOps environment that has a huge impact. When educating management, it is important for you to highlight this aspect and connect it to revenue generation. Infrastructure as code enables you to have “moving forward patching.” In other words, when you have infrastructure as code, you can patch while maintaining the ability to move forward. Infrastructure as code enables containerization. By containerizing applications, you are able to “kill” a node without affecting the application. If it needs to be patched, you kill a node and stand up another one, and that new instance has the new updates.
In effect, you are constantly re-deploying instead of patching. Everything is a re-deployment, or a new deployment, of infrastructure as code. In this way, every time you go through an infrastructure change, you are always testing high availability and reliability.
Guiding Principles and Goals
Operating in a DevOps environment requires the team to define goals and unify in the movement toward those goals. In Nirmal’s example of working with the GSA, his team defined 5 tenets that guided their project:
- Open source first
- Cloud first
- Data as a first-class asset
- Security as foundation
- User experience and usability were core
These tenets directed them to look at an open shared source, which was needed in solving the problems. The team viewed data as a top asset. Security was the foundation of everything. And, the team had to get to the core of what the user wanted.
By defining specific goals, knowing risk points, estimating time cycles, and delineating costs you begin to have the information you need to sell management. Be prepared with metrics and facts to back up your information. Nirmal’s final advice is to engage in active listening and get to the pain points. He points out that “DevOps is actually empathy.” Understanding how the principles of DevOps can alleviate their pain and then communicating in terms of business value will sell DevOps to your C-level managers.