Numerous factors are tied to determining a software technology company’s valuation and these are generally very well understood. However, ever-tightening due diligence against a portfolio’s complete technology stack can have a significant negative effect on this critically important financial determination.
Unmanaged third-party dependencies; a heavy reliance on poorly maintained or even abandoned open-source components; fragmented, outdated and monolithic product architectures; little-to-no automation testing; APIs (if they even exist) built “after the fact”; incompatibilities affecting any aspect of maintaining, deploying and running software; etc., are just some examples that increases risk and cost for investors, assessing candidate acquisitions. This is compounded when multiple products each exhibit unique variations of “technical debt” further complicating business integration, expansion, and growth modeling scenarios. Risk, uncertainty, and elevated operational costs tied to older product portfolios immediately drag company valuations down (often by millions of dollars).
Many organizations face challenges related to older software. Historically, efforts to overcome technical debt (principally aimed at modernizing these products) have proven to be costly, extremely time-consuming, and very expensive. A majority of these efforts either result in an abandoned project or in outright failure1. According to global research from Advanced, nearly three quarters of organizations (74%) that have started a legacy system modernization project, failed to complete it.
One poorly understood detail that organizations rarely consider is the inconsistencies – or differences – of the tech stacks underpinning the various products of a given portfolio. Even when individual products are relatively “healthy”, the organization as a whole is still riddled with excessive overhead when different products are built differently, are managed by different teams with different coding styles and source code management practices, have different deployment needs, or have different states of maturity. These differences all add up and impact the current state and future business opportunities of companies being considered for acquisition.
The lack of a standardized, reference product architecture is yet another dimension of technical debt. The consequences of this prevalent condition extend to external customers, partners, and analysts alike. It’s harder to sell additional standalone products into an existing customer base than it is to license additional modules of a single, multi-functional solution. Complexity hampers expansion and growth opportunities – like it or not. This detail won’t be overlooked by investors and serves as yet another potential impact on valuations that software companies should be aware of.
Aspen ESS was founded to specifically help standardize product technology stacks (as part of our App Modernization strategy) as well as potentially rationalize individual products inside single, richer enterprise solutions. Welcome to Aspen’s Warp Drive Development Engine™.
If you would like to learn more about our approach to App Modernization and Portfolio Rationalization, contact us at info@aspeness.com or visit our website at https://www.aspeness.com/.
Todd Ingersoll
With over 20 years of experience serving multiple roles inside successful enterprise software and services organizations, Todd has been expressly interested in successfully overcoming app modernization challenges. His first-hand experience and dissatisfaction with the limitations and business impact of the traditional options of application modernization led him to create Aspen ESS.
References
1 – 74% Of Organizations Fail to Complete Legacy System Modernization Projects, New Report From Advanced Reveals – Business Wire (May 28, 2020)
