What is the ultimate goal of DevOps?

Software development is a complex process. It consists of many moving parts, and it is sometimes difficult to understand each part in the context of its place in the bigger picture. 

A result of this inherent complexity is the assignment of some intrinsic value to any changes made in the organisation or process. And since software development goes beyond just code and systems, this value must be understood in terms of people and costs as well. 

This holistic valuation in terms of People, Process, and Product is what is known as Business Value. And all software firms develop software in order to accumulate this Business Value.

The Ultimate Goal of DevOps

“The ultimate goal of DevOps in any organisation is to help optimise this flow of business value from the conception of the business idea to the end-product at the hands of the user; all the while encouraging greater collaboration between the stakeholders involved.”

Though DevOps seeks to bring together the development and operations teams and process for greater product release velocity, the ultimate goal of DevOps can only be achieved through a comprehensive cultural change in the company itself.

This optimization of business value flow can be understood in terms of:

1. The Ability to Deliver Value
2. Learning from Experimentation
3. Measuring what matters
4. Faster Software Product Velocity
5. Improving the value chain
6. Moving away from silos
7. Encouraging Cross-Functionality in teams

This article will look into each of these in some detail.

The Ability to Deliver Value

Every organisation has to be able to deliver significant value to its stakeholders in order to survive in the market. DevOps allows teams to reduce risk and expedite delivery of thoroughly tested code and be more responsive to customer requests and changes

Learning from Experimentation

Continuous experimentation allows for a greatly expedited learning curve in which the teams can perform course correction at the source and not wait until product delivery to be able to learn from their mistakes.

Devops stands in stark contrast to traditional software development models in that, it embraces the culture of Continuous Everything (Continuous Planning, Continuous Integration, Continuous Deployment, Continuous Delivery, Continuous Testing, and Continuous Monitoring) in order to be more responsive to change. 

Continuous Everything in DevOps

Measuring what matters

Sometimes organisations get so big and processes so complex that objective, data-driven feedback loops become impossible to implement. DevOps utilises several metrics like 

• Mean Time to Failure/Repair/Diagnose (MTTF/MTTR/MTTD): These help to quantify the risks of any potential pipeline failures. This needs to be minimised in order to have a healthy performance overall
• Time to Value: This is the time taken to build and push a piece of software to production, thus ensuring that the work done begins to generate value. This must be minimised as much as possible in order to increase the benefits of using DevOps

To allow the focus to remain on what’s important and optimise the entire DevOps pipeline.

Faster Software Product Velocity

Software teams today do not have the choice between getting software delivery right or getting it done fast. They must be able to do both consistently in order to maintain a competitive advantage. Teams often lose time and money in bug fixes, code rework, having to wait on stakeholders for support, etc. 

A Key component in DevOps is Continuous Delivery which allows teams to meet business objectives in a timely and consistent manner by synchronising the Build-Test-Deploy cycle. 

Continuous Delivery in DevOps

It also brings together different stakeholders like Business Analysts, Developers, Testers, and IT Operations personnel in cross-functional teams and creates synchronous workflows so that wait time is reduced. 

Pro Tip : Manual tests are not ideal for Continuous Delivery. They lead to extended lag times between development and test completion, and are generally prone to human errors. Automated tests on Emulators/Simulators are also not ideal as they fail to replicate real time conditions. BrowserStack Automate and App Automate allow integrations with DevOps tools like Azure DevOps and lets users execute tests using Selenium, Appium, etc on 3000+ cloud based devices.

Run DevOps Tests on Real Devices

Improving the Value Chain

Value Chain in DevOps

One of the main reasons why organisations venture on a DevOps transformation is the general sense that “productivity” has dropped or that they do not obtain enough “value” from their products or services.

Back in 1985, Michael Porter published the book “Competitive Advantage: Creating and sustaining superior performance” in which the “Value Chain” model of an organisation was discussed. This model allowed the mapping of the activities that add value to a company into primary activities (dedicated to the development of a product), and secondary activities (necessary for the support structure and functioning of the company). 

As change is the only constant, organisations are required to respond rapidly to changes in the market. However large organisations become so complex that they are often unable to identify whether change is required in a primary or secondary activity funnel.

DevOps offers a way out of this and achieves its goal of generating business value by automating tasks and integrating disparate systems so that positive changes made in one part of the pipeline benefit the other parts as well. 

Since processes are now more tightly coupled together, it is possible to spread the benefits of change in a controlled manner than having to worry about the aftershocks of change on different silos.

Moving away from silos

Teams naturally tend to operate in silos, especially in large organisations. This prevents the creation of a smooth end-to-end DevOps pipeline, and creates an adversarial relationship between teams. The ultimate goal of DevOps is to reduce wait times and minimise rework. The creation of silos prevents a sense of total ownership. DevOps teams avoid the blame game associated with the “who is responsible” mindset and allows the unified allocation of resources by leveraging the flexibility of cross-functional teams.

Encouraging Cross-Functionality in teams

A cross-functional team includes developers, QA’, Business Analysts, and support personnel in its basic structure. Software teams bent on production speed often become overloaded with developers and can’t produce software fast enough because it is not enough to simply write code. Such teams spend weeks in “analysis paralysis” going back and forth with other stakeholders on trying to determine the features that are fit to go into the next release. The lack of collaboration often means that everyone is not on the same page and is a major cause of friction during communication.

Cross Functional Teams

The DevOps lifecycle works on a Plan – Build – Test – Deploy cycle, and gets people to work together in delivering optimal value to each software segment while operating as a team. Thus, the entire team seeks to deliver value to the process as per their capabilities. 

Conclusion

The ultimate goal of DevOps is to be able to increase the collaboration between the two primary pillars of software engineering – Development and Operations. It allows them to work in sync, fosters a culture of ownership and collaboration, and allows teams to deliver value to the customers in as short a time as possible.

This is possible by reducing the gap between development and delivery, ensuring that the software delivered is in accordance with the business goals, and that the flow of value is optimised in every step of the process. DevOps improves the value chain of the product as a whole and breaks down silos thereby allowing teams to own the process and deliver results better.