DevOps: Change is the New Normal¶
The software industry is moving away from large, monolithic, centrally managed IT systems, towards a future with small, loosely coupled and rapidly updated micro-systems.
And the rate of change is growing exponentially. Whereas in the past we would have quarterly releases orchestrated by IT departments, we now have a continuous stream of changes to production, delivered by cross functional teams operating in a you-build-it-you-run-it ownership structure.
All this is made possible by DevOps culture, practices and tooling.
Is all this change a good thing?
From the position of traditional IT departments, all this change can be a scary proposition. With so much happening all the time, how is anyone supposed to understand and manage the risks?
The good news is that not only is devops proven to drive better business outcomes, it also improves risk management. To find out more about the research on this topic, we recommend looking into the DORA State of DevOps Report and the book Accelerate by Nicole Forsgren et al.
One of the main shifts that enables devops is value stream thinking. In essence, the philosophy is that change itself is the value that goes through the value stream. By applying the lean principles of minimizing waste and continuous improvement we can improve the flow of change in our organization.
DevOps practitioners often categorize the value stream into two distinct areas:
Product Design and Development: often called the fuzzy front end, the host of activities taking place such as product management, prioritization, coding and testing, documentation.
Product Delivery: the repeatable process for delivering software changes to production.
While Product Design and Delivery steps are novel, hard to estimate, and highly variable, Product Delivery steps should be repeatable and predictable.
A DevOps pipeline can form part of the value stream of a software change delivery process.
Automating the Product Delivery process is a key step in any DevOps journey.