AEM™ Task 8. Transformation Planning

Transformation Planning is critical. This plan identifies:

• Which transformation activities will be automated versus manual to best meet goals related to quality and timeliness
• Roles and responsibilities of project participants
• Application releases
• Transformation rules for specific types of application artifacts, including:
  • Data layer
  • Presentation layer
  • Processing logic
  • Data migration
• Testing and acceptance procedures

Once we define what is to be created, we document how the transformation is to be performed. The goal is to gain agreement among all project stakeholders on how the transformation process should be defined to best account for all the findings of Tasks 1 through 7.

There are multiple possibilities for transformation approaches. For example, migrating from one version of COBOL to another involves relatively minor differences in the programming environment. In that instance, questions to be addressed in Transformation Planning are likely to include:

• Should the existing program structure and organization be retained in the new application, or should the programs be re-factored and reorganized?
• Will the existing screen appearance be replicated, or should the screens be converted to a new look and feel? A common example might be mainframe "green screens" converted to more modern GUI screens.
• When the two versions of COBOL differ in how a particular type of action is coded, how should the code be converted?
• Which of these conversions can be automated (or partially automated) effectively?

The answers to these questions depend on the characteristics of the existing applications, as well as the client's specific transformation goals. Achieving strong performance and highly maintainable new code often requires some degree of reorganization, with an appropriate blend of automated and manual processing during the conversion.

As an alternative example, consider the transformation of procedural legacy code (e.g. Assembler, Natural, or COBOL) to an object-oriented environment such as .Net or Java. The paradigm shift is much larger in a case like this, which requires a different transformation approach. Issues include:

• How are classes to be identified based on the legacy functionality? What principles should be used for identifying classes?
• How should the processing logic of the legacy code be leveraged for creation of code within the target classes?

The reorganization challenges are different in this case, so a different transformation approach is required. We have extensive experience with a wide variety of such conversion scenarios and can guide clients in defining an effective transformation approach specific to their challenges and goals.

As part of Transformation Planning, we re-orient our migration tools and templates to fit the unique needs of the situation. Our transformation plans include manual software engineering activities for the key design, re-factoring, and assessment steps. This balance of automated tools and the human touch is critical for dealing with the potentially overwhelming size and complexity of many legacy applications, while producing the quality maintainable code necessary to provide a positive return on investment in the long term.

Transformation Planning Output:

• Transformation Plan document, personalized for each client’s needs