DevOps seems to gather some real interest from large organizations here in Germany. After having talked to a couple of companies and asked about what they specifically need, it seems to me that there exists this misconception of what DevOps actually is and how to implement it in a company.

Let me start by stating what DevOps is not

1. DevOps is not a replacement of Agile

   If your company is not practicing Agile it will be more difficult to switch directly to DevOps.

2. DevOps is not a replacement for ITIL

   DevOps can coexist with ITIL processes, however, to support short lead times and higher deployment frequencies many areas of the ITIL processes need to become fully automated. The ITIL disciplines of service design, incident and problem management still remain relevant because DevOps requires fast detection and recovery when service incidents occur.

3. DevOps is not just Automation

   This is probably, in my opinion, the biggest misconception. Companies seem to focus eagerly on people to come in and help with automation. Although I agree that the biggest part of DevOps time should go into enabling Automation (CI/CD, IaC, DR…etc) but the work shouldn’t end there. DevOps requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond automation.

With this out of the way, let’s start looking at what DevOps is and how to implement it.

DevOps is a practice that enables companies to deliver value quickly, safely and reliably to their customers. Usually, this is implemented by allowing small teams to quickly and independently develop, test, monitor and deploy their code.

The implementation time can differ between companies and is dependent on many factors. Most companies struggle to deploy production changes in minutes or hours and in an age where competitive advantage requires fast time to market, these companies are at a significant disadvantage. This is in large part due to their inability to resolve conflicts within their software development and other IT departments (Operations, QA, InfoSec..etc.). Why? Because for example, IT Operations responsibility is to provide stable and reliable service and the software developers responsibility is to introduce new features or make the solution more accessible to the customers. The goals between departments differ.

Obviously, companies structured this way will suffer from chronic conflicts between departments. These conflicts can often lead to poor software and service quality that can kick off a chain of effects felt by customers, employees, and everybody else involved.

Solutions

1. Introduce a DevOps Engineer that understands:

   The principles of flow, which accelerates the delivery of work from developers to the customers. The principles of feedback, which enables the creation of safer systems of work. The principles of continual learning and experimentation, which enables new ideas to be validated faster leading to a competitive edge in the industry.

2. Send the IT managers to a DevOps school

   Similarly to how IT managers needed to be ITIL schooled one can reason that in our fast paced environment IT managers need now to understand both ITIL and DevOps principles. The best way for IT managers to understand DevOps is reading about how companies such as LinkedIn, Etsy, Amazon, Netflix, Spotify and many others introduced the DevOps principles. Take a look at Spotify’s cultural video and here.

Summary

It seems everybody understands the principles of DevOps differently. I hope I could express my views on the topic in a meaningful way and some of you might even agree. If not that is also fine :Þ Just make sure to email or comment your opinion.

In a future post I might delve more deeply into the above-mentioned principles and how to actually implement them, also a topic for a future post might be, “The perfect DevOps engineer a software developer or a Sys Admin?”

What do you think? Let me know!