Over the past seven years or so I’ve been privileged to have watched the DevOps movement grow. I’ve experienced first hand the difficulties of implementing a more structural and communicative approach to implementing the concepts and ideas around DevOps (and the consequences of those difficulties!), and I’ve seen numerous definitions including my own attempts but actually none of those definitions matter any more.
DevOps had a purpose – To break down the silos within organisations and help people write and deploy better quality code and systems. I see so many reports from respected organisations like Gartner claiming that DevOps is something that most enterprises are thinking about adopting, and yet when you talk to those organisations as I do day in, day out, the majority of them are under the impression that as long as you’ve installed Jenkins and you’ve setup a “DevOps Team” who are responsible for deployments, then you’re “Doing DevOps”.
To me, this is the antithesis of what DevOps was meant to be about. It’s become about tooling, not culture and this is perpetuated by some of the DevOps consultancies that only want to resell IBM or HP tooling in the guise of “DevOps Transformation”. Tooling is important, but unless you have the cultural foundations in place to support the new tooling, it’s going to be a very painful process and you will hit resistance after resistance on the way.
Over the past two years, I have had the great pleasure of working with and for DevOpsGuys. The main thing that sets them apart from all their competitors is that they have a process of transformation that involves everyone in the organisation, from the people who answer the phones and open the post, to the C-Level executives in their boardroom, and the results have been amazing.
I have watched organisations who, after following our advice, have merged their development, systems and “DevOps” teams into smaller, service or product-focused teams and seen a rapid increase in their productivity and quality.
I’ve seen silos come tumbling down and complete reorganisations of seating plans as companies realise that the best way to collaborate is to have people working on the same things to sit next to each other, and as a result, code quality and speed to deploy has increased.
The problem is that whilst the large organisations continue to preach that DevOps is about tooling and not culture (in spite of the CALMS acronym!), their customers continue to make the same mistakes and just move to practising waterfall development with two week iterations.
DevOps, to me at least, is common sense – it’s about communication, it’s about improving the way you work, but most importantly of all, it’s a People Problem that cannot be solved by technology alone and can only be solved by looking at the organisation as a whole instead of just the developer and sysadmin teams – but unfortunately this battle appears to have been lost.
The self-declaration of many as “high priests” of the DevOps Movement, so-called “luminaries” who have never been heard of outside their own large enterprise organisations, and their insistence that as long as you install tool-set “x” you’ll be fine means that the guiding ideas of DevOps are being lost in translation.
DevOps means different things to many different people, and without a clear definition, we are sunk.
Perhaps it’s time for me to updated my job title from “DevOps Consultant” to “Business, Culture, and Systems Automation Consultant”…