Traditional ISVs (and legacy software products) are in a death spiral
The traditional ISV (Independent Software Vendor) business model of installing and supporting on-premise based software products, and revenue model based on licensing is fast becoming extinct. Thanks to the impact of digital accelerating technologies (SMAC, IoT, AI, etc.), virtually every business is becoming a digital business, and embracing technology as well as business model transformation to be competitive and relevant. Cloud adoption and moving to a SaaS-based on-demand, subscription model for software services is a key component of digital transformation.
Gartner estimates the worldwide public cloud services market to be around $246.8 billion in 2017, and forecasts it to touch $383 billion by 2020, and projects that the Cloud application services (SaaS) market will double between 2016-20, and cross $75 billion. Gartner further states:
“ As enterprise application buyers are increasingly adopting a cloud-first approach, new software investments by large vendors are shifting from a cloud-first to a cloud-only approach.”
At this pace, it is very clear that any traditional ISV that fails to modernize will be dead and extinct by 2025, if not sooner. In this blog, I would like to focus on the challenges that typical ISVs face in their modernization quest, and outline some of the potential modernization strategies.
What is the future of software products?
Let’s examine the cumulative impact of technology and business model disruption on software products and ISVs who build them. Some broad trends are clearly emerging:
- Every software product will be delivered and consumed as Software as a Service (SaaS), and enterprise software is transforming into enterprise SaaS.
- In an increasingly platform-centric world, every software product will be part of a platform either as a producer, consumer, or match-maker. In this platform landscape, configurability, integrations, and functional richness in terms of ability to support multiple business processes will become key product considerations.
- Monolithic architectures and standalone applications will be obsolete; Micro-services based architecture and digital native applications will be the norm.
- The ‘Independent’ in ISV is fast becoming an oxymoron, in an increasingly connected and interdependent landscape.
- With the widespread adoption of utility computing and SaaS, enterprises (consumers of software products) are moving from a Capex to an Opex mode.
- Unprecedented customer expectations are giving rise to demand for ubiquitous computing – anytime, anywhere, any device access; scalable performance and consumer grade UX/DX/CX in enterprise SaaS applications.
What’s stopping ISVs from modernizing?
Even when it is widely acknowledged that the business case for technology modernization is established beyond a reasonable doubt, what is holding back traditional ISVs from modernizing their software products?
Legacy technologies and outdated skills: the ISV landscape is dotted with hundreds and thousands of software products which still run on legacy technology stacks such as Power Builder, Progress, Delphi, FoxPro, COBOL and VB etc. Often, these products have a monolithic and tightly coupled architecture, which makes it very difficult to maintain and support them. But unfortunately, the outdated skillset of the engineers and developers who have built and supported these products, is one of the biggest stumbling blocks in the ISVs quest for modernization. Often, these engineers who have tremendous expertise in various legacy technologies, don’t have the much-needed skills in emerging technologies, which is key for any modernization effort.
Trapped by sunk cost syndrome: it is usually the case that, the ISV might have invested significant time, money, and resources (sunk costs) in developing enterprise class software products/applications. Even when it is evident that the technology is obsolete and the product has no future, some ISVs continue to waste money on a clearly losing proposition. Businesses are often trapped by a sunk cost syndrome, get emotionally attached to the product or project (stickiness to what we have), and find it difficult to think objectively about future.
Myopic worldview and don’t fix what’s not broken: I have frequently come across some very successful ISVs, who feel that they have a stable customer base which is happy with their products, continue to pay licensing and support fee, and is not complaining. The logic of these ISVs is, if their customers are happy, not demanding a change, what’s the incentive for them to modernize? In other words, in their myopic worldview, don’t fix what’s not broken.
“ The global business landscape is littered with many giants who were once undisputed leaders, yet failed to anticipate future market needs and technology trends, and became irrelevant in the blink of an eye, as nimble-footed competitors displaced them with superior products and services.”
Fear of failure and risk aversion: There is also a deep-seated perception that modernization of technology products is an inherently risky exercise with lots of uncertainties. It is often the case that, the ISV might be unsure of the right modernization strategy, lacks the wherewithal to make the appropriate technology/architectural choices, and could be simply lacking the capacity and resources to execute. For a multitude of reasons, risk-aversion, fear of failure, and fear of the unknown – all come together in keeping any discussion on modernization off the table.
Choice of technology platform and application architecture
Once the decision is taken to modernize a legacy product/application, one of the key challenges that ISVs encounter is in choosing the target technology platform and application architecture. From a future-proofing perspective, ISVs would be wise to consider a modernization approach that will deliver digital native applications. While there is no one-size fit all kind of an approach, the chosen technology stack and architectural framework must consider the following factors:
- Scalability: rapid scalability (on-demand), performance, and security
- Availability: must support always on access (24×7), continuous availability, and uptime
- Adaptability: flexibility to change, ease of configuration, and modularity
The infographic shown below, depicts some of the widely-used software stacks and architectures in traditional applications, and lists the architectural principles and choice of technology stacks/frameworks for digital native applications.
The choice of modernization strategy will be dictated by multiple factors including (but not limited to) the current software stack, application architecture, target architecture and technology frameworks, hosting environment, resource availability, timeframe etc. Based on these factors, one may choose a modernization strategy that best serves their needs, which could range from an automated (tool-enabled migration) process, to manual processes such as re-platforming, re-hosting, refactoring, re-architecting, re-engineering,and replacement.
Modernization and transformation are key to avoid the ISV death spiral
In a fast-changing technology landscape, where digital disruption is the norm, status quo is not an option for a traditional ISV, as it will lead to irrelevance, extinction, and a certain death. To avoid this death spiral, ISVs must embrace technology modernization and transform their legacy software into digital native applications, that can be deployed either as an enterprise SaaS or as part of a digital platform