With the growing recognition that modernizing legacy applications makes more sense than completely rewriting them, what are the consequences if we don’t recognize the truth about the steps we should take?
All too often, organizations are pressed for short-term speed at the expense of long-term efficiencies. Legacy application modernization projects face this same hazard, especially if the goal includes revamping the application architecture. To join the ranks of those moving in the direction of agile applications development, some initial investment of time is needed to accomplish the appropriate understanding, analysis, and restructuring of existing business logic embedded in legacy application code.
Although legacy application modernization may appear to be a newly highlighted IT requirement, it is here to stay. Because technology changes are cycling faster with every new paradigm shift, we have to separately identify and manage what is stable; a valuable outcome of a well-managed modernization project. That requires finding ways to separately manage business logic from the technology that provides access to that logic. The reward for this restructuring is that continuous modernization is easier. The speed of technology changes, coupled with the growing requirement for intra-organization software collaboration, makes modernization a must for survival. Think about the positive impact of reusing modernized legacy application code within a new architecture such as the highly touted Services-Oriented Architecture (SOA), or as the implementation code linked to a Model-Driven Architecture (MDA) project, or as the business logic now more easily plugged into an Enterprise Application Integration (EAI) framework.
How do we go about managing the transition from monolithic legacy applications to a more agile environment where we can mix and match business logic into new applications while maintaining business rule consistency and correctness?
TRANSITIONING BY STAGES
Each company is unique. IT resources are scarce. Your priorities are decided by your company’s business needs. As you move through the stages described here, you may choose to stop at any stage. You can derive significant value by implementing the entire architecture; however, not every company is prepared to accomplish all of the steps from modernization through re-engineering and transformation to new languages and technical environments in immediate sequence. What is critical is that you accomplish each stage with the correct, quality deliverables.
When you apply the right methods and techniques, your investment in each stage is secure. Each stage represents a significant step forward to improve your legacy environment, even with a substantial pause between steps . Additionally, because each stage can stand alone, there is no need for rework when a subsequent step is resumed after an interruption. Now let’s look at the recommended stages, which are also highlighted in Figure 1.
STAGE ONE: CLEANING EXISTING PROGRAM CODE