Legacy Application Systems: What to
do with your application once it becomes outdated
|
SUMMARY
One
of the most common decisions that software owners are faced
with, is what to do with legacy systems and databases once
they become outdated. Leaving
a legacy application untended will only turn it into a liability.
There
are usually four common options before the owner of a legacy
system, commonly referred to as the four R's. They are Rewrite,
Replace, Re-engineer and Re-use.
|
One
of the most common decisions that software owners are faced with,
is what to do with legacy systems and databases once they become
outdated.
Leaving
a legacy application untended will only turn it into a liability.
This is because an application goes through a definite lifecycle,
with an initial maintenance phase where bugs are fixed and functionality
added. After this phase, the owner needs to invest in the application
with both resources and time in order to enhance its performance,
value and capabilities. If left neglected at this stage, all of
the initial investment will be lost.
There
are usually four common options before the owner of a legacy system,
commonly referred to as the four R's. They are Rewrite, Replace,
Re-engineer and Re-use.
If
the owner chooses to rewrite the software, the most important decision
to be made is what language to use. The choice you make, be it COBOL,
Java, VB or C++ is especially important. The wrong choice will result
in a lot of wasted time, effort and money. Once you have zoned in
on what language to use, you need to train your staff to be conversant
and adept with the new language. You could also hire new people,
but this will also have its own complications, as they would need
to learn the workings of your business and applications and you
would need to spend time on training. According to Capers Jones,
27% of rewrite projects are cancelled or rescheduled, 20% are seriously
behind schedule, 50% exceed budget and the majority of projects
that do manage to reach completion, have only less than half of
the planned features. Overall, rewriting does not seem like an encouraging
option.
The
second option is replacing your legacy application with a new package.
This again entails finding a package that fits in with the requirements
of your business. The chances of this happening are very low, therefore,
you need to either customize your package in order to fit the business,
or actually make changes to your business in order to exploit your
package to the fullest. This can turn out to be a workable strategy,
provided the package supplier has made a good decision on the choice
of development language.
The
third option is Re-engineering. This entails changing the entire
business as well as the software application in order to make way
for your re-engineered software. The flip side of this option is
that there already are existing systems, procedures and methods
in place, with technicians trained to work with them. Re-optimizing
all these systems is both expensive and hugely time consuming.
The
final option is reusing your existing legacy systems. This is by
far the most sensible, cost effective and time effective option,
primarily because your staff is already acclimatized to your system
and will need minimal re-training. It is still possible to upgrade
your legacy systems into web services, graphical user interfaces
and mobile computing. The changes made will be incremental, which
means much lower costs and time involved in re-training your workforce.
The smaller the steps, the easier they are to retrace and start
over in the case of a mistake, which means that the risks are also
minimized.
So
your legacy system will still serve critical business needs, while
making use of newer, more efficient technology and programmer skills.
|
