Customer Relationship Management

Hi Sandeep,

Thanks for sharing your views on this. I was looking for this information.

Good information. Thanks for your post

A very interesting article. Thanks for sharing.

Rather than retiring, applications will either be overhauled or will be stripped off their modules which are inefficient.

The best example can be an automobile. For example; every motor vehicle has its lifetime. With every passing day we also need to account the depreciation in software as well. With new technologies coming in, one has to get upgrades or live with the inefficient systems.

I completely agree with the author's view point and the issues that are raised over here. But the big question is at what point does one need to retire an application? The cost of running a legacy system is usually higher than building a new efficient system. Especially in these uncertain times, there are a lot of entities who prefer to bear the recurring cost rather than making that one time capital investment.

SaaS is a good alternative to overcome the troubles of legacy systems, but it does not necessarily mean that it will fit in all business requirements.

This has been my subject of study for the last 4+ years. I have observed that whilst there are a number of straight forward cases where migration renders clear business benefit, there are applications which are architecturally sound and are highly efficient yet earmarked for migration in order to satisfy the enterprise architectural decisions.

Such migration projects are painful for the business, the design and delivery teams and have very low rate of success.

Aging of software is a very complex phenomenon. Many times, it matures and becomes stronger as it ages.

I want to comment on "Do you easily get people skilled on outdated software to maintain your legacy applications? " . The answer is no. Perhaps, the reason is different than it has been said. I guess the reason is though it is a rare skill nowadays, it not a well paid job. I feel it is the reason people are shifting to newer technologies. A new entrant in the field with knowledge in newer technologies is paid more than a person working in legacy for more than 10 years experience.

Good points by Sandeep. One more thing that is going to set a trend or act as a governing factor now is the financial slump. Companies which were leaning towards legacy retirement are looking the other way around and delaying the decision. Why would you want to go and disturb something that is running healthy? That would be a CIO's question. Is the legacy maintenance cost too much? If so, can you guarantee the same performance and reliability in the new system? Can we invest one time in the new system and see an improvement in costs, productivity? Now, how long before the new system becomes legacy? Is the world moving too fast to accomodate changes? Some of these questions need to be sounded and thought aloud before legacy is shunted down.

All said, sometimes shrugging off the old and entering a new realm gives that extra push to the organization. Its purely a management decision after all.

Thanks everyone for spending few minutes on this blog and leaving very thoughtful comments/questions.

Collating few questions raised by some of you
"At what point does one need to retire an application?"
"How long before the new system becomes legacy?"
"Why would you want to go and disturb something that is running healthy?"

I think the answers to few of these questions lie in my initial blog that you have to do a thorough cost-benefit analysis before you decide to retire/retain your application. If we have a mechanism to continously monitor TCoA (Total Cost of Application) and comparing with what it takes to upgrade or replace with newer tachnologies, it will surely help in taking the big decision.
In these economic times when most companies and even inidividuals have tightened their pockets and decided to focus on savings rather than spendings, the one things which can not be compromised is the Customer's Expectations. Technology in day to day life is now becoming way of life for many. Can you think of a life without internet? Do you again want to go to the era of standing in long queues for submitting your water and electricity bills? Are you not curious of using mobile banking and using internet anytime/anywhere? Legacy systems might be running fine but you may still want to upgrade to new technologies if you try to answer similar relevant questions.

Thanks again for reading this and please continue to pour in your views. These are really helpful for many of us.

IT Cost/Benefit Analysis considerations
1) Ease of maintenance (downtime cost + resource availability & skills and associated cost)
2) Legacy systems usually run on legacy hardware. Cost to maintain this hardware + o/s licenses and reliability of h/ware (downtime) + data centre cooling + power consumption
Strategic Considerations
4) Architecture considerations
5) Can the money for rewrite be better spent elsewhere – ROI calculation
6) What is the benefit to the customer for rewriting - major consideration?
7) Is the business ready to change, do they consider it important to change?

There are a number of reasons why a Legacy system cannot be totally retired, most of which have been discussed above. That is a reason why transition projects today are using new technologies as front end / middleware, including small databases to log end user data, but still data getting posted at the end of the day in the legacy system. Any query from the end user would access data from the legacy system and gets displayed to the user (the advantage in this mixed architecture being the end user / end user application developer need not know the legacy system architecture or programming). The robustness that a legacy system gives in terms of its uptime, dependancy, scalability and portability (if that aspect has been thought of during the design phase of the application) is unmatchable.
Rather than completely retiring & burying a legacy system, it would be wise to continue using it for what it is famous for, the 'R' factor ('reliability') and front end applications providing the flexibility for the end user.

Thanks Sandeep, for sharing your ideas.