{"id":964,"date":"2019-09-22T17:49:12","date_gmt":"2019-09-22T17:49:12","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=964"},"modified":"2019-09-22T17:49:27","modified_gmt":"2019-09-22T17:49:27","slug":"variability-and-devops","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2019\/09\/22\/variability-and-devops\/","title":{"rendered":"Variability and DevOps"},"content":{"rendered":"\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"682\" src=\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2019\/09\/background-21751_1920-1024x682.jpg\" alt=\"\" class=\"wp-image-965\" srcset=\"https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2019\/09\/background-21751_1920-1024x682.jpg 1024w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2019\/09\/background-21751_1920-300x200.jpg 300w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2019\/09\/background-21751_1920-768x512.jpg 768w, https:\/\/janbosch.com\/blog\/wp-content\/uploads\/2019\/09\/background-21751_1920.jpg 1920w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption>Image by PublicDomainPictures from Pixabay\n<\/figcaption><\/figure>\n\n\n\n<p>Many  companies that I work with are in the process of adopting continuous  deployment of software \u2013 or DevOps. As part of that process, the notion  of product variability comes up frequently because there often are  multiple product variants out in the field. The software for each  variant used to be created in a mostly manual process. As a consequence,  most companies do not see a reasonable way to adopt DevOps with that  many product variants requiring frequent software updates. This often  results in significant pressure within the organization to start  reducing the number of variants drastically in order to alleviate the  DevOps challenge.<\/p>\n\n\n\n<p>In my experience, reducing the number of product\n variants indiscriminately isn\u2019t the right way forward. The number of \nvariants shouldn\u2019t be driven by technical limitations or constraints, \nbut rather by business considerations. We should offer those variants \nfor which the variation can provably be monetized. If there are business\n reasons to maintain a variant as the value that it represents outweighs\n the cost of maintaining it, obviously this variant should not be \nremoved. The reality in many companies, of course, is that the product \nvariant space has often evolved over a long period of time and it may \nwell be the case that many variants are outdated and should be removed. \nHowever, once again, this should be driven by business considerations \nand not by technical constraints.<\/p>\n\n\n\n<p>When it comes to technical \nconstraints, the reality is that the way the software for product \nvariants is derived should change and the primary transition called for \nis the shift from customization to configuration. Many companies employ a\n manual customization process to adjust the generic product software to \nthe specific needs of product variants. When the software was released \ninfrequently, eg once per year, this is an acceptable way of working. \nHowever, when employing DevOps, the manual overhead of working in this \nway goes through the roof as we have to manually customize the latest \nversion of the software every few weeks.<\/p>\n\n\n\n<p>The obvious solution is \nto adopt a configuration where the generic software contains the \nsuperset of all functionality that the space of product variants entails\n and where this software can be automatically configured to select the \nspecific variants and features that should be part of a specific \nvariant. Although some companies build bespoke, in-house solutions, \nthere are those, such as Pure Systems, that offer tooling that \nsimplifies this process significantly.<\/p>\n\n\n\n<p>One important aspect to \nrealize is that tools such as those by Pure Systems shouldn\u2019t just be \nused for configuring software, but also for all other assets that need \nto be configured for each product variant, such as product \ndocumentation, requirement specifications, safety documentation, etc. \nThe structured and systematic use of these tools allows for delivering \nproduct variants at much lower cost than manual approaches. The \nconsequence may well be that the company decides to offer many more \nvariants than before because the business benefits for each variant \noutweigh the now significantly reduced cost.<\/p>\n\n\n\n<p>Concluding, the \nadoption of DevOps often leads to a tendency to reduce product variants.\n The number of variants should be driven by business considerations and \nnot by technical constraints. Instead, the company should transition \nfrom using customization to using configuration and adopting automated \ntools to manage the creation of all assets related to each variant. This\n allows for a significant reduction of product variant creation cost and\n supports DevOps exceedingly well. So, don\u2019t kill product variants \nindiscriminately but maintain each variant that adds business value!<\/p>\n\n\n\n<p><em>To get more insights earlier, sign up for my newsletter at<\/em><a href=\"https:\/\/mailto:jan@janbosch.com\/\" target=\"_blank\" rel=\"noreferrer noopener\"><em>jan@janbosch.com<\/em><\/a><em> or follow me on<\/em><a href=\"https:\/\/janbosch.com\/blog\" target=\"_blank\" rel=\"noreferrer noopener\"> <em>janbosch.com\/blog<\/em><\/a><em>, LinkedIn (<\/em><a href=\"https:\/\/www.linkedin.com\/in\/janbosch\/\" target=\"_blank\" rel=\"noreferrer noopener\"><em>linkedin.com\/in\/janbosch<\/em><\/a><em>) or Twitter (<\/em><a href=\"https:\/\/twitter.com\/JanBosch\" target=\"_blank\" rel=\"noreferrer noopener\"><em>@JanBosch<\/em><\/a><em>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Many companies that I work with are in the process of adopting continuous deployment of software \u2013 or DevOps. As part of that process, the notion of product variability comes up frequently because there often are multiple product variants out in the field. The software for each variant used to be created in a mostly &#8230; <a title=\"Variability and DevOps\" class=\"read-more\" href=\"https:\/\/janbosch.com\/blog\/index.php\/2019\/09\/22\/variability-and-devops\/\" aria-label=\"Read more about Variability and DevOps\">Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/964"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=964"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/964\/revisions"}],"predecessor-version":[{"id":966,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/964\/revisions\/966"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=964"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=964"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=964"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}