Legacy Application Systems

By Bill Flowers

---

I started writing articles about evolving IT concepts and methods a few years ago.  I had some luck with Agile Methods, Business Intelligence, Modifying Commercial Software and a few other interesting subjects.  Then I thought I would do a short article on Legacy Systems.  Simple, right?  Not.

What I thought was going to be simple was anything but.  I could not even find a clear-cut definition for Legacy Systems or Legacy Applications.  So, if the ideas you find here do not translate directly into answers, they may at least give you some important things to think about. 

What is a Legacy System/Application?

I went looking for a simple definition of a legacy system and found that there are many thoughts about what a legacy system is.  I collected some of the characteristics to see if I could isolate a set that might lead to a definition that could be used in an article on the subject.  A legacy application system might have these characteristics:

• Developed long ago and been in use for a long time.
• Probably caters to essential business functions.
• Internal functionality, specifications and structure are not well understood or documented.
• Continues to be used because it is essential to the business or at least fulfills some business needs.
• Sometimes large, complex, poorly understood, difficult to modify and maintain.
• Probably provides strategic business functions which themselves may not be documented.
• An old application system that may be problematic and incompatible with current systems.
• Very often a mainframe based solution.

 

Narrowing it down, we might say that, for discussion purposes, a legacy application system was originally developed to provide business functionality, some of which still exists.  The software is old, not completely understood, probably undocumented, probably developed for mainframe use and is very likely to have been written in COBOL (or maybe PL/1).  There are lots of variations but this pretty much defines the type of Legacy System we are thinking about. 

Legacy Systems – Are They Good Things, Bad Things or . . . ?

The fact that Legacy Systems still exist and are still operational would lead one to conclude that they are still useful in some way – probably true.  However, there might be better alternatives available in which case the reason that they are still being used is because getting rid of them is difficult for some reason.  And therein lies the rub. 

The maintenance, operation and support costs of some Legacy Systems are often excessive.  Tracking down a problem, making changes and testing the changes on a Legacy Systems can be quite difficult.  Legacy Systems can be slow in operation and difficult to use.  Some of them have data input and data presentation that is clearly from the IBM 3270 green-screen era (over simplified and presentation without explanation).

It is difficult and probably impossible to make any portion of a Legacy System mobile.  Data comes from and goes to terminals (desk top PCs).  But the modern business world is mobile and often gives some access to information directly to customers/clients or partners.  Legacy Systems are unlikely to provide that kind of access. 

So, are Legacy Systems good things or bad things?  Well, they are often expensive things.  They sometimes require hardware and/or internal software that has little to do with the future of a company.  Let us just say they are things that we would rather step beyond or move away from.  They are neither good or bad, just surrounded by uncertainties.

Why Are Legacy Systems Still Running?

Why are they still running?  Good question.  The answer may be as simple as – there is no obvious reason to turn them off.  The answer may also be more business oriented than that.

There are a lot of legacy systems still in operation.  The reason why some of these systems have not been replaced or upgraded may be because it just is not possible.  They provide some form of business support even if the systems and their purpose are not well understood anymore.  Generally, the expectation is that they would have to be replaced with . . . something but, because what they do is often not well understood, how they might be replaced is anything but obvious. 

As an IT staff member, what might one do?  Suggest that a system be terminated?  Now that would be anything but clever.  Suggest that it be replaced?  With what?  And that is an interesting question.  If the purpose and value of a Legacy System is well understood, one could work towards replacement options.  Unfortunately, the purpose and value of Legacy Systems sometimes tend to be less than clear.  So pursuing replacement options is not always the simple matter it might be.  Determining the cost to replace them is anything but easy.

Although the functionality and the business value they provide may be less than clear, they came into existence and have remained in operation for some time.  The reasons may not be obvious but their ongoing existence may be related to the reason for the original investment in a legacy system, whatever that was.

Will We Have To Replace Legacy Systems . . . When, Why?

The difficult question is – will we ever have to replace those old Legacy Systems?  Do we have to keep them in operation and, if so, how difficult will that be over time?

There are definable operational costs that include hardware, related software and perhaps license fees.  We can go back and calculate the maintenance and support costs that have already come to pass with some degree of accuracy.   Software maintenance costs get interesting.  They deal with changes that have been needed over time.  There are at least two dimensions to those costs – what was needed and who was able to provide the changes?  Will that type of change continue (or increase) and will people who can make the changes be available? 

One question that really should be asked has to do with what software changes may be necessary due to the business itself.  Will the system have to adapt to changes in the business world?  Will the business need the system to do more or different things?

If the Legacy System is a purchased commercial software product, will the vendor support dry up at some point?  Is that when a replacement decision will have to be made?  Should some thought and consideration be given to that eventuality ahead of time?

Typically, the most pressing answers to why you might have to replace a Legacy System have to do with:

• Cost – the operational cost to run it on aging technology will progressively increase over time.  The time, effort and cost to modify the code when business changes dictate it will also progressively increase and even maintaining the IT staff skills to look after it can be significant.
• Uncertainty – it gets more difficult and expensive to make changes over time.  It is altogether too likely that, at some point, it will simply no longer be possible.

Things to Think About

Dealing with Legacy Systems is no small thing.  It may be overwhelming.  It may be best to think about how you might want to go about it before you openly suggest replacement as a possibility.  Consider it initial planning.  This kind of thinking may result in a plan for making a plan. 

Cast your mind over things like:

• What business departments are going to be interested and/or able to help? 
• What people in the business departments would you like to see involved?  You might want to start some early (perhaps non-specific) discussions with them.  They may trigger thoughts about an eventual replacement.
• What type of IT skills might be needed and are they available in your shop?
• Is there a timeframe associated with the whole idea?  There may be business changes coming that started you thinking about limitations in your Legacy System(s).
• Can you see a structure/architecture that would be best?  You are not decision making here, just identifying things to talk about with some of the IT people.
• What other application systems does the Legacy System integrate with and/or which ones might a new solution want to connect/collaborate with.
• What data challenges might you face?  Remember, there is probably years worth of historical data from the Legacy system out there that may be important. 

There are many, many other things that you might want to think about.  I offer those above as a starter kit.

Things You Might Want to do

After you have given the whole exercise some thought, if you are still of the opinion that some attention to the Legacy System situation is warranted, you can go beyond the thinking stage and perhaps start doing something or causing others to be involved.

Talk to the Business Folks

When you have thought about some of the things you need to know, you might start talking to people in the business departments that use the Legacy System.  Chances are good that you have been doing that for years as you dealt with issues related to the system or other systems.  Now you might start to help them get focused on the future and things they might want to think about related to how business processes are supported by computer systems.

The danger is that, in talking to them, they may conclude that something is going to happen when your goal is simply to try and determine how to make something happen.  I wish I had a clever suggestion about how to avoid leaving them the wrong impression.  It depends on your relationship with them.  Perhaps explain that you are just trying to understand the IT/business connection better, which would be true.

Identify Related Metrics

One subject that often causes some difficulties when change and budgetary issues are involved is metrics.  Metrics – numbers and measurements that usually relate to performance of some kind.  The difficulties I refer to above have to do with figuring out which ones are relevant to planning how to do it, making a business case for doing it and then how to actually acquire the numbers.

How does one justify the sizable expense of building a new system to replace one that may seem to be still functional by executives and those who control the budget?  At some point, you will have to present a case for spending the money needed to replace or rebuild the Legacy System.  It will have to be clear and logical.  It will have to have numbers associated with it – metrics.  The logic may relate to business changes anticipated that simply cannot be done for some reason.  The reason will have to be very clear.  The cost to maintain, operate, support the Legacy System will almost certainly be needed.  The really difficult thing will probably be trying to determine how the system is related to performance of the business group.  If you can clarify that, then you might want to review what the original justification was for the system and how that has changed over time as the business changed but the Legacy System did not. 

There are a number of metrics that you might want to acquire.  Identify them, create a list of questions to ask and perhaps ask your IT staff and/or your Business Analysts to pursue some of the questions when they “have a moment”.  What you need and want will become clearer as you start getting feedback from them in the form of numbers or questions.

How Does One Go About Replacing a Legacy System?

If it becomes obvious that a Legacy System must be replaced, the overriding question probably is how does one go about doing that?  And that is an incredibly good question.  More often than not, it will be difficult.  Those systems have been running a very long time.  People who you may not have identified or even be aware of use them, depend on them and will want your blood if you do not consider their needs.

If you do your research, you will find that there are many opinions on how to go about it.  As far as I can tell, it boils down to three main options – completely replace the Legacy System (and there may be a couple of ways to do that), build a new product to replace the old one (call it a rebuild) or modify/upgrade the existing software (call it modernize or transform). 

Your best solution may, in fact, be a combination of the options.  Deciding how to go about it will be difficult and is very, very important.

Options:

• Replace (buy current commercial software for example)
• Rebuild (start again, requirements, rebuild, testing, training, implementation)
• Modernize/transform (upgrade existing software, use what is there, make it better)

Replace

If the Legacy System was originally purchased from a software vendor, you may be able to select a current version of their software and do a more or less standard conversion to the new system.  It sounds simple but there are many things to be considered, some have to do with the application itself.  Questions come up – is it integrated with other application systems and, if so, will that be possible with a new system?  Has the relationship with the vendor been satisfactory? 

As in every option, the question of resources comes up – who will be needed and how many will be needed?  Do they have the skills needed to define the current/future requirements, to plan an implementation, to deal with data issues that might come up?

As in the acquisition of software at any time, it will probably cost more than you would like to have to pay.  That does not make it the wrong or a poor choice.  It just means that you will have to identify sound business reasons for making it the preferred alternative.

Rebuild

This option assumes that you will rebuild the software probably using IT and business people inside your company.  It means starting over by extracting requirements from the existing software (so far as is possible), verifying them, working with your user departments to identify new but related requirements, defining a new architecture and building a new system. 

There are challenges here – original requirements will not be clear from the old code.  Old Legacy Systems will have been modified many times and the original intent may simply not be clear anymore. This is where your staff may truly begin to understand how confusing “spaghetti code” can be.  You will certainly have to spend time with the users because you will be after their needs for input screens, data displays, mobile access needs and integration with other systems, most of which will have no connection whatsoever with the old code.

Of course planning the rebuild will be a challenge.  If your company has adopted agile project methods, you may be expected to use them on this rebuild opportunity.  I like agile methods but they may not be the best idea in a rebuild situation.  An iterative approach might be worth considering, though. 

Resources will be an issue.  Do you have enough, when are they available, do they have the right skills?  The same questions will need to be asked about the business folks that will be involved.  These questions can all be worked out but they need to be asked.

There is a price to replacing a Legacy System in this way.  It will take time. It will be expensive and time consuming.    

Modernize

Legacy Systems can be made more modern by converting the original code (goodbye COBOL) to something more modern or by keeping the old code but employing other, more current ways to activate and use it.  You can find many related options.  Put “legacy modernization” or “legacy migration” into Google and you will have plenty of reading. 

Basically, the options are:
 

• Convert all or some of the original code and replace anything that does not fit your current technology (usually the user/screen interface and sometimes the data base).
• Wrap existing code with current technology interfaces (much the same as above only leaving the code alone and using off-the-shelf interface software).

There are various combinations of these options.  What I most dislike is that whatever structural flaws were in the old code could still be there when you finish.  The architectural flavor of the old code was designed for “legacy” technology and it is still there.  It might be possible to correct the worst of those problems over time or even during the modernization but you would have to purposefully set out to do so. 

A long term migration plan might be to do it piece at a time – leave as is for the moment, replace parts and eliminate pieces or applications over time.

In Summary

There are many Legacy Systems still in operation even thought they are expensive to support, maintain and upgrade so they must still be useful in some way.  Pursuing replacement options is not always a simple matter.  Determining the cost to replace Legacy Systems is anything but easy.

It will boil down to what it might cost to keep them in operation and to make changes to them.  This type of information can usually be extracted from records.  Questions from the business side are important.  Will the system have to adapt to changes in the business world?  Will the business need the system to do more or different things?  Can the changes be made?

You might start by talking to your business colleagues to find out what they think about the existing Legacy System(s), any new features that might help them and any changes in the business world that may add to what the systems can do to help.  These conversations might also give you some idea about the timeframe and things of that nature.  Conversations of this type will help you identify which business people might be involved and may provide you with some of the metrics you need or identify a source for the metric information.  It is just a couple of colleagues talking to each other.

Within your IT group, a conversation about replacing Legacy System(s) or rebuilding them might provide interesting observations.  It would probably also be a good idea to get one of your IT people to learn a bit about application modernization as an option.  There are some interesting possibilities there.