Please don’t throw things at me!
It sounds a bit odd but I’ve come to the conclusion that DevOps is fun but non-functional. Before you start throwing rotten tomatoes at me, as was the case with one of my other DevOps blogs, Kill DevOps, please let me explain.
There aren’t many decent definitions of DevOps around but Gene Kim says nails it as far as I’m concerned. He says that DevOps is “the set of cultural norms, technical practices and architecture that enable organizations to have both a fast flow of work from development to deployment, as well as world-class reliability, availability and security” (of information systems and IT services).
Resilient, secure and fast
Gene, is one of the co-authors of The Phoenix Project and the long-awaited and recently published DevOps Handbook. The Handbook builds on Gene’s definition and describes technical practices in four categories: (1) flow, (2) feedback, (3) continual experimentation and learning, and (4) integrating information security, change management, and compliance into the software development lifecycle.
Most of the core technical practices focus on things continual:
- Continuous integration: frequently synchronize developer’s working copies with the shared mainline version
- Continuous testing: automatically test to obtain immediate feedback on risks
- Continuous delivery: ability to always put a product into production
- Continuous deployment: automatically deploy into production whenever product passes QA
Unsurprisingly, this is consistent with what Gene’s definition emphasises: getting resilient, secure and compliant software into production quickly.
Improving IT performance
This corresponds with how the prestigious State of DevOps Report describes performance of the IT function in terms of deployment frequency, lead time for changes, mean time to recover, and change failure rate. The report also talks about cost savings that can be spent on value-add activities, and how DevOps practices also improve organizational culture and enhance employee engagement. In ad industry where the pressure of work can lead to serious issues, it’s good to read that high performing IT organizations have employees who in 2016 were 2.2 times more likely than average to recommend their organization to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend as a great working environment. In other words, DevOps is not only about speed of change, operational behaviour (reliability and availability), security, and cost – it’s also about fun. These points are well-aligned with The DevOps Handbook’s focus.
A focus on ‘non-functionals’
So DevOps addresses most of the non-functional qualities of software, and does that very well indeed, but none of the practices seem to concern themselves with determining what functionality is required. This seems to define the ‘upstream’ boundary of DevOps: once the functional requirements have been established, then DevOps’ technical practices can be applied. While many of DevOps’ generic cultural norms can and should be applied to domains of activities outside the ‘continuous’ domains, as far as concrete technical practices are concerned, they focus on the non-functionals.
