{"id":182,"date":"2020-09-02T10:50:00","date_gmt":"2020-09-02T08:50:00","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/software-operability-a-devops-cornerstone\/"},"modified":"2022-01-05T20:05:55","modified_gmt":"2022-01-05T19:05:55","slug":"software-operability-devops","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/devops\/software-operability-devops\/","title":{"rendered":"Software Operability: a DevOps Cornerstone"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. What are DevOps?<\/a>
  2. It takes two to DevOps<\/a>
  3. How and why: focus on operability<\/a>
  4. Want to launch a developer event despite the challenges of COVID-19?<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

    The software industry<\/span> often seems to exist in a world of dichotomies and contrasts: business<\/span> against developers<\/span>, developers<\/span> against testers, designers<\/span> against business<\/span>, and so on – towards infinity and beyond. <\/p>\n\n\n\n

    When a particular activity within the software lifecycle<\/span> and workflow<\/span> is identified and codified, the need to differentiate itself from the rest then arises. <\/p>\n\n\n\n

    This is how, over time, the two distinct phases of ‘development’ and ‘operation’ first arose – initially contrasting, but eventually reconciled thanks to the intuition of the DevOps<\/span> movement.<\/p>\n\n\n\n

    What are DevOps?<\/h2>\n\n\n\n

    However, the spread of the word ‘DevOps<\/span>‘ has led to a weakening of its real importance and usefulness. <\/p>\n\n\n\n

    In fact, although the initial intent was to offer a culture and the tools<\/span> that would allow two people<\/span> – a ‘dev’ and an ‘ops’ – to cooperate to create a working product<\/span>, it is not unusual to encounter companies<\/span> that are looking for people<\/span> to do DevOps<\/span> as a singular construct, or where developers<\/span> learning and using some tools<\/span> is considered sufficient to have a DevOps<\/span> workflow<\/span>.<\/p>\n\n\n\n

    \"Without<\/a><\/figure><\/div>\n\n\n\n

    These situations are often linked to a lack of understanding of what the activities of ‘operations’ people<\/span> actually are, and the low importance given to ‘software operability’ in comparison with ‘software functionalities’.<\/p>\n\n\n\n

    In the upcoming Codemotion<\/span> conference, to be held online<\/span> on October 20, 21, and 22, 2020, the topic of DevOps<\/span> will be addressed widely in numerous talks (you can find the schedule here<\/a>). Not for the first time, our speakers will retrace some salient features<\/span> of the DevOps<\/span> culture, and the importance of software operability.<\/p>\n\n\n\n

    It takes two to DevOps<\/h2>\n\n\n\n

    As it’s not easy to define and use the word ‘DevOps<\/span>‘ – is it an adjective or an adverb? Is there a DevOps<\/span> person or a DevOps<\/span> team? – it might be more effective to start talking about ‘operability’.<\/p>\n\n\n\n

    We can define (software) operability<\/span> as a measure of how well a software system<\/span> works in a production environment<\/span>, for both end-users and operations teams. <\/p>\n\n\n\n

    There are many advantages in having a software system<\/span> with good operability<\/span>, including of course the simplicity of management<\/span>, diagnosis, and recovery this offers in the production environment<\/span>.<\/p>\n\n\n\n

    However, the path to good operability<\/span> could require some changes in how the whole team<\/span> approaches product development. For example, a good starting point might be to avoid the historical distinction between functional and non-functional requirements<\/span>. <\/p>\n\n\n\n

    Even without the negative semantic connotation of the term ‘non-functional requirements<\/span>‘, it is more accurate to speak in terms of ‘end-user features<\/span>‘ and ‘operational features<\/span>‘, giving equal importance to both. Just as it is important to be able to check and test user<\/span> stories – “as a customer<\/span>, I want to buy a product<\/span>“, for example – it must be possible to verify and test the user<\/span> story “as ops, I want to switch a feature<\/span>” in the same way.<\/p>\n\n\n\n

    \"DevOps:<\/a><\/figure><\/div>\n\n\n\n

    The same approach can be applied to any operational activity: deployment<\/span>, monitoring, status checking, reconfiguration, dependency management, and capacity planning, to name just a few.<\/p>\n\n\n\n

    How and why: focus on operability<\/h2>\n\n\n\n

    Paraphrasing what is often said about the quality<\/span> of software<\/span>, the same principle applies to operability<\/span>: you cannot test or inspect operability<\/span>, you must build it in.<\/p>\n\n\n\n

    There are several core operability<\/span> concepts and features<\/span> that are important to have in a software system<\/span>:<\/p>\n\n\n\n