Strategy clinic: Where do legacy systems hide?

I am preparing to streamline the IT infrastructure within my business. Can you give me any tips about how I can identify legacy systems that are lurking within our infrastructure that could safely be switched off?

The solutions

Be guided by feedback from your user managers - Gary Cairns, Certus

You will know when to replace legacy systems - when they are constantly falling over or become expensive to maintain. But the best barometer is when negative feedback from others (especially directors and managers)is overwhelming.

When the finance director gets involved you know something has to be done and at the same time you have a valuable ally. You will score more brownie-points if you are proactive and lead the debate, but be prepared to present a logical business case. Never underestimate the work that needs to be done to find replacement systems, migrate data and change business processes.

How important and effective is the application? - Anthony Harrison, NCC Group

The task of managing the applications portfolio is made easier by having a robust process. Applications must support the business. The fact that an application may be five years old or more does not, in itself, justify decommissioning.

Evaluate the fitness of applications across two dimensions: how important is each application to the business and how effective is it in support of the business? If an application is judged to be both important and effective, then it should, in most cases, be retained. But if it is important but ineffective, then it is a candidate for replacement.

As it can take 12-18 months to replace enterprise-class applications the analysis should be undertaken regularly to identify applications that are un likely to meet business needs in the next 12-18 months.

One exception is where the application's supplier is no longer in business or viable. Then it may be prudent to replace applications even though they are fit-for-purpose in the short term.

Finally, evaluate the cost of replacement carefully. Initial licence fees may be dwarfed by other costs arising from implementation and configuration, testing and end-user training, and most interfacing and integration. Factor these costs into the replacement system's business justification plan.

Evaluate risk before switching off systems - David Hughes, Deloitte & Touche

Decisions about which legacy systems can be switched off should ideally be based on an evaluation of risk. Only switch off a system once you are sure that:

• Its replacement is meeting all of your current business requirements, without you having to refer routinely, or even by exception, to the legacy system. Do not forget business requirements that might only be raised intermittently by, say, your external auditors, regulators or customers following up past questions.
  
  
• All of the data you need is available to you in your new environment, including data to satisfy statutory data retention regulations as well as audit trails of transactions. Take a full back-up of all system and data files, so that you could recreate the legacy environment.
  
  
• Switching off the old system is not going to jeopardise current production IT processes. If you are not sure precisely which processes might involve the legacy environment, then taking the legacy system down in stages is the safest way to progress. Isolate it on the network and check that existing business processes continue to operate, including during key periods such as month-ends. Have contingency processes in place so that you can bring the system back online quickly if required.

Be clear about what you see as legacy systems - Roger Elvin, Cranfield School of Management

The easy answer is to switch off and see who shouts loudest and how quickly. I know IT managers who have used this approach successfully, although I never saw the need to resort to such extreme measures. It does imply a certain lack of knowledge about what is going on in one's computing environment and a desire to shortcut the process of finding out.

A more considered approach would require you to consider what you mean by "legacy systems" and "streamline the IT". What is your specific concern and what are you trying to achieve? Do you have old hardware with high costs of operation, environment and maintenance, or maintenance programmers whose effort would be better deployed elsewhere?

Just because a system is old does not necessarily mean that it is not performing a valuable function - business management should make that judgement. Your task is to provide data about costs and possible alternatives.

What you need is information - about who is accessing which systems and how often, what output is being produced, who is using that and for what purpose - and what would be the business impact of not having it. You ought to have the data available to provide this information. If not, it is time you put in place procedures to gather it. After all, without it, on what basis do you prepare your operational budget?

You should not be running redundant systems - Robin Laidlaw, president CW500 Club

What do you mean by legacy systems? If you are running systems, which presumably you are charging for, but making no use of them, then you have a very relaxed bunch of users.

If you mean systems that have been left running, probably old mainframes, delivering high-volume transaction processing, probably highly reliably and at low cost to users, why do you want to turn them off?

If you have a systems and data architecture in place, then you should be able to identify what applications are providing what data and information. If you do not have a systems and data architecture, then setting one up is your first step, albeit an expensive and time-consuming one. Perhaps the legacy you have inherited is just that - no systems and data architecture.

I find it hard to envisage legacy systems running, but not being used in any way. You may have developed to a position where the data provided by these systems is readily available from newer systems, but why, then, were the legacy systems not turned off when this became available?

If you mean that you have legacy systems that you believe can be supplanted by newer systems, then you need to identify what data and information is being provided and used. If you are not sure what is being used, then you have another problem, - a lack of applications management, with its associated recharging or reallocation - otherwise, who is paying for the systems you want to turn off? Regular reviews with your users are needed to ensure that what you are providing is what they really need.

Regular reviews of your systems and data architecture will indicate the changing business requirements and how your systems need to change, be turned off or where new systems need to be developed.

Analyse business needs and the technology's efficiency - Sharm Manwani,Henley Management College

There are two main reasons for replacing legacy systems: if they no longer meet business needs or they are technically inefficient. An analysis of all systems based on these two criteria will result in four potential categories:

• Systems that meet needs and are cost-effective
• Those that meet needs but need a new IT platform
• Those that are efficient but do not meet user needs
• Systems that are neither efficient nor meet user needs.

The last category is a good starting point to consider making replacements. It is also worth evaluating the need for operational and decision support reports. Potentially, these may be consolidated or eliminated.

One barrier to switching off legacy systems is the need to retain data, often for many years for legal purposes. Depending on the storage and access costs, it may be worth looking for an alternative medium, such as microfiche. The key is to engage with business managers so that they understand the cost of different services.



The experts

Computer Weekly has put together a panel of experts. You can draw on their specialist knowledge to solve a problem. E-mail your questions (or your own solutions to this or the next question) to computer.weekly@rbi.co.uk

Certus www.certus.org.uk

NCC Group www.nccglobal.co.uk

Deloitte &Touche www.deloitte.co.uk

Cranfield School of Management www.cranfield.ac.uk/som

Computer Weekly 500 Club www.cw500.co.uk

Henley Management College www.henleymc.ac.uk

AMS www.ams.com

British Computer Society www.bcs.org.uk/elite

Impact www.impact-sharing.com

The Infrastructure Forum www.tif.co.uk



Next question

The IT industry is always coming up with new and potentially useful technologies such as web services, grid computing and instant messaging. We are told that to test the usefulness of new technologies we should run pilot projects. Can you give me any ideas about how I can get the best value from a pilot project and even benefit the company in the process?