{"id":1036,"date":"2020-02-21T15:28:59","date_gmt":"2020-02-21T15:28:59","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1036"},"modified":"2020-02-21T15:29:00","modified_gmt":"2020-02-21T15:29:00","slug":"dont-build-new-platforms","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/02\/21\/dont-build-new-platforms\/","title":{"rendered":"Don\u2019t build new platforms"},"content":{"rendered":"\n
\"\"
Image by kenjylee from Pixabay\n<\/figcaption><\/figure>\n\n\n\n

During the last months, I\u2019ve met with several companies that had an interesting common denominator: they were all building a new platform to replace a legacy platform and things weren\u2019t going so well. The legacy platform often is decades old and has functionality in it that\u2019s the result of hundreds of person-years of effort. And it typically forms the basis for a significant part, if not the entire, product portfolio.<\/p>\n\n\n\n

When the new platform effort is initiated, the organization accepts \nthat it will take some time (years) to build it to a point that it can \nreplace the legacy platform. As stalling the product portfolio is \nunacceptable, there will be a continuous flow of development effort into\n the old platform to realize the features that are needed right now. \nThis, of course, happens in parallel to the new platform effort. The \nconsequence is that the goal for the new platform becomes a moving \ntarget as the legacy platform is continuously adding new functionality \nthat the new platform will need to add as well in order to achieve \nfeature parity.<\/p>\n\n\n\n

There are three possible outcomes in this scenario. The first is also the worst: the new platform effort forever fails to achieve feature parity. As a consequence, no product line is willing to move over to it. At some point, there\u2019s a change of management, the new platform effort is reviewed and the track record to date leads to an obvious conclusion: the new platform is canceled. The result is that the company is stuck with the old platform and has lost years of time and hundreds of person-years of R&D effort without any business benefit.<\/p>\n\n\n\n

Second, the platform effort starts to be used by one product line and\n becomes the de-facto platform for only a part of the portfolio. For \nproduct management, the choice between building functionality for a \nproduct that\u2019s here now or a potential product in the future very often \nfalls in favor of the existing product. When this happens continuously, \nit results in the platform becoming increasingly optimized for the \nspecific product line and getting further and further behind for the \nother product lines. This could be viewed as a way for one product line \nto hijack general R&D resources for its own purposes, which makes it\n very attractive as a strategy in companies with a strong focus on teams\n delivering in their own area of responsibility without maintaining \nresponsibility for the success of the company overall.<\/p>\n\n\n\n

The third situation is where senior R&D and business leaders \nunderstand these patterns and force the organization to abandon the \nlegacy platform and adopt the new one. This often leads to significant \ntension as product lines are asked to put out new products with reduced \nfeature sets. The discussion typically leads to many requests to perform\n \u201csmall\u201d maintenance efforts on the old platform in response to customer\n requests and other, highly viable, reasons. In general, many in the \nR&D organization will fight for staying on the old platform as long \nas possible. In the worst case, the legacy platform will never be \nsunsetted and the platforms continue to exist next to each other for \nyears or even decades.<\/p>\n\n\n\n

The fundamental reason behind these scenarios is a mechanical mindset\n by leadership. The notion of having generations of platforms may make \nsense in mechanics and electronics (although these platforms would \nbenefit from continuous evolution as well), but software is different. \nOur research shows that there\u2019s no correlation between system age and \nthe level of technical debt, meaning that new systems and old ones have \nsimilar amounts of requirements for technical debt management.<\/p>\n\n\n\n

Rather than thinking in terms of platform generations, the focus \nshould shift to a continuously improving platform with a constant flow \nof refactoring effort keeping it current from a technology and \narchitectural perspective. Instead of allowing an existing platform to \nsink in the morass of commodity and irrelevance, organizations should \nlook to continuously invest some percentage (10-25 percent) into the \nplatform to ensure it never has to be replaced by a next generation.<\/p>\n\n\n\n

Concluding, building new platforms to replace existing ones is a highly risky R&D initiative fraught with challenges. Instead, commit to continuously investing a part of your R&D resources in refactoring your existing platform. The best platform is one that never has to be replaced because it\u2019s always current and up to date. Because you committed to keeping it that way!<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

During the last months, I\u2019ve met with several companies that had an interesting common denominator: they were all building a new platform to replace a legacy platform and things weren\u2019t going so well. The legacy platform often is decades old and has functionality in it that\u2019s the result of hundreds of person-years of effort. And … 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\/1036"}],"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=1036"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1036\/revisions"}],"predecessor-version":[{"id":1038,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1036\/revisions\/1038"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1036"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1036"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1036"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}