The need for a DevOps assessment

For sometime now, like many IT professionals, I have developed a keen interest in DevOps and have been following, researching and trying to practice nuances of the DevOps style of doing things. Having worked in environments which are still in the DevOps 'infancy' stage or are mulling about doing DevOps, having seen their challenges from inside out, I thought it is only pertinent to share my views about organisations embarking or trying to embark on the DevOps journey. The innate theme of my article being, look before you leap

Knowing where to begin

Just because DevOps is the most in-thing, many decision makers in IT consider it cool to start being 'DevOpsy', but lack the oversight of what DevOps really is and what inherent changes (read cultural) are required to make it work. The tenets of Continuous Integration, Continuous Delivery, Continuous Testing, and Continuous Monitoring as easy as they may sound, can be quite arduous to implement and practice. Some of the above practices might already exist, but in bits and pieces, all that is required is to build upon these fragments, tie them all together and voila! you are doing most things the DevOps way. Sounds easy and cool? Well, to be honest, it is not

NB : Netflix, Spotify, Amazon, Flickr et al took years to nurture and practice DevOps in totality in their environments.

It is in the context of discovering what is already being done and what needs to be done that an assessment needs to be performed; before going big-bang and declaring "we are going to be doing DevOps" from the next year. For example - An organisation might be doing software development work the agile way - in short sprints, but the deployment of the 'releases' might still be done the traditional 'quarterly release' way. It therefore becomes imperative to study and understand how to enable and feed the output from the sprints to be able to continuously integrate the developed and tested code into the configuration management system and then to continuously deploy it to lower environments and continuously test it before deploying to production at the touch of a button.

Furthermore, an organisation might be practicing Continuous Integration but can't do Continuous Delivery because the architecture of the applications is such that individual components are very tightly coupled and it is not possible to release in increments to the components without taking the the entire application offline.

The business vision, development, testing, monitoring, architecture and deployment are the obvious choices to begin.

It is better to improve 10% in 100 different areas than to improve 1000% in just one single area

Knowing what to assess

In my view there are four assessment levers to focus on, they are -

• Process
• Technology
• Culture
• Metrics and Measurement

Process - Assess the software development process, change and release management process, Incident and problem management process to understand potential bottlenecks to a seamless 'from concept to market' software/feature delivery. The intent is to analyse the processes to discover the wasteful activities in them.

Technology - The focus here is to understand the tooling requirements to enable the teams to achieve development and release velocity. The outputs of this assessment aim to provide answers to some of the questions like - how to configure, test, deploy and monitor software with automation and minimum manual effort, how to stand up environments and standardize them, how to manage versions, how to detect failures instantly, how to factor in security, how to build quality right from the start instead of applying 'band-aid' at the end

Culture - Perhaps the most challenging of it all, assessing what the organisational culture is like, are the Dev and Ops teams collaborative or confrontational? does the senior management recognise the need for DevOps? what are their expectations around benefits realisation from DevOps? This assessment will target to answer questions like - how to enable collaboration between the Dev and Ops teams who have been historically at loggerheads, how to enable openness, trust and transparency among teams, how to remove the blame game and naming culture, how to instill a culture of experimentation and learning from failures.

Metrics and Measurement - There is an old adage - you cannot improve what you can't measure. The metrics and measurement assessment gauges what is the frequency of releases and changes, how often do changes cause incidents, how long does it take to recover from failures, how many builds fail on an average, what is the software quality etc.

Knowing what to change

The outcome of the assessment will provide an insight into the things that need to be changed at an organisational level to enable DevOps to take wings, drawing a roadmap and targeting one small bit at a time is the way to go instead of trying to boil the ocean all at once. It does take serious commitment and belief to change the culture, it is a long drawn battle and once culture is in place, everything works like a well oiled machine.

DevOps is a sum total of CALMS as they say -

C - Culture

A - Automation

L - Lean

M - Metrics

S - Sharing