Forget Devops

Image credit

“How do we implement devops?”

“How can we change to a devops culture?”

How often have you read or heard something like this?

I’ll bet you’ve heard this sort of thing more than once. Starting from ‘we need devops’ makes the wrong starting assumption, namely that ‘devops is some form of universal panacea’. Now, before you hit the comments with howls of indignation, I am not suggesting you don’t need devops but I am suggesting that you need to consider whether you need devops; a fine distinction but an important one.

Forget devops. What you should be asking is ‘how can we deliver more benefit to more customers/users faster and more reliably’, this is, after all, the question devops is intended to address. In considering this question you have three things to work with; where are we now, what can be done with our existing process and infrastructure, and would a wholesale shift to a new way of working be beneficial. This last one, for most organisations, represents the shift to a devops culture.

For most organisations improving what you have in relatively small ways will result in the greatest gains for the smallest investment. This is the rational choice for most organisation. These small improvement may, or may not, move you toward a devops culture and that’s okay because we’re all about improving how we work and not about blindly implementing ‘devops’.

Moving to a devops culture requires a radical shift in thinking throughout an organisation. This sort of shift is generally very difficult to implement. Virtually impossible to make in a single sweeping change and often stalls through lack of senior management support when implemented gradually.

When a radical shift is attempted in one ‘big bang’ it results in discontent among people who think the current way works fine (or worse, have a vested interest in maintaining the status quo). Any attempt at revolution in any sufficiently large and established organisation is doomed from the start as cultural inertia will drag it down and the discontented will sabotage efforts to change.

When a radical shift is attemped gradually (if one can be radical and gradual) the problem of cultural inertia is still present but more significant is the problem of gathering and maintaining momentum. You need to be constantly showing benefit to senior management in order to maintain their support for change and, as anyone who has attempted this sort of ‘quiet revolution’ will attest, this can be a significant challenge.

So, all hope is lost? Well, no, not completely but you need to be prepared for a long war and many battles.

The first step is getting senior management support. Find a greenfield project (one that will not require direct updates to existing systems). Then approach senior management about creating this new system using a devops approach. You need to be clear that you are aiming for a devops approach and this most likely means you will need to break company protocols, especially those around the separation of development and operations. Managaement tend to take less issue with setting up novel development projects and more with bypassing operational processes. You must ensure that you have buy in for building your own operational infrastructure. Make it clear that you need this, not to subvert company policies, but to improve feedback and turnaround time because your project considers the entire life of the system important, not just delivery to operations; your project will be responsibe for the system even after ‘delivery’. Point out that the whole point of a devops culture is to break down the siloes between the various IT system lifecycle disciplines. It would therefore be pointless to start out knowing that you will have to deliver into an existing silo (the exisitng operational culture).

The hardest part about selling devops is clearing up the misconceptions about devops. Make clear that devops is not about throwing out all process (quite the contrary it is about automating those processes so they are reliably and repeatably enforced while not being an unecessary barrier to delivery) and it is not about developers hacking away in operational infrastructure (again, quite the contrary, it is about ensuring a deployment pipeline and feedback systems that are efficient enough that developers do not need access to operational infrastructure).

Bring people along. Do not recruit a whole new development and operations team, recruit from within. Find people within the existing development, test, management, security, and operational siloes who want to try something new (bonus if they’re already aware of, and keen to try, devops). By recruiting from within you will begin the process of spreading the devops culture as these people will continue to work with and among their existing work contacts.

Once you have support, go for it!

Of course, if you’re just starting afresh you should be considering devops from the start. The only challenge here is finding team members who have not become so inculcated into the existing silo mentality that they bring that mindset into your organisation.