The Migration/Modernization Dilemma

Transcription

1 The Migration/Modernization Dilemma By William Calcagni

2 Approaches to Legacy Conversion For many years businesses have sought to reduce costs by moving their legacy applications and databases to hardware that runs under Windows. Often these legacy applications run on mainframe computers using block mode terminals such as 3270s and are written in COBOL utilizing mainframe database technology such as VSAM or DB2. In contrast, the desired end state for the application is to run on low cost hardware with an interactive GUI interface using an object oriented language such as C# and a more fully featured database. In order to move from the present state to the desired state several possible paths exist: Re-architecting, Platform Migration, and/or Modernization. Re-architecting (Rewriting) Perhaps the most conceptually appealing approach is to re-architect the application for the new target hardware and software environment. This is often billed as the ultimate modernization process. The argument is made that the application can take advantage of the full capabilities of object oriented languages and relational databases while providing the users with an attractive and interactive GUI interface that fully integrates with the operating system. The argument continues that the existing business logic can be mined from the current application and embedded in the new application using equivalent logic in the object oriented language. Cost Factors of Re-architecting While conceptually appealing, this approach has historically proven to be the most expensive, time consuming and risky choice. It is the most expensive because of several factors. First, the business logic must be mined from the existing application. Usually there is little or no documentation and even when documentation exists it seldom reflects the current state of the application. Once the application logic is mined, a model is usually developed. Then the application is rewritten in a new language, the database is redesigned to a relational model and the testing process begins. This is expensive because most of the work is usually done by consultants. The existing staff rarely has the expertise in the target technologies and rarely has the time to completely document the existing application. If they had the time to document the system they would have already done so. So the work is tasked to consultants whose cost per hour usually exceeds the in-house staff rate. This approach is also the most time consuming for the same reasons it is the most expensive it takes a long time for the consultants to learn enough about the application to do their work. The mining of the business logic can consume many man-months of effort. This is followed by a complete development effort. Since 100% of the code is new, extensive testing is required. All of this takes a lot of time and money.

3 Risk Factors of Re-architecting This approach is also the most risky. First, the job of determining the business rules usually falls to people who have no knowledge of the application. To the extent that experienced staff members assist, they are diverted from ongoing maintenance and enhancement of the existing application. This can cause the business to fall behind its competitors in advancing their technology. Second, since 100% of the application is new code, extensive testing is required not only to correct programming bugs but to ensure that the new application follows the same business rules as the old one. To the extent that development staff and user staff are absorbed in the process of testing the new application they are distracted from the business of the company and from maintaining competitiveness. There are numerous examples of companies that launched re-architecting projects only to find themselves 5 years into a 2 year rewrite. They then had to abandon the project due to cost and time overruns. Meanwhile the companies that attempted them lost market position while they were absorbed in the re-architecting process.

4 Platform Migration Another strategy that is conceptually appealing is to migrate the existing application from its currently platform and database to a functionally equivalent application running a different dialect of COBOL on a Windows system. Using this approach, the business logic is preserved intact and is shifted to the new platform via a code migration that is often referred to as a Lift and Shift. VSAM files might be converted from hierarchical to relational as necessary and the database access code in the application programs is modified accordingly. Data migration can often be accomplished using automated tools. Cost Factors of Platform Migration This approach usually results in the lowest cost and lowest risk because the existing business logic is preserved and the process can be at least partially automated. This reduces the cost and the amount of time necessary to reach the desired end state. Additionally, less testing is required because application logic has been migrated rather than re-written and the process has been automated thereby guaranteeing consistency. Risk Factors of Platform Migration These factors stated above reduce risk. The primary negative to this approach is that, from the point of view of the end user, nothing has changed. From the point of view of senior management, a considerable commitment of time and money has been made without improving on the competitiveness of the business. At the end of the day, the result is still a portfolio of COBOL applications and a staff of COBOL programmers doing the same things they always did code COBOL, access data via EXEC SQL and communicate with users via EXEC CICS. The UI is still encapsulated in BMS Maps that continue to be maintained. For this reason, many companies look to modernization instead of migration. Personnel Factors of Platform Migration Another negative is a corollary to the problem mentioned above. Because the application is still COBOL, the need to find COBOL programmers still exists. As anyone with responsibility for staffing a COBOL development team know, the number of COBOL programmers is constantly dwindling due to retirement and lack of COBOL training at the college or technical school level. This forces managers to either compete for a constantly diminishing pool of trained COBOL developers or to create them through an in-house training program. Either of these options adds cost.

5 Modernization A modernization strategy seeks to preserve the logic of the application while replacing the COBOL programming language with a modern, object-oriented language such as C#. In addition, through detailed analysis and abstraction of the COBOL program data and logic, restructuring to a more object oriented model can take place. Value Proposition to Modernization While most COBOL dialects claim to have object oriented capabilities the truth is that COBOL was never meant to be an object oriented language and most COBOL programmers have little practical experience in true object oriented design or development. By contrast, programmers trained in C# have been engrained with the design principals of object oriented development and most have also been extensively exposed to modern design patterns such as REST and Model-View- Controller methodologies. Modernizing the application by migrating it to an object-oriented language and a rich development environment such as Visual Studio allows future enhancement of the application to take advantage of these methodologies. It also simplifies testing, debugging and deployment. Unlike a platform migration, the end state of a modernization is to change the way the development staff works. Rather than business as usual on a different platform, the development staff now features development in C# using true object oriented programming techniques, modern design patterns, interactive debugging and automated testing all coordinated within an advanced interactive development environment. Variants of Modernization There are a number of variants to the modernization model that are worth examining. One conceptually appealing variant claims that the application can be completely decoupled from the language and, therefore, can be transformed from being written to conform to the rules and design constraints of COBOL logic to an application that appears to have been originally designed in an object oriented language. Unfortunately, this approach ignores the reality that application designs are constrained by the language in which they are to be written. This is true even within object oriented languages. Consider C++ and C#. Both are object oriented languages. However, it would be next to impossible to automatically migrate a C++ application to C# and have it look and function exactly as if it had been originally designed for C#. The chance of success with COBOL is even smaller. The result is usually a partially automated modernization that requires a great deal of manual intervention in order to attempt to resolve the inherent conflicts between the COBOL programming model and any object oriented model. The reality is that an application design is as much a creature of the implementation language as a brain is a creature of the body in which it lives. Likewise, an effective modernization strategy has to accept certain realities created by the original choice of language, namely COBOL.

6 The Key Question: How much transformation? In any modernization, the goal is to create, to the maximum extent practical, an application that can be maintained using object oriented techniques i.e. one that is as object oriented as it can be. However, working against this is the necessity of preserving some of the existing data structure and functionality to ensure accuracy and maintainability. This, in turn, requires a consistent and accurate transformation of data and logic in the source language to the target language. Each time a structural change is made in mapping from the original to the target, all the logic that operates on that structure must be changed. For example, trying to completely abstract a series of COBOL programs to create a set of classes that define business processes and encapsulate only the data for that process involves a massive restructuring of the data. That, in turn, will require a massive restructuring of the logic that operates on that data. The original system is proven and reliable because, through years of effort, the data structures and logic are internally consistent and certain protocols and conventions are followed throughout the system. The more the structure and logic are altered from the original, the more this internal consistency breaks down and the resulting code becomes less of a migration and more of a rewrite. The resulting code is, to a large extent, new logic rather than a faithful mapping of the proven logic. Therefore, this new code can expect error rates consistent with new code exactly the problem an automated migration is designed to prevent. Cost/Risk Analysis The modernization approach shares much in common with a platform migration in terms of cost and risk so long as the degree of modernization is kept within limited bounds and that is the Migration/Modernization dilemma: the more a business attempts to transform the application while modernizing it, the more the costs and risks approach that of rearchitecting.

7 4 Cost/Risk C o s t Cost/Risk 0 Migration Modernization Rearchitect As the approach to legacy conversion moves toward re-architecting, costs/risks increase exponentially. Language Portability Solutions Modernization Approach Language Portability s team has been involved in conversions, migrations and modernizations for over 15 years. During that time we have seen and participated in dozens of projects. From that experience Language Portability has developed a tested and proven approach that combines the best features of migration and modernization while keeping the project at the low end of the cost/risk curve. The approach can best be described as a sequence of migrate, modernize and implement, then enhance and/or re-architect going forward. Language Portability Modernization Language Portability s modernization is done using Language Portability s extensive set of automated tools. These tools provide automated migration of programs and databases including the necessary conversion of both database structures and access logic to account for SQL differences between databases. Because the process is automated, all programs in the application are changed consistently. This reduces the amount of testing required. During this migration phase, the application logic is automatically filtered from COBOL to C#. This is done using a proven model of maximum practical modernization. This means that extensive analysis is done to the application programs to transform them to the maximum degree practical into object oriented replacements. However, unlike the complete abstraction variant, this approach recognizes the reality that, in order to avoid interjecting difficult to find errors, certain conventions dictated by COBOL must be followed even in the C# application. Through its years of experience helping businesses successfully migrate and modernize applications,

8 Language Portability has developed a modernization strategy that provides a maximum degree of modernization without pushing the project up the risk/cost curve. 4 Cost/Risk C o s t Cost/Risk 0 Migration Modernization Rearchitect Legacy conversion moves toward re-architecting, but costs/risks increase only marginally. COBOL to C# Conversion Often one of the primary motivations for management in moving to a Windows platform is the ability to have future development done in an object oriented language such as C#. This is the crux of the re-architect argument. Language Portability has a strategy that allows the business to use the least risky and lowest cost solution automated migration and modernization while positioning the application to be maintained and enhanced using an object oriented language. Short of rewriting the application, no COBOL program can be made as completely object oriented as one originally written in C#. However, the data and business logic can be converted to objects and methods that can be consumed by true object oriented languages. This allows all future development to be done using object oriented language and design patterns. Enhancements to the existing system are made using the same object oriented language but using a set of classes and methods that account for the realities of the language from which they came (COBOL).

9 Conclusion This approach has grown out of Language Portability s 15+ years of migration experience and 20+ years of tool building experience. Using Language Portability s measured approach to modernization a business can obtain the greatest combination of cost savings, risk management and application improvement. The application is moved off of the mainframe quickly and efficiently, maintaining original constructs and standards, thus reducing costs. The application is migrated and modernized using proven tools and techniques and the application is positioned for incremental improvement and re-architecting in the least disruptive manner.