Bringing DevOps into Business

Convincing Business people to adopt new technology or strategy is always challenging. Especially when it is the DevOps or DevSecOps. As we all know, DevOps or DevSecOps will speed up the delivery of quality software and it has many more advantages but business people are failing to understand this fact. It’s not a problem with business people. It is normal and nature of business people that they can not understand the DevOps facts. It is the responsibilit of DevOps person to make them understand. Today we will discuss the nailing points of DevOps which will help business people to understand the necessity of DevOps.

Identify and Address the Business Problem

Run the As-Is assessment with the entire system, Collect the possible data and information regarding the system. With enough data, As Is – Model can be compared with the standard maturity models of DevOps and Explain to the client about the Gap. Let us take this case as an example:

Use case 1:

System: Assume a SaaS platform providing company is developing a custom application for their customer and they are Developing with different the developement team with different platforms.

Problem Report: Assume the following problems are observed:

1. The release is not happening in the declared date because of Integration issues happening after the Development Environment.
2. Communication and collaboration between teams are not happening and teams are blaming each other for the issues. Because of this production quality is degrading and the release gets delayed.

Resolution: The DevOps on The Development Side.

DevOps on the Development side will totally fix the problems reported in this case and here is how it should be addressed to the business guy to make him understand.

Observation 1:

1. The Release is not happening on time because the developers cannot be able to complete the job together but they are finishing their individual tasks on time. This is because of the integration of the code will not be happening between the developers. So here, We need to implement the Continuous Integration so that the code can be integrated before it is reaching further environments.
2. Developers are not communicating between them while developing the task so that they can fix this together even before committing the code. So we need to create an ALM (Application Life Cycle management) workflow and integrate collaboration tools to communicate with them and record them for the documentation. This can be done using tools like Jira, Confluence and Hip chat or slack.

Use Case 2:

System: Assume an internet-based application that is serving millions of users over a period of month which is having the production deployment on every month end and have new features that are getting developed for the next month.

Problem Report: Assume the Following Problems are observed:

1. Application deployment is often getting failed due to the lack of configuration information that is required for the deployment.
2. Web Applications are going down often and the reason for the same is because of insufficient resource and lack of monitoring/Alert management system.
3. Recovery processes are very complex as the bug could not be figured and fixed easily because of the lack of confidence on the issue.

Resolution: The DevOps on the Operational side.

DevOps on the Operational side will fix the above-observed issues. Implementing the following DevOps enhanced tools on the operational side will be the solution.

Observation 2:

1. Application Deployment is getting failed because of the wrong configuration or the wrong configuration details that are provided at the time of deployment. Now, this can be fixed if we are properly implementing the Continuous Integration and Deployment (CICD) on production alike environment before the production deployment.
2. Applications are going down often because of lack of enough resource over the time of high traffic and insufficient monitoring and alert management system to inform the same before the hand. This can be fixed by implementing the proper monitoring system and alert management system which are well integrated with the ALM tools so that the alert will reach the developers and operational teams before the impact.
3. Recovery of “Gone Down” applications are taking a long time to recover because of insufficient knowledge on the issue and less confidence on the issue to redeploy directly on production. This issue can be fixed easily by having the proper rollback or Hotfix workflow with the feature flagging strategy and integrating the log analytics tools with ALM tool so that the developer can have the clarity on the issue every time and fix the issue by integrating it quickly and get verified in a short time.

KPI for our work.

Providing resolution is not the sign-off. We need to prove the business person that our solution is working and improves the business process. To prove, we cannot show the system directly to the business person. We need to show numbers and Quantities. So by measuring the KPI (Key Performance Indication) values and comparing it with the KPI which are measured before and after the new resolution implementation will help the business person to understand how the DevOps solutions changed or improved the system. KPIs are like board examination of the DevOps person to prove his implementations.

So here are some example of KPI in the above use cases:

1. Deployment Frequency – This KPI will help us to find out how often we are deploying in the period of time
2. Defect Escape rate – This KPI will help us calculating the bugs that are fixed in QA and re-appeared in production
3. Lead Time – This is the KPI to find out the time taken for the work between task assignment and release.
4. Error rate – This KPI will help us calculate the number of errors occurring per number of features that are taken for the development.
5. Average wait time for integration – This KPI will help us to calculate the time taken for integrating the code from the development environment
6. Failed Deployment – This KPI will help us identify the number of deployments that are failed for the sprint.
7. Downtime Rate – This KPI will help us to find out the ratio of downtime per release.
8. Application performance – This is the KPI to measure the performance in terms of service response time
9. Mean Time to Detection (MTTD)– This KPI is to measure the average time taken for detecting the defect or issue after the deployment.
10. Mean Time to recovery(MTTR) – This KPI will help us to figure out the average time taken for fixing the issues that are detected after the deployment.

So these KPIs should be calculated before and after implementing the DevOps solutions and the comparative of both should be presented to the Business person to make him understand the improvements by means numbers.

Get the DevOps Handbook to learn more about DevOps [The DevOPS Handbook]

We will discuss more about the KPI measurements in an other whisper of Digital Varys.