It seems that nearly every day I get approached by a recruitment agency looking to place a "DevOps engineer" at a company which is "doing DevOps" and nearly every company are doing DevOps wrong because they are treating DevOps as a set of tools rather than as a process.

Someone on twitter said it was “Ops++” and I think that is a great way to describe it. You could also describe it as the worst form of shadow IT.
As an example, most companies, and by extension recruitment agents, seem to think that DevOps requires automation and cloud based skillsets as well as involvement with build tools. This is not at all, what DevOps is about.

In the book, the Phoenix Project, automation is used as a method to build environments for developers to test against. The developers even comment that it is helping them improve on build times as all the tools are provided and that they can “check out a virtual machine that’s got all of the environment preconfigured”. No cloud. No containers. Just a simple, template virtual machine.

In the background, management are focused on improving workflows and getting visibility of the actual work they have.

Likewise, the cloud is used as an extension of the Parts Unlimited data centre to provide a temporary boost to a system that the developers are having issues with getting to run fast enough. In this, they use automation that they already have to spin up and spin down the compute instances.

What many people seem to miss is that these two events happen near the end of the book. The first thing that happens is that the reader is taken on a journey to understand what wok actually is and that “any work done anywhere other than at the bottleneck are an illusion”. I will bet that most companies “doing DevOps” would not know where their constraints are and would not see an improvement in throughput by “Implementing DevOps”.

At no point in the book are tools mentioned and at no point does anyone create a DevOps team, instead, the walls come down between the teams and the traditional ops teams work more closely with the developers and the QA people. Today’s approach to DevOps seems to be “rename the Ops team to Devops, automate everything and we’ll be in good shape!” which is totally the wrong approach because it just creates more silos and gives more responsibility to a team that doesn’t understand where work is coming from and ends up drowning under more workload.

It can (and will) also lead to an automation dependant culture where a DevOps engineer pushes a button and a task runs, they will not know why it happens, instead, they’ll just expect it to happen.
In the future, when a change is required, the change will not be in the original automation script, it will be in a script that is run after the original automation script because the engineer will be too scared to touch the original script in case it breaks.

Docker, AWS, Chef, Puppet, Ansible, Kubernetes are all great and wonderful technologies that should give IT departments more flexibility in how they do things. They are not “DevOps tools”, you are not a “DevOps Engineer” because the very title harms what it means to do the DevOps process.
DevOps shouldn’t even really be called DevOps, it should be DevSecOps to highlight just how critical security is and how security testing should be baked into the process from the very start

DevSecOps is a great practice to work to, in many ways it is a rehash of [CMM](https://en.wikipedia.org/wiki/Capability_Maturity_Model from the mid 1990’s but expanded to cover IT Operations as well.

It is just a shame that most people do not seem to know how to implement DevOps properly, just giving a team the name “DevOps” and expecting miraculous things to occur is not only short sighted and asking for trouble but it makes IT that little bit worse and reinforces the image of IT projects always running late.