Research: DevOps - who, how and why now?

As well as delivering software faster, DevOps has numerous benefits for the IT department, research finds, but strong leadership is essential

We live in a software-defined world. Products of all types are differentiated by the software they run and many services by the software used in their delivery. Because it is now a key differentiator, getting high quality software to market as quickly as possible has become a priority for organisations of all shapes and sizes.

Adding value through software is behind the emergence of DevOps, the melding of the developer and operations roles. There are others of course, which we will investigate a little later, but first let's check the lie of the land.

The vast majority (84 per cent) of the 300 organisations we surveyed in the run up to today's DevOps Summit were developing at least some software, even though for most this was not their core purpose. Twenty-nine per cent were predominantly coding their own applications with a further 55 per cent relying on a mix of third-party suppliers and off-the shelf software, augmented by their own in-house expertise.

[click image to enlarge]

Thirty per cent of these organisations had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 per cent planning to go down this route.

In spite of its newness, there was a good understanding of what DevOps is all about, with little of the jaded cynicism that often greets technological developments. OK, so three per cent said it is basically no different from Agile while seven per cent believed it to be just another new buzzword, but the vast majority seemed to get it. The most popular definition selected from our list was:

"Where the development teams work with the operations teams making it easer to deliver software faster and with better quality"

In fact, DevOps is a general approach rather than a cast-iron set of rules and tools. Common to almost all definitions is the idea of breaking down the artificial barriers between developers and the people that test and run their code for them, barriers that have grown up over the years for reasons that have little to do with operational efficiency.

Tipping points

What are the tipping points? Why would an organisation choose to tear down the physical and metaphorical walls between Dev and Ops with all the upheaval that that might entail?

Aside from the main business goal of speeding up the development lifecycle, many were also seeking to resolve ongoing management headaches.

"When the company realises they just got into this vicious circle of maintenance - constant maintenance and lack of output - this is when they realise that they have to change," said one panellist in a focus group.

"It became obvious that because of the scale of development we were doing we were having problems. We couldn't get them resolved because of the pass-me-around problem," added the CIO of a local authority.

Others felt that they could harness new technologies to start working in a new more collaborative way, or that they could save money by merging departments.

"We were moving our digital platforms into the cloud, so that was the perfect opportunity," said an enterprise architect in the entertainment industry, while a CTO in services spoke of a major clearout of internal infrastructure (and, sadly, staff).

"You needed the guys in the brown overalls changing tapes on a machine and managing the patch cables in the cabinet. Now I use the comms cabinet to hang my cycling gear in," he said.

However, while many people were merging the Dev and Ops roles to remedy existing issues an equal number were doing so in anticipation of future business demands. This was especially the case in large complex organisations for whom it is vital to plan ahead.

"It's problems coming out that weren't anticipated and are difficult to solve. It's that realisation that you could have more and more problems, especially if you are doing more and more development," said the CIO of a local authority.

So CIOs are looking at the big picture, seeing that they need to be more responsive and agile, and are looking to DevOps as at least part of the solution.

Getting started

To dive straight into DevOps would be a mistake. It is a cultural shift that takes time and, importantly, strong leadership to see through, as there are some formidable barriers to overcome. We asked our survey participants what they believed to be the vital ingredients or prerequisites for DevOps to succeed.

It was not surprising to see good management, an evangelical champion and backing from the board all feature high on the list, right after the importance of a clear business objective. DevOps is not something you do for fun, or something you do in isolation. It is very much goals-driven, and without a goal it will fail.

[Next page - the importance of leadership]

Research: DevOps - who, how and why now?

As well as delivering software faster, DevOps has numerous benefits for the IT department, research finds, but strong leadership is essential

Leadership

On the all-important question of leadership, the vast majority of our survey felt that - at the very least - the initial impetus for DevOps has to come from the upper echelons, with most giving that task to the CIO, CTO or other senior technology leader.

However 24 per cent said board level management should lead it, showing the DevOps is far from an arcane IT-department-only endeavour.

The clout that comes with seniority is needed to overcome some pretty engrained attitudes, and while DevOps may offer carrots aplenty to the right people, a little stick is also necessary at times to see through the necessary changes in culture and attitude.

The consensus also had it that someone internal rather than a consultant drafted in would make a better DevOps leader, given that DevOps is often tied into complex and detailed business needs.

That leader needs to protect the team too. Mistakes will be made along the way and the leader needs to fend off criticisms from naysayers and keep the team motivated.

So what are the obstacles likely to face this leader? Well, here are a few for starters.

"Dev people don't really like Ops, let's be honest about that..." said our local authority CIO

On the other side many in Ops feel that developers regard then as box-ticking drones

"You get the impression that the developers' view is along the lines of ‘how difficult can it be, it's just a compute layer, It's just a server, it's just a network layer..." complained an infrastructure strategy architect in retail.

Some Ops staff feel aggrieved that they are the ones woken up in the middle of the night when the developers' poorly conceived code unravels.

"Ops have to deal with poor code coming over the wall that they then have to support. They will get the blame when it all goes wrong," said the CTO, in a software house.

So what's going to happen if you simply tear down the wall? Not a lot, except that Dev and Ops are now within punching distance of each other. This underlines the vital importance of strong management and a clear vision. There can no longer be any hiding behind rules and blaming the other side. Everyone needs to be in it for the long term and everyone needs to be on the same page. There is no turning back.

"Culture is the biggest problem, and it's not a list where you can tick stuff; it's an on-going journey... People don't want to change the way they are doing things, because they don't see outside their team, how that might affect the organisation as a whole. The way to approach this is slowly, iteratively, step-by-step..." advised the platform automation lead in a software firm.

Indeed, resistance to change was a clear winner (or should that be loser?) among barriers to DevOps, although it was joined by siloed mentality and lack of vision towards the top of the list. Interestingly mastering the tools required were not seen as a barrier but lack of skills and finding the right staff were.

Some resistance to change is also due to operatives fearing for their jobs. in this they may well have a point.

"Some of the backroom guys, they're just not going to be appropriate in the new environment. Some sacking and some hiring are going to be necessary...." explained the CIO/CFO in a financial firm.

In technology change is a constant. DevOps is just a part of the new collaborative trend that is sweeping many areas of business, not just the activity of producing software. It is vital to keep up and stay ahead of the game.

Interestingly, when asked what would be the principal benefits of DevOps the most commonly selected answer was "making IT more responsive to the business".

Clearly, by delivering better solutions faster, many IT leaders have an eye on maintaining or improving good relations with their colleagues and ensuring a central role for their department.

"It's the change in perception of the department as well, ICT has always been the people in the basement, that only causes you problems ..." said the head of technology at an NGO.

Revitalising the IT department was mentioned as a secondary benefit by 32 per cent of respondents. Building a versatile team better able to change was the aim of 34 per cent. Creating an exciting and motivating working environment was another perceived knock-on benefit.

"Enthusiasm can lead to someone extending their skillset and in IT we have a lot of people just getting bored doing the same thing, so DevOps could be used as a tool. In the UK we don't have stock options, but you can offer training money," said a senior developer in technology.

Before and after

So what will an organisation look like where DevOps has taken hold? We asked respondents to pick appropriate words from a word-cloud to describe the before and after situations.

For an organisation in which Dev and Ops are separate they picked the following descriptions: "Us and them", traditional, siloed, uncommunicative and unresponsive. Where the Dev and Ops roles are combined the most popular words were collaborative, flexible and dynamic, integrated, responsive and agile.

Perhaps more than any of the statistics presented above, this comparison between the old and new ways of working illustrates where we are going and why.

Sure, for most it is still an aspiration rather than a reality. Certainly it won't be suitable for all organisations, nor will it be appropriate for all development efforts. Some will doubtless try it and fall at one of the many hurdles.

But for many, DevOps is a logical answer to the need for faster and more flexible development practices, and one that fits very snugly with the prevailing collaborative trends.