This is the fourth tip in a series on migrating applications off the mainframe. Check out part 3, on tuning migrated applications for the new platform.
In this series on best practices for migrating off the mainframe, the previous three parts took a "just-the-facts-ma'am" approach. If your aim is simply to successfully transition users to an equivalent non-mainframe environment, then part 4 will not be useful to you. However, if you anticipate getting more out of your original mainframe code in the future, there are several straightforward additional steps that may pay off handsomely down the road. The key point to remember is that these steps and tactics should be baked in from the beginning of the project, or else they will involve unnecessary extra costs.
Broadly speaking, these value-added migration tactics include.
- Application modernization
- Distributed integration
Mainframe application modernization
Mainframe applications continue to be modernized, involving support for Web browser and PC access and Web-servicization. However, there are often plenty of remaining applications for which this has not yet been done. The migrater should consider Web-servicizing as many apps during migration as possible. Major mainframe software providers have plenty of tools and services for the task, whether you want to Web-servicize before moving the application or after it arrives on the target platform. There is no hard-and-fast rule about which approach is better; but the more you know about the structure and actions of a mainframe app, the easier its encapsulation as a "Web service provider."
It is easy to underestimate the usefulness of mainframe application modernization. However, migraters should understand that if they want to set up an internal cloud or use an external one, the migrated app will not be usable in a cloud unless it is converted to a Web service. Cloud implementation, by definition, virtualizes and groups apps as Web services. To exclude business-critical apps from that type of flexibility would be to lose much of the cloud computing advantage to the enterprise.
Re-engineering mainframe apps
In part 1, I noted that re-engineering was a good way to migrate those mainframe applications for which abstracting a model of the program was feasible. The side effect of re-engineering a mainframe application is typically a model standardized to allow modification during development's design stage (e.g., UML). This abstraction allows not only generation of app instances for all major programming languages and environments (e.g., Java on all platforms), but also much easier modification and upgrade of the program by modifying the design rather than the app itself.
The task of the smart migrater, therefore, is to ensure that the re-engineering tool generates a standardized model suitable for the enterprise's existing development process, for all re-engineered mainframe applications, and possibly for some of the recompiled ones. This will ensure that if the enterprise later wishes to port the app to another platform or if it wishes to modernize, extend, or combine the app, the process of doing so will be swifter and without risk.
Nothing terrible happens if the migrated application continues to service the same end users in the same way on the target platform. However, good things happen when the migrated application starts communicating with other target-platform applications over a network. Business processes are enhanced and new end users leverage the application.
Again, the key task of the migrater is to set up the application as it is being migrated so it is ready for distributed communication and integration with other distributed applications. It is a frequent misconception that this involves setting up a standardized way of communication between applications. Rather, the key aim of the migrater is to set up a standardized way of exchanging data between applications -- and, more specifically, to define the mainframe's metadata and include it in a global metadata repository that also includes target-platform data. Data-combining technologies like ETL or IBM's Information Server can then use the data to do Master Data Management, cross-enterprise reporting and the like.
Anticipating the ways that target-platform peculiarities can affect app performance and security can save a lot of grief for the migrater and the end user of the application. Moreover, this marks the end stage of a successful process; once an app runs, performs/scales and provides adequate security on the target platform, the main goals of migration off the mainframe should have been fulfilled.
However, it is likely that there will be more challenges on the way. What if the application needs to be moved to an internal or external cloud in the near future? Get-the-job-done mainframe migration does not guarantee readiness for a cloud. Is there a possibility that the app may need to be moved from Windows to Linux or back? Can you get more out of the migrated app, such as composition with other apps to enhance or integrate business processes? What if you have to combine the app with another from a company you just acquired?
A little forethought during the migration may save a lot of time in future projects like these. Here, I've discussed the relatively straightforward ways that a migrated app can be spruced up during the migration process to meet future needs.
ABOUT THE AUTHOR: Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures. Infostructure Associates aims to provide thought leadership and sound advice to vendors and users of information technology. This document is the result of Infostructure Associates-sponsored research. Infostructure Associates believes that its findings are objective and represent the best analysis available at the time of publication.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.