Vendor Accent

Legacy value restoration in the financial sector

Despite the risk and cost of migrating to a new technology from legacy systems, in the long run it pays to have responsive, integrated and market-oriented IT systems, says Daljeet Saran

There’s no doubt that the fag end of the 20th century and the early years of the 21st have been challenging for financial institutions. This economic uncertainty, political unrest, business slowdown and growing recovery coupled with changing customer expectations and demands, has caused financial institutions large and small to take a hard look at all aspects of their operations and processes. These companies are faced with conflicting priorities—widen capabilities to exploit increasing business potential but avoid committing too much in case the recovery stalls.

To increase market share, a company must be better than the competition. That competitive edge may be in operational excellence, leading to a lower cost per transaction and therefore lower prices, or it could be in higher quality, or innovative and user-friendly product design. In most markets, however, the winning competitive edge comes not from these capabilities—all competitors must now meet stringent expectations in price, quality and product—but the critical success factors are more often lead-time, agility and customer service.

When software fails to change

Software becomes legacy when it begins to resist modification and evolution. When the knowledge embodied in legacy systems constitutes a significant corporate asset, the systems can’t simply be discarded—but must be replaced. Legacy systems, by definition, resist change. Many have grown very large and contain business knowledge that may not exist in any other form inside the company. The replacement system must capture and implement this business knowledge. Unfortunately, replacing a legacy system places a huge burden on IT departments and prevents them from developing new applications and capabilities. IT can ease this burden by increasing the efficiencies of maintenance processes and eliminating redundant applications. However, even these activities have practical limitations.

Even the newest systems require continued investment to duplicate all the capabilities of the legacy system. Because the larger chunk of the software budget in large financial companies is devoted to evolving existing software rather than developing new software, legacy systems acquire more prominence. The major part of the cost of maintaining software comes from the high support cost— unavailable resource set, old languages, operating systems, compilers, etc.

Restoring legacy systems

Normally, a well- functioning system will be called a legacy application because of one or more of the following attributes: lack of user documentation, limited internal skills, high support costs, phasing out of the application platform by the vendor, and non-compliance of existing systems with some new regulations coming into place. Mergers and acquisitions (M&As) have also impacted the development of legacy systems.

Legacy information systems are often a company’s biggest asset in terms of information and knowledge. Losing this data could prove more costly to the business than replacing a system. Modifications are therefore viewed as high-risk, high- investment projects.

Retention of value provided by legacy applications is as important (if not more) as current IT market dynamics such as offshoring, right sizing, and business and IT process optimisation. Lack of agility of the application can result in statutory non-compliance, and the business can lose its market edge if new functionality cannot be incorporated easily, if applications become expensive to support, and if training is needed for end-users.

Legacy system enhancement caught the public fancy prior to becoming a business need during the nineties when organisations started offering services to external audiences using the Internet as a channel. Converting the character-based systems (3270/ 5250/VT100 DEC, AS 400, etc) that were not intended to be displayed or played around in the HTML format provided the impetus.

Big issue

Organisations across the globe are facing the challenge of Legacy System Restore to satisfy the demands of internal customers and new users. The choice of application conversion method used often depends on the complexity of a system and the oldest system in use. Then there are other factors such as phasing out of support by vendors. For example, Windows NT 4.0 is no longer supported by Microsoft, nor is Oracle 6.0 supported by Oracle.

Typically, when we migrate a legacy system to a more potent new technology, a couple of things are required: understanding the business functionality, and identifying the data items that represent these concepts and the processes performed on them. The enhancement can either be done through a front-end UI, writing middleware and using the data direct drivers to retrieve information from a mainframe and present it to the GUI screen, or by employing a composite application.

To get the maximum bang for the buck spent, the recommended method is to build the existing application from the bottom up; not only will it involve extensive ground work but will also help us use technologies and security features. This method is prone to failure with regard to converting the absolute existing functionality from a legacy platform.

Capturing legacy value

The inherent inflexibility of core transactional systems makes it difficult to introduce new products, streamline processes, drive automated decision-making and leverage best practices across an enterprise. A generic pattern will involve studying existing applications, classifying the same into various types and layers, and proposing a solution that captures and leverages the existing application into a scalable real-time application architecture.

Data gathering: Classification of existing data and application type, infrastructure architecture mapping (type, data and complexity.)

Metrics: Metrics generation, analysis and base lining of existing as well as expected outcomes.

Product evaluation: Evaluation of existing products, their relevance to applications.

Solution: Proposal of the solution after study of above issues.

Implementation: Implementation of the proposed solution and to fill any gaps in the proposed solution to result in the agreed output.

Competitive pressure and escalating maintenance costs can pressurise a company into replacing its legacy system. The apparent attractions of new technology may also act as a driver for change. The legacy transformation from an old platform or version to a more robust one is a time-consuming, risk-prone, multi data-decision point initiative and an investment-intensive one, but the payoff from the same is manifold, making the organisation more responsive, integrated and better tuned to the market and its customers.

Daljeet has over four years of software consulting, development & offshorisation experience and is currently with the Financial Services Business Unit at Patni. He can be reached at daljeet.saran@gmail.com