Outdated

While these legacy systems may be solid and reliable, they can`t work forever. They can`t be maintained for much longer, either, because the pool of technicians with the skills needed to maintain them is dwindling, as people retire or die.

These ageing systems that have been around since the days of the mainframe are now due for a much-needed facelift, say industry players.

While most of the financial services players have adapted or replaced legacy systems in a piecemeal fashion over the years to accommodate changing needs, soon a point will come when such solutions are no longer enough.

With new regulatory demands and better ways of reaching customers, increasingly flexible systems are required. And, Barry Dwolatzky, professor of software engineering at Wits and director of the Joburg Centre for Software Engineering, points out: "You can`t stretch systems to do what they are not meant to do."

Damned if you do, damned if you don`t

So, with the legacy systems precariously supporting layers of new applications, they are kept in place running core applications - partly because they are the foundation for a great deal of other technology - and partly because replacing them means risking a massive `switch off` of vital banking functions. And the cost and complexity of a rip and replace exercise can be massive.

On the other hand, in a worst-case scenario, if the legacy system should collapse under all the technology stacked on top of it - also causing a shutdown of essential banking business and risking massive and sudden expense.

Dwolatzky likens the situation banks find themselves in to a young father trying to accommodate a growing family by building extra doors in the sports car that he bought when he was a young bachelor. "What the financial services sector is doing is building in these doors while the sports car is driving at 150km an hour," he says.

A catch-22

Ronny Smulders, financial services sector executive at IBM SA, says the cost of revamping these systems is exorbitant and business does not always "have the appetite" to invest in this multi-year change. Moreover, this level of change introduces risk to availability and stability.

Tertius Haak, head of strategy and architecture at Absa, agrees. He says that due to the potential for business disruption and the costs involved, Absa is not embarking on a full legacy replacement strategy.

Smulders explains that most legacy systems are mainframe-based and most were programmed in COBOL in the mid- and late-1980s.

According to Nico Vlok, senior manager in Accenture`s Global Technology Consulting unit, over time, antiquated systems lose their `business fit` from a functional and technical point of view.

"When applications lose their business fit, it leads to an increase in the total cost of ownership of running and maintaining these applications and data," he says.

Smulders agrees: "IT departments are often left frustrated because of the escalating cost of maintaining these legacy systems coupled with the squeeze on IT budgets. But without business investment, IT cannot curb escalating legacy maintenance costs."

He points out that banks are hard-pressed as they are reluctant to let go of their legacy systems and would rather opt for incremental change.

"This incremental change would mean extending the life of the legacy applications. One approach to this could be through Web enablement, which could, for example, provide a modern user interface and additional business functionality to the legacy application. But this does not solve the problem as the inflexibility of the legacy applications still exists."

As it stands the legacy applications are efficient and work well, but just do not meet modern demands. This is as a result of ever-changing business models, says Smulders. He says, at present, it is extremely costly to maintain legacy systems because of the complexities in these systems, coupled with the fact that many of the people who wrote these applications and understand them are now either "retired or no longer around".

What`s more, he says, there`s limited documentation in existence that details how to maintain these systems.

Absa`s Haak says: "A typical legacy banking application landscape is usually mainframe centric, developed in procedural Cobol, with the functionality residing in silos."

He adds that there is very little re-use of code. Haak states that the main challenges are to remove or untangle the system from an integrated application landscape without compromising stability and customer service, as well as plugging in the new system into the old legacy environment. - Smulders says it`s costly to migrate from the legacy and it`s costly to maintain the legacy. "It`s a catch-22 situation."

Let`s go shopping

Another approach to transformation, says Smulders, would be to buy off-the-shelf applications to replace the legacy applications.

This would bring in a new set of challenges, he says. "The new application will need to interface to other existing applications and would involve a lot of integration work. Also, to minimise customisation of the new application, changes to existing business processes will be required," says Smulders.

Nedbank`s divisional director for group architecture and IT strategy, Andre Meyer, says: "The challenge with off-the-shelf applications is integrating packages into the legacy environment, as well as customising these packages."

He adds that another challenge is keeping the legacy system competitive while implementing a new package, since the time frame for such an implementation is typically 12 to 18 months per module.

Not all gloom

Vlok maintains, aside from these, there are other strategies in existence to achieve legacy modernisation. He says banks can decide to re-platform, which is to change the technical platform, or remediate, which is resolving issues with the application code without changing functionality. Banks could also decide to migrate existing code to a new language, he adds.

"These strategies could extend the life expectation of legacy systems indefinitely," he states.

Vlok maintains that because of the complexities associated with migrating from legacy systems, careful consideration must be given to the reasons for embarking on this journey.

"In deciding what strategy to embark on, one must ask: Is the total cost of ownership in line with the benefits delivered? Does the system fit functional requirements? Is the application and platform stable and still supported?"

He adds that the counter-argument, in favour of keeping legacy systems, must also be looked at in terms of the following: Why even change to newer systems if the existing ones are still performing?

Also, the costs of running legacy systems must be scrutinised in terms of discretionary and non-discretionary spending, says Vlok.

"This spending is typically made up of the following: costs to enhance legacy environment and functionality; platform costs, which includes software and hardware, processing power; regulatory changes; time required to perform enhancements; maintenance of different environments and maintenance of the legacy skills base."

He says even after all these factors have been considered, cost, agility, quality and risk remain the biggest challenges that face the financial services sector, whether deciding to keep the aging systems or completely overhauling them.

Fernando Moreira, FNB`s CEO for the Hogan banking systems, says FNB has decided not to change its core system. "We have found the platform to be extremely scalable and flexible."

He says current and future developments are still taking place in the Hogan environment, but where the business case makes sense, it has developed outside the Hogan mainframe environment while still integrating the systems with the Hogan.

He says IT skills remain in short supply, but these shortages are not unique to the legacy systems. "FNB has extensive internal skills development programmes to ensure that capacity levels are maintained."

He notes there has been an increasing trend internationally, especially by IBM, to address shortages and accelerate training in legacy skills.

Haak from Absa says the bank is in the process of extending the life of its legacy applications with the implementation of service-oriented architecture (SOA). "This allows us to expose existing banking business logic from the existing legacy systems as re-usable services. We are creating a front-end tier where we can enable business process re-engineering, workflow, electronic documents and document management systems."

He says SOA implementation is in line with international best practice.

Meyer from Nedbank agrees: "SOA influences our decision making at present." He says that at present banks are starting to renew product systems while some are choosing to use different packages. "We are seeing growth and consolidation in the package supplier market," he says.

At present the banks continue to plug-in and stack applications on top of the old legacy systems. It remains to be seen how long these antiquated systems will last under the pile of new applications before they overload.