Application software as a product has very short shelf life. In a typical product, one goes through conceptualize, construct, QA, bug fixing cycle and one fine day it goes LIVE. Suddenly, there is mayhem with customers digging out issues QA never found, demanding features never signed off but are critical, reporting issues not reproducible in staging / development.
Eventually everything settles down with issues either fixed or workarounds provided. There are happy customers getting business benefits supported by happy developers providing enhancements for life. Right? Wrong after a lull period everyone starts complaining again.
Customers complain they are not getting required benefits from application; new features are breaking existing components. Technical supports guys complain that the workarounds are irritating; components just freeze at peak load. Developers complain it takes ages to deliver simple enhancements. And the list goes on.
Hence start talks of retiring and rebuilding application from scratch. Since everyone is unhappy it should be easy to decide in favor of retiring legacy application. Right? Wrong; I have never found it easy to retire a running application. I always find it better to rebuild specific components incrementally.
I find it tough to take a decision on retiring application and suppose everyone faces similar dilemma. Every situation is unique and decision will differ from project to project and client to client. I have a checklist of items to look for while deciding to retire or rebuild an application. I hope it would be helpful to someone making similar decision:
Desktop to web application
You have a desktop application developed couple of years back for target customers. There is great feedback and everyone is telling you about its great potential and how you should reach out. You learn about benefits of SaaS offerings but cannot move forward since application is not web enabled.
It is easy to decide to move to web enabled application but complexity arrives with possible choices. I worked on a project where client had a swing based desktop application that needed to be web enabled. We mulled on options to make it either browser based using Applet – Servlet communication / JWS or make it complete web application by rewriting complete solution using MVC framework. In that case we decided to go with JWS route since client was unsure of quantum of benefits and wanted to go live soon with minimal cost.
Problems with one layer
You have an application with multi-tiered architecture and majority of problems are reported in one layer. In this case we need to make a decision to improve or retire-rebuild this layer.
I worked on an application where problems were specific to Presentation layer. In that case, we replaced Struts, uPortal based presentation layer with GWT based web2.0 enabled presentation layer. You can read more about my experience in an earlier post here.
Home-grown solutions to standard technologies
Initially in my career, I worked on couple of very successful products developed with homegrown architecture. MVC frameworks like Struts were not readily available and many companies have come up with their own version.
One of these was a hugely popular insurance product suite. There were many requests for customization and enhancements. But, because of certain inherent flaws in core architecture, enhancements were either taking long time or were deferred. It was decided to rewrite product with WebWork, Hibernate and Spring. It turned out to be very good decision and helped in making product more popular. This was a big decision taken after careful consideration but there are simple cases. I recently worked on a project where we easily replaced home-grown wrapper component on Quartz with Quartz integration provided by Spring.
Redundant / over-designed features
Occasionally there are features in product never or rarely used. This leads to problems while implementing enhancements. Dependencies need to be fixed and tested in these seldom used features. Maintenance cost is skewed and money is being spent on useless stuff. In some cases, it may make sense to remove or simplify these components.
I worked in maintenance of a project with a component to show workflow change notifications on dashboard and to send them via email. Component served its purpose but had very complex subscription logic, notification control features with many options. Lots of issues were reported from production and most cases were due to lack of understanding. We redesigned this component and removed whole lots of complexity (and code) making component much easier to use.
Non availability of resources
There are products with no problem apart from the fact that they are built on technology for which there are not enough developers available. This leads to resource dependencies and it becomes very difficult to maintain application even if enhancement part is left. Sometimes, in these cases it may make sense to shift gradually to newer technologies.
Modernizing application
Sometimes there are modern concept out there in market you just cannot ignore. For example, many application have been migrating to Service Oriented Architecture or OSGi off late.
I covered some scenarios but know there are many left. It would always be difficult to retire an application and in each case proper cost benefit analysis needs to be done. Sometimes, retiring-rebuilding may look better option but on probing further it may emerge that existing component can be improved.
I worked on a text search component in a recruitment application. It took hours and sometimes days to index resumes and other documents. Customers and technical support was unhappy and initially it looked like worth rewriting. But the product has just started getting real customers and it was decided to wait. It worked with some minor fixes and workarounds for more than a year when it was eventually rewritten when more information was available and other components were being modified. I told you every situation is different and there are no hard and fast rules.
[End]
No comments:
Post a Comment