{"id":1614,"date":"2021-08-06T10:14:54","date_gmt":"2021-08-06T10:14:54","guid":{"rendered":"https:\/\/tomgeraghty.co.uk\/?p=1614"},"modified":"2023-08-11T12:47:00","modified_gmt":"2023-08-11T12:47:00","slug":"resilience-engineering-devops-adoption-and-adaption","status":"publish","type":"post","link":"https:\/\/tomgeraghty.co.uk\/index.php\/resilience-engineering-devops-adoption-and-adaption\/","title":{"rendered":"Adoption vs Adaption in Resilience Engineering and DevOps"},"content":{"rendered":"<p class=\"p3\">DevOps was, and still is to a degree, a \u201cground-up\u201d phenomenon. It became to be adopted, adapted and evolved by engineering teams before \u201cmanagement\u201d even really understood what it was.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p class=\"p3\">The openness and flexibility that was expounded by <a href=\"https:\/\/tomgeraghty.co.uk\/index.php\/the-history-and-evolution-of-devops\/\">DevOps<\/a> meant that it was able to be interpreted in different ways by different teams in different contexts. This was a key strength, because unlike rigid frameworks such as ITIL, the people responsible for doing the work were able to modify and apply DevOps to their own work, in the ways that best suited them.<\/p>\n<p class=\"p3\">But this loose definition also proved to be a weakness. Because there were no limits to how DevOps could be interpreted and applied, it was often (and still is) interpreted as a technology solution rather than cultural change. This resulted in \u201cDevOps engineers\u201d, or \u201cDevOps teams\u201d whose remit is focussed on cloud technology, CI\/CD pipelines, or automation.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p class=\"p3\">Due to this, we\u2019re still far behind from where we could have been as an industry. Despite everyone in technology knowing the term \u201cDevOps\u201d and almost every firm adopting some degree of DevOps practices, these transformations have often stuttered or even failed, in part because it\u2019s unclear to many what DevOps really is and how to \u201cdo\u201d DevOps.<\/p>\n<p class=\"p3\"><a href=\"https:\/\/tomgeraghty.co.uk\/index.php\/resilience-engineering-and-devops\/\">Resilience Engineering<\/a> is a field of applied research that considers organisational-scale capability to anticipate, detect, respond and adapt to change. The principle of socio-technicality is core to RE: the premise that you can\u2019t separate people from technology; if you change the technology, it will affect people, and if you change the way people work or communicate or the way teams are structured, it will impact the technology created or consumed by those people.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p class=\"p3\">RE as a field has been around for almost two decades, but only now (for various reasons including the Covid pandemic) is beginning to touch mainstream discussions and discussed in the same conversations as <a href=\"https:\/\/tomgeraghty.co.uk\/index.php\/digital-transformation-and-enterprise-agility\/\">digital and organisational transformation.<span class=\"Apple-converted-space\">\u00a0<\/span><\/a><\/p>\n<p class=\"p3\">Researchers and Practitioners of RE are quick to clarify what RE is, and is not, during these discussions. Whilst it may seem dogmatic to be so strict about what is within the remit of the field, I think this could be the valuable lesson learned from one of the weaknesses of DevOps. In order for organisations to successfully adopt and adapt to a new operating model and principles such as RE, it\u2019s essential to understand very clearly what it is.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p class=\"p3\">Resilience Engineering, despite being nearly twenty years old as a field, is somewhat embryonic in its adoption outside of a narrow field of specialist researchers and practitioners, and as such, it\u2019s crucial that we define accurately what it is, what it is not, and resist attempts (intentional or unintentional) to co-opt the term to mean something more akin to chaos engineering, automation, or system hardening efforts.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p class=\"p3\">A balance must be struck between defining accurately what RE is, and tolerating (indeed, encouraging) a flexibility of interpretation and adoption in different contexts. DevOps was maybe too loose in this respect, other paradigms such as ITIL or SAFe were maybe too strict and dogmatic. Maybe with Resilience Engineering, the sweet spot will be found.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>DevOps was, and still is to a degree, a \u201cground-up\u201d phenomenon. It became to be adopted, adapted and evolved by engineering teams before \u201cmanagement\u201d even really understood what it was.\u00a0 The openness and flexibility that was expounded by DevOps meant that it was able to be interpreted in different ways by different teams in different &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/tomgeraghty.co.uk\/index.php\/resilience-engineering-devops-adoption-and-adaption\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Adoption vs Adaption in Resilience Engineering and DevOps&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":2131,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,4],"tags":[],"class_list":["post-1614","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-tech"],"_links":{"self":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/1614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/comments?post=1614"}],"version-history":[{"count":4,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/1614\/revisions"}],"predecessor-version":[{"id":1621,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/1614\/revisions\/1621"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/media\/2131"}],"wp:attachment":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/media?parent=1614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/categories?post=1614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/tags?post=1614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}