Greg Pritchett, MD of Marval, examines why he thinks there’s something missing from the DevOps model.
For IT professionals, the idea of having a more collaborative approach between development and operations is highly appealing. Getting rid of the isolated “siloes”, opening up to feedback and building consorts across the product lifecycle, from design to end of life — who would say no to that?
DevOps came with a promise to provide exactly that, with all the obvious benefits: a resilient and highly scalable infrastructure built and running faster and easier, happier teams, improved productivity, better quality and increased effectiveness.
As a result, DevOps became very popular very quickly; only for many organisations to discover that this (great in principle) approach requires more than good intentions to be successfully applied. In fact, it requires supporting culture, proven processes and investment in the right tools. Unless these conditions are in place, DevOps is very likely to be unsuccessful.
What DevOps fails to take into account is the existing environment: resources, assets, technology and culture, all integral elements of the organisation, all potential burdens to successful implementation. And you may be able to improve some of these elements, but this will take its time and demands for good planning — it’s very unlikely to manage to uproot a long-established culture and customs in a few days.
Sure, we all like the idea of “a big, happy family working together”. Real work environments though have deadlines, pressure, work overload, conflicts and most importantly people, who need to buy in the idea and decide they want to be part of it. Real work environments have their pre-set ways, their little traditions and their core teams, who won’t get excited about this more collaborative concept just because it’s good for the company. They need to see and appreciate why this is good for them.
In my opinion, what DevOps is currently missing is a clear link to the corporate vision and strategy. Its focus on operational and practical aspects has made it exactly what it’s trying to displace: an isolated practice related to development and operations exclusively.
These two functions though can really affect the organisation’s mid and long-term plans. Their efficiency can generate great outcomes that have a positive impact across the organisation; a lack of efficiency can have exactly the opposite results, as well.
By highlighting this connection and making it part of the corporate strategy, organisations can anticipate a smoother integration, helping people realise what all the fuss is about, what the benefits are (not just for the company, but for them as well) and what their role will be into this.
This is a change and, just like any change, the DevOps adoption can be assisted by processes that will inspire and enable a cultural shift. Supported by technology and advanced tools, processes can really help cultivate a new mindset and foster the right culture. Processes and technology will help people traverse the new path more easily, faster and with much more confidence.
At the end of the day, DevOps will help us go from A to B following a specific workflow and therefore without getting much trouble on the way. It will help us do things more collaboratively and probably more effectively.
In order to be really efficient with DevOps, though, we need good processes in place- and tools, which will enable us to optimise the use of existing resources, minimise operational costs and maximise results. We need alignment between operational and business objectives.
We need a well-designed strategy, to make DevOps an integral and functional part of the company’s operations, instead of another fashion invention. We need to take into account the existing environment and integrate DevOps in it, not the other way around.
Technology-assisted process is the missing link that will put everything in place. Without it DevOps will just speed up the mayhem.