CIOs don’t know what DevOps is

‘DevOps is not an IT platform but a culture: that’s where it often goes wrong’

It seems that only one of every ten innovative software projects sees the light of day, despite CIOs setting up agile DevOps teams that develop new functionalities at a lightning pace. ‘CIOs have the world at their feet, but become the victim of their own success,’ says Jan Aril Sigvartsen of Basefarm.

As the VP for Public Cloud, Manager for Professional Services & Technology Evangelist at Basefarm, Sigvartsen looks directly behind the scenes at a lot of companies. And although many companies embrace agile principles that enable them to deliver functionalities quickly, he finds they often forget to include security, compliance and cost management in the development process. And because of this, there is often a problem at the transition point from development to operations. ‘The CIO doesn’t really know what DevOps is, and often confuses it with fast releases,’ according to his analysis.

This ship is unsinkable

‘The CIO knows exactly how to use agile principles and technologies to have their developers develop new functionalities quickly. This quickly makes them think in terms of the Titanic’s slogan: this ship is unsinkable. But this often leads CIOs to become the victim of their own success. They only discover that the new software can’t go live according to the operational requirements when they want to convert the new software to operations.’

As an example of how to do it right, Sigvartsen sketches a picture of a project for public transport in Norway. ‘If you only look at innovation and value for the end client, you could imagine it would be handy for the bus driver to see that a frequent passenger is on their way to the bus but is still a minute or two away from the stop based on the GPS coordinates given by the app on their smartphone. The driver can then wait for the passenger, making the experience better for the end client.’

‘But,’ Sigvartsen continues, ‘then you have to consider the fact that it is a civil right in Norway that you can travel anonymously with public transport. So if you want to develop innovations, you can’t just look at innovative features with smart watches and payment information, for example. You have to consider issues around GDPR and legislation and regulations from the beginning. That’s the only way for new developments to actually become operational.’

9 out of 10 CIOs don’t know what DevOps is

The reason development processes stall at the transition from development to operations is related to two problems. First of all, nine out of ten CIOs don’t know what DevOps is, according to Sigvartsen. ‘DevOps, DevSec, DevSecOps: everything is often done by a team made up of only developers.’ Aside from that, Sigvartsen thinks CIOs are only partially to blame for this, because software suppliers have claimed the term DevOps for their platforms. ‘But DevOps is not a tool, process or instruction manual. It’s a culture!’

DevOps, DevSec, DevSecOps… these abbreviations say it all: a good team for software development projects is made up of multiple disciplines. Sigvartsen: ‘Security staff, operational IT staff, service staff, developers, I could go on: all the roles involved in the development process have a place in a good team. This means that everyone has the same KPIs. Not only functional KPIs but also for cost management, compliance and security. It’s about everyone taking care of the whole service lifecycle together, from design through the development process to production and management.’

Management costs too high, code too complicated for the service desk

An example of how a multidisciplinary team provides added value: ‘If we haven’t thought about operationalising software, the costs of stabilising the platform for operations come later. This can make the IT management too expensive. Or the code is too complicated for the first-line IT staff working at the service desk. If an operational IT worker is involved in the development process, a good, operational manual is provided that makes it possible to resolve incidents quickly and therefore cheaply.’

The second problem development teams come up against is related to working with agile principles. Agile can only increase speed if all the processes are agile. ‘It is not recommended only to make developing functionalities agile, and then save security until the last week before going live. This is partially resolved by setting up a multidisciplinary team. This bridges gaps, and security, compliance and cost management are included from the beginning.’

Risks addressed step by step

Internal and external partners will also need to work agile. ‘If internal security employees or for example an external security software supplier are only brought in at the last moment, it is possible that all the hazards and risks will be dumped on the DevOps team at once. That’s bullying. Sometimes it works, but it often actually leads to unnecessary delays. If security is included iteratively, risks can be addressed step by step. It is also done completely in line with the culture of the rest of the team and how they see the future of the application.’

Does that mean that software development projects will never fail if CIOs take Sigvartsen’s tips to heart? ‘No, some projects won’t succeed. Sometimes an innovation just doesn’t work out as well as expected, but the idea is to fail quickly so you spend as little time as possible on dead-ends. You can only achieve this speed if you really work according to agile and DevOps principles. In this way, CIOs might be able to reduce the number of failed projects from nine out of ten to one out of ten.’