{"id":1403,"date":"2022-02-02T09:53:32","date_gmt":"2022-02-02T09:53:32","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1403"},"modified":"2022-02-02T09:53:34","modified_gmt":"2022-02-02T09:53:34","slug":"platform-lesson-6-control-platform-variability","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2022\/02\/02\/platform-lesson-6-control-platform-variability\/","title":{"rendered":"Platform lesson #6: Control platform variability"},"content":{"rendered":"\n
\"Image
Image by Ben Kerckx from Pixabay<\/figcaption><\/figure>\n\n\n\n

Software platforms by their very nature support multiple products. Typically, these products are used in different contexts and configurations. As a consequence, the platform has to offer variation points that allow each product and customer to use the platform in the way that best suits their purposes. Each variation point then has two or more variants that can be selected in that variation point or has configuration settings that allow the user of the platform to influence platform behavior. In addition, the platform often offers extension points where the product team or the customer can build custom extensions.<\/p>\n\n\n\n

Although a simple and beautiful concept, it\u2019s very easy to cause significant practical challenges. Most platforms I\u2019ve been involved in have thousands, tens of thousands or even more than a hundred thousand variation points. There are several reasons for this. First, when a customer asks for a point of variation and it becomes part of a sales negotiation, it\u2019s very tempting to accept the request and just carry the cost of introducing the variation point as part of the \u201ccost of goods sold\u201d line item. Second, product teams can easily demand that certain variation points be included as a precondition for getting or staying on the platform. Third, engineers are by their nature optimizers and identify, for each feature or functionality, the parameters that can be tuned. That often results in several variation points to be added for each feature in the platform.<\/p>\n\n\n\n

When left unchecked, the number of variation points tends to explode. The resulting complexity is phenomenal and causes significant extraneous costs when adding features and when testing the platform. Many variation points have dependencies on other variation points, resulting in a combinatorial explosion of configurations that often cause post-deployment issues as it\u2019s impossible to test all variations. Most companies only focus on the cost of introducing a variation point but fail to recognize the downstream cost for maintenance, testing and managing inter-dependencies.<\/p>\n\n\n\n

\"Three<\/figure>\n\n\n\n

One model that\u2019s very helpful in controlling platform variability is the Three Layer Product Model (3LPM). It organizes functionality into a commodity layer, a differentiation layer and an innovation and experimentation layer. The rule of thumb is that we seek to keep innovative and experimentation functionality outside the platform until it has proven itself as being valuable<\/a>. In the differentiation layer, we allow for value-adding variation points to be included, whether these are configuration parameters, variants or extension points, as we seek to maximize the value for the customers of the platform. Finally, in the commodity layer, we seek to actively reduce the number of variation points. This includes the refusal to add new variation points in that functionality but also the removal of variation points that have outlived their usefulness.\u00a0\u00a0<\/p>\n\n\n\n

The largest contributor, in my experience, to unmanageable amounts of variation points is the absence of variation point removal efforts. Naively, one may easily assume that an existing variation point, once introduced, has no associated cost. In practice, however, for each variation point, a constant \u2018tax\u2019 is paid that has to be outweighed by the value generated for customers and the company. For commodity functionality, this value is often missing or significantly reduced. Consequently, as part of technical debt management, we need to continuously allocate resources for the removal of variation points that have outlived their usefulness.<\/p>\n\n\n\n

The challenge with removing variation points, as well as features and other functionality, is that the company often doesn\u2019t know whether they\u2019re in use by customers. This is why instrumentation of the platform is so important. It allows us to make data-driven decisions on variation points as well as features that are no longer used. We can then proactively work with the few customers who are still using them to help them transition.<\/p>\n\n\n\n

Platform variability needs to be carefully controlled as it leads to significant costs and many post-deployment quality issues due to the combinatorial explosion of inter-dependent variation points, variants, configuration parameters and extensions. Controlling platform variability has two main activities. First, the introduction of new variation points needs to be carefully evaluated and only focused on the differentiating functionality. Second, we need to proactively remove variation points that no longer provide sufficient business value. In many cases, the quote of Henry T. Ford provides the right answer: \u201cYou can have any color you want, as long as it\u2019s black.\u201d<\/p>\n\n\n\n

Like what you read? Sign up for my newsletter at\u00a0<\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Software platforms by their very nature support multiple products. Typically, these products are used in different contexts and configurations. As a consequence, the platform has to offer variation points that allow each product and customer to use the platform in the way that best suits their purposes. Each variation point then has two or more … 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":[4,8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1403"}],"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=1403"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1403\/revisions"}],"predecessor-version":[{"id":1405,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1403\/revisions\/1405"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1403"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1403"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1403"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}