In-Depth

Legacy Migration: Architecture, Platform, or Both?

• 08/01/1999

During the past two years, all eyes have been focused on Y2K issues. Enterprises have had to make very binary decisions -- dump their legacy applications and go ERP, or remediate the legacy applications for long-term use. With the millennium nearly upon us, all of those decisions have now been made. The remediated legacy applications that remain have been selected as the core applications for the enterprise's business for the foreseeable future. And, as Y2K remediation projects on these applications are completed, enterprises are now looking at their future plans for these applications. Most businesses are now seeking to capitalize on the millions of dollars invested in this set of remediated source code. The main questions remaining for these IT departments are:

• How can the company now evolve and extend these legacy applications to better meet future emerging business needs?
• How can the company recoup some of its investment in Y2K remediation?

Even though these legacy applications have been chosen for Y2K remediation because they meet today’s business requirements, those needs and the applications are not static. Future business needs usually revolve around adapting to e-business requirements, including Web enabling the applications, redesigning the application to supply new or more integrated services to customers, and redesigning the application interface. Of course, it is important to do all of this at lower cost, while retaining or improving the scalability and performance that mainframe applications have traditionally enjoyed.

Since the business rules and data often remain unaffected by these emerging business needs, these remediated legacy applications provide a solid foundation for evolution into the emerging e-business world. The question still remains as how best to achieve this evolution. Two techniques are becoming popular:

• Architecture migration, or re-using the existing business rules and data structures inside as components in a new component-based development (CBD) system.
• Platform migration, or moving the existing applications to UNIX or Windows NT to achieve substantially lower operating costs and then adding e-business capabilities through client interfaces.

Both approaches are viable and are based on reusing today’s applications, business rules and data structures.

State-of-the-art, component-based software engineering approaches are ideally suited to the development of brand-new, standalone applications. However, most organizations must contend with a significant investment in legacy applications, and will be forced to face the problem of integrating these new applications with their legacy code base.

It is clear that there is a need for technology to facilitate the integration of 3270 terminal-oriented applications. In order to allow these legacy applications to participate in next-generation IT architectures, this integration software must meet a number of requirements.

Internet awareness. It is widely anticipated that the Internet, or some business-funded successor thereof, will play a major role in near-future enterprise architectures. Of all requirements listed here, the importance of being able to operate in TCP/IP networked environments, and in tandem with other "Web technologies" cannot be overstated.

Interface rejuvenation. When 3270 terminal interfaces were originally designed, the possibility that members of the general public would ever use these interfaces was often never considered. Invariably, the assumption was that these interfaces would only ever be used by knowledge workers, familiar with both the 3270 terminal paradigm and the internal workings of the owning enterprise. Once these applications are deployed externally, their interfaces must be usable by members of the general public with no prior experience with the application.

Application consolidation. A number of Web-enabled terminal emulators have emerged recently, which simply provide Internet access to legacy mainframe applications. The more sophisticated of these also provide the ability to rejuvenate application interfaces via "screen scraping" approaches. These products are very effective at building attractive and intuitive interfaces, often with low required user-deployment effort. However, these products impose a strict one-to-one correspondence between the logical screen sent by the mainframe application, and the graphical interface presented to the Web browser user. In order to move to the next level of application usability, the removal of this inflexibility is absolutely crucial. A client application must be capable of maintaining multiple simultaneous terminal sessions, potentially with multiple distributed 3270 application subsystems. By constructing a composite application interface to present the data returned by these parallel terminal sessions, new levels of application usability and hence end user productivity are made possible.

Componentization of legacy application access code. We have discussed how state-of-the art software development approaches promote the concepts of code reuse and complexity management via the encapsulation of self-contained code fragments into components. Any modern software development technology should support these initiatives, and should also integrate with the latest development environments.

Deployment flexibility. Depending upon the specific nature of individual application characteristics and requirements, it may be desirable to deploy any integration technology on either a desktop or mid-tier machine.

Distributed Object architecture portability. There are currently three competing distributed object architectures, namely CORBA, DCOM and Java Beans. As yet, it is unclear which, if any, of these alternatives will emerge to be the dominant technology. It is therefore important that any integration technology will function in any of the competing schemes.

No change to legacy applications. Restructuring of legacy code can be high risk; any problems introduced are likely to severely disrupt the existing end user community. As a result, enterprises are often extremely reluctant to agree to code modification.

Software to Meet Legacy Integration Requirements

New component-based Web integration products have started to come onto the market. When packaged as a Java Bean, this software can encapsulate the functionality of a 3270 terminal emulator. An easy-to-use API is exposed, which allows multiple logical 3270 terminal sessions to be initiated and controlled programmatically from a single Java executable entity. It is important that this type of software adhere to standard Java Bean conventions in order to expose its public methods, variables and events. This allows its importation into popular Java Bean-aware Integrated Development Environments such as Borland's JBuilder or IBM's VisualAge for Java. Facilities within these environments are designed to simplify application development and deployment. One example of a component-based product is UniKix Technologies’ 3270 Screen Bean.

Most 3270 terminal-oriented applications are structured hierarchically. Initial access is often channeled through a common initial screen, which might force the end user to supply a valid userid/password pair. After successfully negotiating through this initial logon screen, a typical application will force the user to navigate through multiple levels of nested menus to access the desired screen. A simple business task may require this laborious navigation process to be repeated multiple times, perhaps against multiple back end 3270 application subsystems. Products like the 3270 Screen Bean are specifically designed to allow the streamlining of this common type of user interaction pattern. Its API allows the automation of laborious navigation and data acquisition end user activity. An innovative aspect of this API allows legacy data to be stored away during navigation, for retrieval and processing at any later point in time.

At the very highest level, there are two alternative approaches to the deployment of 3270 component software. These alternatives are characterized by the execution location of the bean; the bean either executes in a highly distributed manner on multiple desktop machines, or on a more centralized mid-tier machine.

SunGard Investment Systems provides its’ SUNSTAR investment management application to financial services companies. As a mainframe CICS application, SUNSTAR has many different 3270 screen displays. These include various log-on screens (for the network, the system, the application and the function). Once within the application, the user can choose from many different functions, each of which displays different elements of the customer’s portfolio.

SunGard wanted to significantly ease user log-on functions and to create new screens that navigated a dozen screens, pulling frequently used results from six separate 3270 screens.

Before creating the 3270 navigation beans, it is important to first analyze the application. This involves highlighting different paths through the application, noting the information needed for input, and the output to be stored and displayed later. This is exactly what SunGard did; they decided upon a path that navigated through 12 different screens. The first four screens sign the user into the application. The next two screens are menus, followed by another six screens of customer information.

It was decided that the new SUNSTAR application would be made up of several beans that built on top of one another, each bean leaving the terminal in the correct state and position for the next bean. It seemed logical to have one bean whose sole purpose would be to log the user on; another bean would select the menu options, with three additional beans used to drill down the customer information screens, extracting information from each one. The five navigation beans were created without writing a line of code by using UniKix’s Pathfinder Bean Developer, which automates navigation through any legacy 3270 application and identifies data fields to be shared and integrated with other applications. The newly created beans were then dropped into an IDE -- JBuilder V2.0 -- and a new Java application was created.

The new application contains a small amount of code to tie the beans together, provide some error handling, and extract and display the data. The main bulk of the code is for the presentation.

The new SUNSTAR application has only one input: an Account Number. The information that is now presented to the user consists of data retrieved from six screens of customer information.

The same component wrapper tools (3270 Screen Bean and Pathfinder Bean Developer) can also be used to create servlet components to run in an application server container. Servlets provide several advantages for the application, and are usually more appropriate for large enterprise applications. Servlet-based differences include HTML/XML presentation, secure HTTP, connecting pooling (maintain state and session servlet) and pool of available 3270 connection beans (allocate for duration of interaction and pass session data between applications).

The use of servlets and the servlet architecture is a superior approach to the use of applets. Applet (now servlet) execution is left on the server, removing the large download times incurred with the use of applets. The presentation is no longer restricted to only Java. A mixture of JavaServer Pages, JavaScript, HTML or XML can be used to create powerful new front ends. All of this information can then be secured with the use of a secure protocol such as SHTTP. Development time will be greatly reduced by using servlets; servlet development is very small, with no complex presentation code needing to be written. High performance, secure, scaleable Web applications can be created extremely quickly using a combination of the latest technologies, such as Java servlets, XML, HTML, Application Servers, IDEs and 3270 applications.

In the case of platform migration, the focus is on reusing the existing application code and data structure exactly as it is today – but on much less expensive UNIX or NT servers. With this approach, the focus is on cost reduction, typically achieving a 50 percent operating cost reduction for the application. Extension of the business functions in the application would be achieved using the current 3GL languages and tools, although transformation of the customer presentation interface is still possible through Java tools.

With this approach, the underlying application infrastructure or middleware is duplicated on the new Unix or NT platform, enabling the application to run essentially unchanged. For typical mainframe applications, see Figure 1.

Whether adhesive, sealant or resin, National Starch produces thousands of technically advanced products through an international network of 125 manufacturing and customer service centers.

This large, complex enterprise requires an IT system that provides advanced and efficient services. The company embarked on a long-term strategy to move its IT infrastructure to open systems in the early 1990s. The design of the new system called for National Starch to replace some of its existing applications with SAP’s enterprise resource planning package and to integrate the remaining legacy applications with SAP on a common shared Oracle database.

Challenged by the need to quickly find a mainframe migration solution, National Starch first attempted the migration with CICS/6000. But performance problems showed that another solution was required. National Starch turned to UniKix Technologies, which supplies scalable component and legacy open systems middleware for high-performance transaction systems in large enterprises.

UniKix’s first step was to set up a pilot benchmark to compare performance of National Starch’s applications using three potential environments: mainframe, CICS/6000 and UniKix. The results for several jobs run in the pilot showed that UniKix was the only environment that could deliver the performance needed. A job that took seven minutes on the mainframe and 17 minutes with CICS/6000 ran in just three minutes on UniKix. Another job that took two minutes on the mainframe and four minutes on CICS/6000, ran in under a minute on UniKix. Four-hour file-loading jobs on CICS/6000 were done on UniKix in less than 10 minutes. The average performance improvement of UniKix over CICS/6000 on most of the National Starch jobs was seven to one.

With these very clear pilot results, UniKix was selected. A UniKix-National Starch team converted everything that had already been converted to CICS/6000 and moved programs across to UniKix. The project included more than 500 VSAM files and 1,000 programs serving most of National’s locations, with about 100 users. The programs were a mix of enterprise applications – financial, manufacturing, quality control, inventory –- all heart-of-the-business, mission-critical functions that represented years of investment for this global company.

National Starch organized the applications into five groups with each containing a mixture of online and batch programs. With less than five months left to complete the entire migration project, speed was essential. Batches 2 and 3 were the first work project. After three months, the work had progressed so well that Batches 1, 2 and 3 were ready to go live.

The test process was thorough and actually caught several data conversion errors from earlier Y2K remediation work. With less than two months before the deadline, the first big cutover to live production running on UniKix and the SP/2 was ready. The migration went smoothly. The final two batches of applications were completed and all applications went live on UniKix before the deadline.

The National Starch experience shows that successful platform migration allows companies to reuse existing code with significant performance improvements and cost reductions.

With many enterprises having now spent millions of dollars to remediate legacy applications for Y2K, it is clear that legacy applications are here to stay and will probably be around for a lot longer. Having made this Y2K investment, businesses will be reluctant to scrap these applications or to rewrite them, and many will choose to enhance them, as the basis for their emerging e-business needs. Indeed, Butler Group, the leading U.K.-based industry analyst, reported in a recent survey that 96% of respondents considered their existing systems to be sources of components to meet their future business needs.

Tools and technologies now exist to extend these legacy applications into the e-business world of the Web, Java, XML and CORBA – and to do this while re-platforming these existing applications onto powerful, but low cost Unix or NT servers.

About the Author: David Matthews is Vice President of Marketing at UniKix Technologies (Phoenix; www.unikix.com), a leading supplier of open-systems middleware for high-performance transaction systems for large enterprises.