Thursday, January 6, 2011

Legacy Applications and Technology Change

It is not necessary to change. Survival is not mandatory. ~W. Edwards Deming

Independent Software Vendors (ISV's) inevitably, and then repeatedly, grapple with application technology changes. Sometimes these changes are modest, new compiler or component upgrades that need to be fit into the product road map. Sometimes these changes are better described as paradigm shifts, mandating significant changes in products and practices and in most cases absconding the product road map. Examples of such changes include the introduction of .NET and the move to Software as a Service model, or cloud computing.

Although in each case, as with paradigm shifts in other industries, the impact to the those products lagging behind is not immediately fatal, users of these applications demand that the laggers be provided a lifeline, to continue operating at least until the vendor has enough time to adapt the product to the new paradigm or the customer has enough time to find a replacement. Eventually, if the ISV does not adapt to the new technology the product begins to suffer, the user interface may begin to look outdated, performance may suffer, integrations with other applications that have adapted may become impossible, opportunities for the product to expand in it's market or enter attractive adjacent markets.

The business case to adapt the product becomes the focal point and sometimes the paralysis point of the action plan. This is development cost hoisted onto the unfortunate unsuspecting ISV by forces outside of its control, but it is the price of doing business in the commercial software industry.

For product lines where there is a critical revenue stream based on a renewal rate associated with periodic or annual updates, tax preparation products tied to state or federal legislation are an example, the paralysis can be severe and the stakes very high. For these products absconding the roadmap is not feasible, since the majority of the roadmap has nothing to do with features or technology, but everything to do with updating business rules and calculations with legislative changes. As an example of the effort involved, the IRS recently blamed congress for delaying the filing season by passing the recent tax law changes so late in the year, claiming they will need time to reprogram computers forcing refund processing to be delayed until mid-to-late February. So for these ISV's the strategy is to reduce the legacy roadmap to the minimal legislative changes to secure the renewal revenue, jettison all features, and stand up a new development team to work on the next generation application, merging the tax law changes back in before shipment. This of course is an expensive and risky proposition, but a necessary one.
For those ISV's that aren't bound by update timing the strategy if much more straight forward.

In either case the resource issues are similar, new technology, new skills, new designs, new metaphors, new environment new opportunity. It's time to retool and think outside of the box again, the process can be rejuvenating for an organization but it can also lead to some internal tension and critical market mistakes.

Internal tension can occur between the legacy group and the next generation group for obvious reasons. Keeping cross communication channels open and communication events frequent and meaningful can remedy this situation. Also providing a clear skills development path for the legacy developers to join the next generation team is key.

The most common market mistake is to overshoot the current market. Even though the application technology paradigm shift has occurred, rocking the foundation of the product line, doesn't necessarily mean the same thing has happened to your customers, they may be perfectly happy with what they have. And because the next generation product may take some time to build, there is a danger of undershooting where the market will be when the product if finally shipped. A mentor of mine, Jim Petersen - founder and CEO of Best Software (later purchased by Sage Software),used to say, "shoot the puck to where you customer is going, not where they are now". This is critical for the current customer base, but even more important for the prospect customers and markets.

After you've done a thing the same way for two years, look it over carefully. After five years, look at it with suspicion. And after ten years, throw it away and start all over. ~Alfred Edward Perlman, New York Times, 3 July 1958

No comments: