Legacy Renewal
View Comments and Questions (6)
What's Your Question – Ask Our Experts..
At many companies, legacy applications are a fact of life. They may not be based on the latest cutting-edge technology, but they are tried and trusted - and, in many cases, extremely reliable.
They also represent years, even decades, of investment, so it's hardly surprising that most companies are pretty reluctant to replace them. Indeed, no serious cost analysis would suggest that to do so would be a sensible move.
So how can legacy applications keep pace with the changing IT environment around them?
The service-oriented architecture (SOA) provides an answer, according to Steve Shepherd, SOA specialist at Logicalis.
By packaging up re-usable business logic contained in legacy applications as open standards based web services, he contends, end-users get three key benefits:
1. REUSE
Employees don't expect to be asked to use decades-old technology. Web services make it possible for them to access legacy applications through a standard web browser on a modern PC.
2. REPURPOSING
Using web services, the information held in legacy applications can be used in new ways. For example, the stock look-up function sitting on a back-end mainframe might be used by customers to check product availability as part of an online order.
3. CONVENIENCE
Some call it ‘swivel chair integration' - the need to feverishly switch between different applications in order to complete a business process. Using web services, information held on different back-end systems can be brought together and presented to end-users via single interface, for example, an employee portal.
"The service-oriented architecture is already helping IT departments to deliver software components flexibly, as a service to users, rather than perpetuate the pain of siloed applications. It's a great example of IT focusing on the way business users want to work, rather than the converse," says Shepherd.
Add to del.icio.us






Your Comments and Questions
Mandy Shaw, 8 months ago
I'm interested in your comment '... the cost of development falls ...'. Do people agree with Redou that it is falling? If so, why do you think this is happening?
Edward1 Charvet1, 8 months ago
Must be a cost / benefit debate, being brought into focus as the cost of development falls and the sophistication of the applications increase.
Gary Edwards, 8 months ago
I'm not sure that legacy applications and 'cherished' code is necessarily a limiting factor in getting rid of legacy systems, but perhaps the 'uniqueness of purpose' it provides to the organisation is. I read in the IT press that bespoke IT systems are gaining in popularity due to the competitive advantage they confer, given that most organisations will have similar 'out-of-the-box' solutions. Is this anyone's experience?
Mandy Shaw, 10 months ago
Replacing a legacy application is an enormous move, especially as it may well involve modifying the business process as well. Modifying the legacy application in /any/ way, even to add hooks for SOA, can be a fairly big move, especially where the organisation has complex compliance requirements that cut in when any application code change is made. And don't forget that, even post Y2K, there may just occasionally be grey areas where the organisation is not 100% convinced that the stored source code matches the deployed application ... It's honestly more about risk management and sweating your assets than about fear of the unknown. Re 'cherished' code, I think it was a vendor (of screen-scrapers, needless to say) rather than a customer that came up with that one. But, if you don't mind me saying so, I think you are wrong in your implication that being interested in technology means you can't see the benefit in something that, though old, was well built. I wonder if any civil engineer would want to sweep away the Clifton Suspension Bridge and replace it with a swanky new one - even though the interfaces are a bit inflexible (i.e. narrow). Sweeping away the old is sometimes the right answer. Keeping the old in its current, frequently monolithic and unmaintainable, state can sometimes, boringly, be the right answer. Chipping away at cleaning up the old and giving it proper SOA interfaces, while deploying new functionality through more easily supportable technologies, may very well be the right answer. We used to call this whole question 'the old, the new and the glue' which sums it up pretty well.
Edward Charvet, 10 months ago
As ever, Mandy, your comments are keenly observed. Are you saying that in general peoples fear of extracting a legacy applications is still greater than the fear of finding it unsupported in the future? And the comment about "cherished" code, does that some it up - is it just too heart breaking to sweep away the old for new? I wonder if we have found a new definition of irony - a technologist wedded to the past!
Mandy Shaw, 10 months ago
I went to see a customer about this sort of application modernisation the other day. They already have an SOA engine in place and are very comfortable with reuse, repurposing and convenience, and with using web services. However, and unusually in my experience, they are really keen to get rid of their legacy application code and rewrite it in Java. Their perception is that getting hold of 'legacy' (e.g. COBOL or RPG) development resources will become harder and harder, and that therefore the bullet needs to be bitten now. I would be very interested to know what others feel about this, obviously especially those with large amounts of in-house-written (or heavily customised package) legacy code. (I suspect it does depend somewhat on your geographical location.) On a slightly different tack, taking legacy code and providing it with a web services interface typically requires you to lose an existing user interface (unless you are lucky enough to have nice modular code). I am interested to know what sort of experiences people have had when doing this. Finally, can't resist sharing an old memory of someone describing legacy code as 'cherished' code ... not that common a feeling, I suspect.