Why DevOps Is Never Done
Today, these are all terms you might hear in a conversation about DevOps. But in fact, the DevOps movement owns none of these terms. They are all ideas we’ve heard before. Project Management, Enterprise Content Management, Agile, and Application Lifecycle Management (ALM) are just some of the historical movements that have used concepts like these toward the same end—to do things better and faster.
What makes DevOps different, however, is that DevOps never ends. DevOps is a process that allows you to continually get better. If you think you’ve come to the end of DevOps, you’re not doing DevOps right.
Keep reading for an explanation of why DevOps is a never-ending process, and why understanding this concept is important for doing DevOps the right way.
Dead On Arrival
The reason previous movements hit a wall is because they defined an ending point.
In contrast, movements such as DevOps should be a framework, not an end. You are not, nor will you be a “DevOps Shop.” You will, however, be a development organisation that leverages the DevOps framework to do your job. This means DevOps drives everything from documentation, to process, to talent, to tool acquisition.
True, there is comfort in being able to define a completion date. And in traditional enterprise culture, this is a must. Projects are started and projects end. This is because the structure of most enterprises is compensation based on projects that have been signed off on by business users.
But treating DevOps like a project will force organisations into the outcome, which is a project that took too long to complete, and by its completion is already dated, or the functionality is a Frankenstein that is the product of too many mid-development inputs, without a change on how it’s delivered and tested.
It would simply be bizarre to implement DevOps with Waterfall project management practices. Thus DevOps should not be a project, and if it is, the outcome will be fairly obvious.
The Wrong Way to Think About DevOps
When organisations treat DevOps as an end, the outcome is more automation. But it’s automation that cannot adapt, and tools and processes that are locked in.
This approach allows you to be modern for a time. But the system will eventually suffer the same fate as Waterfall development, or any other business process improvement project. It will eventually become dated, and users will be screaming, “This is not working for us!” It could be as soon as the project completes, or two years later, but it will happen.
The reason this outcome is unavoidable is that better programming languages, release automation tools, frameworks, and infrastructure are surfacing daily. Enterprises can control the cadence of the ecosystem and processes around them. And your organisation and customers demand that you leverage these improved tools and processes in order to produce better applications. But the newly established “DevOps” environment did not have these processes or tools as part of the original spec, so they have been architected out by design.
What “Success” Looks Like
In a development environment driven by a DevOps methodology, success is measured continuously. It is measured by issue remediation, releases, new automation, and fewer bugs. Both approaches are focused on results. The results are related to the applications the environment is producing, not internal checklists.
A successful development environment will always be able to leverage new infrastructure, replace source repositories, and introduce new testing tools, without having to re-invent the pipeline, and without a project to do so. This does not mean there is no change control and changes occur without consideration. Change control is not synonymous with Waterfall. It simply means there is no lock-in.
This is done by focusing on the software delivery chain as a deliverable of its own. And the software delivery chain will have its own versions, and be the meta-application for everything that the development team executes on. But changes can be made iteratively and continuously when well-architected. You build for change.
The DevOps Engineer’s Work Is Never Done
That is why the DevOps movement gave birth to a new job title: DevOps Engineer. A DevOps engineer is an engineer that has awareness of all IT and processes associated with creating great applications. The DevOps engineer can steward processes and find the right technology to get the job accomplished. The DevOps engineer is responsible for building both the pipeline strategy as well as the actual automation. And the work is never done.
The DevOps engineer does not dictate. He or she facilitates and finds out what it takes to make releases happen faster at a higher quality. That means the DevOps engineer is constantly looking for better tools and processes that can get the work done. Success is the improvement of the delivery chain over a period of time. If releases are going up, and bugs are going down, he or she has demonstrated tremendous value. But bugs never go away, and releases are never fast enough.
Yet the DevOps engineer also needs to be aware of what it takes to solve problems as well— what processes and tools are involved in remediation and self-healing so that issues are addressed at the same pace or faster than functionality is created, so that technical debt is not a topic in meetings. It’s handled by automation continuously.
Conclusion: Getting in the Zone
There is a lot of comfort in knowing that not only is the team always finding ways to improve iteratively and continuously—they are always focused on results that are not just internal. And this is for the users, not for the purpose of completing projects for the sake of completion.
DevOps is not a thing, and it is not an end. DevOps is a practice and a framework that development organisations leverage to release software faster, and at a higher quality, which means the job is never done. And that is the foundation of true innovation.
