Introduction: One of the common challenges faced when attempting to modernize an old legacy application that is heavily rooted in the business is to envision how the disparate parts of the new system will interact together to provide a similar business solution to the one the legacy provided.
Examples: Let’s review a couple examples of pitfalls that could become major obstacles in the way of successful delivery:
Challenge 1: Hey, where did my extract go?
Some legacy Batches (programs that are scheduled to run unattended by users) extract newly entered records according to certain criteria to a flat-file. This process is followed by another batch that reads the extracted records, updates them according to certain logic, then populates some other table in the system with them (see figure 1).
A Modernization Specialist (a Developer in the role of System Analyst) modernizing such a set of Batches can reasonably design a modernized System-Event (a program that may have no interface and is usually scheduled to run unattended) that simply skips the extract part and runs a script to insert the records into the destination table with the required updates (see figure 2). Meanwhile, the System Architect (in charge of making core, high-level system design decisions) might have reached an agreement with a 3rd-party that expects to be fed with the flat-file extract to keep sending them the file as is (not being aware of the history behind the file generation).
Once the modernized System-Event is built, there will be no flat-file generated which means that the 3rd-party would not be receiving their file. This kind of problem is actually hard to detect, because all parties have assumed no changes to the existing extract and hence minimal follow-ups.
Prevention: Clear communication between System Analysts during the design phase minimizes the chance for such pitfalls to happen. The System Architect can lead the System Analyst group in one or more sessions to secure against missing pieces.
Challenge 2: Report numbers look all funny!
While most legacy reports are produced by the programming language code as part of the program, the reporting technology to be used in a modernized application is very likely to incorporate a reporting server (Cognos, Crystal Reports, etc.). This presents the challenge of synchronizing modernized application programs calls to related modernized reports.
Consider the situation where a legacy Batch made of 5 legacy programs, each producing 1 legacy report being modernized into only 2 modernized programs. If we don’t keep track of which legacy report is executed when, and ensure that we are calling the modernized reports from the equivalent stages of modernized System-Event processing, the report numbers will not match.
Prevention: We have to start by proper documentation of legacy reports and where they are called from. This is to be followed by documenting the modernized reports and their parameters (we may combine a few reports together, ignore some reports and generate new ones) and finally properly linking the modernized reports definitions to the legacy ones in order to empower the developers modernizing the Batch code with enough information to make the right report calls at the right time.
Conclusion: A legacy modernization project can be a huge undertaking. Paying attention to details and making the right modernization decisions is not enough to ensure successful delivery. You may modernize every part of an application, but the new pieces may still not work together to deliver the same solution the legacy application delivered, hence delivery failure!
The modernization methodology should be comprehensive enough to ensure that the big picture is not blurred by all the details.
- Sinan Ali
