The software industry often seems to live in dichotomies and contrasts: business against developers, developers against testers, designers against business and so on, towards infinity and beyond. When a particular activity within the software lifecycle and workflow is identified and codified, then arises the need to differentiate itself from the rest. This is how, over time, the two distinct phases of “development” and “operation” first came to contrast, then reconciled thanks to the intuitions of the DevOps movement.
The spread of the word DevOps, however, has led to a weakening of its real importance and usefulness. In fact, although the initial intent was to offer a culture and the tools to allow two people, a “dev” and an “ops”, to cooperate to get a working product, it is not rare to run into situations where companies are looking for people that do DevOps or where it is considered sufficient for developers to learn and to use some tools to have a DevOps workflow.
These situations are often linked to the lack of understanding of what actually are the activities of “operations” people and the little importance given to the “software operability” over “software functionalities”. Marco Abis, in his speech at Codemotion Milan 2018, wanted to retrace some salient features of the DevOps culture and the importance that software operability plays.
While it’s not easy to define and use the word “DevOps” – is it an adjective or an adverb? is there a DevOps person or DevOps teams? – it could be more effective to start talking about “operability”.
We can define (software) operability as a measure of how well a software system works in a production environment, for both end-users and operations teams. There are many advantages of a software system with good operability, including of course the simplicity of management, diagnosis and recovery in the production environment.
The path to good operability, however, could require some changes on how the whole team approaches product development. For example, a good starting point could be to avoid the historical distinction between functional and non-functional requirements. Even excluding the negative semantic connotation of the term “non-functional requirements”, it is more correct to speak in terms of “end-user features” and “operational features” and to give equal importance to both. Just as it is important to be in the conditions of checking and testing, for example, the user stories “as a customer, I want to buy a product”, in the same way it must be possible to verify and test the user story “as ops, I want to switch a feature”.
The same approach can be applied to any operational activity: deployment, monitoring, status checking, reconfiguration, dependency management and capacity planning, just to name a few.
Paraphrasing what is often said about the quality of software, the same principle applies to operability: you cannot test or inspect operability, you must build it in.
There are several core operability concepts and features that are important to have in a software system:
The ways in which to carry out the actual implementation and improvement of the operability of your software may depend on the effective capacity of the team. Marco Abis reported in his talk some suggestions that are summarised in the following slide. In any case, it is essential to treat software operability as a first-class citizen of a product and to treat “ops” as a high skill.
Software operability is becoming more and more important nowadays, due to several factors. Hardware infrastructures are moving to PaaS clouds or containerised systems, reducing the rollout times of the infrastructures themselves. The business requires fast development times and faster changes. Software architectures are moving away from monoliths and to increasingly distributed and complex structures.
All this makes the potential of an error greater and more able to guarantee a quick intervention that is more vital than ever.