Working in the COBOL mine
Developing with Legacy Systems – Part 2
The important objective in this style of legacy modernisation is risk mitigation through re-use of what is known to work already; coupled to choice, going forwards. The enterprise can keep its legacy systems and maintain them in a more agile fashion, using a PC-based development environment, if that makes business sense; or move them to a new platform, perhaps if they are on a "burning platform" nearing the end of its supported life. It can even mine its legacy for business processes which can be input to the development of new software; or adopt some combination of all these approaches.
The first stage in the legacy modernisation process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code – modern tools can automate much of this analysis for staff working at a higher level.
Once the legacy systems are understood, they can be emulated on a different, cheaper, more agile platform. With modern technology, it is quite feasible to change and maintain even a traditional COBOL mainframe application on the PC, and then migrate the changes back to applications running on the mainframe.
However, legacy modernisation is a serious project, involving cultural change, so it has associated risks, which must be managed. An enterprise embarking on legacy modernisation needs a modernisation process, with internal champions both in top business management and in the technical area, as well as effective risk mitigation policies.
Sponsored: Customer Identity and Access Management