Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.
DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.
Planning the Adoption Journey
Here are four different aspects an organization should consider before starting the DevOps adoption journey:
Conduct an as-is continuous delivery assessment on product development practices and processes within the organization
This will best determine an organization’s current maturity level across several different parameters, including:
- Culture and organization
- Build management and continuous integration
- Environments and deployments
- Release management
- Testing and verification
- Data management
- Design and architecture
- Information and reporting
This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.
Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it
Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.
Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization
Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:
- Bringing in common views on what a product, release or sprint is intended to deliver.
- Creating an opportunity to bring forward and address operations needs during the development cycle.
- Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.
Measure and track
Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:
- Production deployment frequency: The number of product releases within a specified time.
- Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
- Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
- Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.
The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.
Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.
For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.
About the Author / Amit Gupta
Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.