Screen-Based Modernization: Challenging the Myths

by Greg Mummah

February 9, 2010

Myth #3: Screen-based modernization solutions don’t perform or scale well. Organizations that are exploring screen-based modernization solutions are typically concerned that by introducing a layer on top of the mainframe, they may lose some of the performance and scalability characteristics the business expects. They also question whether the modernization layer will require additional mainframe resources. Proper evaluation of these concerns begins with understanding how screen-based modernization solutions can be deployed and what mainframe resources they use.

Most screen-based modernization solutions are architecturally flexible. Figure 3 shows three basic deployment choices. Each of these options has advantages and disadvantages, and the best choice for a specific project depends on requirements, available mainframe resources and application types, organizational knowledge of and comfort with distributed platforms, and other factors. Some modernization products also support other methods of application and database access, such as COMMAREA, Front End Programming Interface (FEPI), and Java Database Connectivity (JDBC). Specific to screen-based modernization, the trend is to choose a distributed architecture. Figure 4 shows a high-level architecture for a distributed solution.





Using this architecture, mainframe resource usage is limited to supporting the required TN3270 sessions—a predictable, reliable, and well-understood access method. By allowing the mainframe to do what it does best and offloading modernization processes to the distributed platform, resource utilization is minimized.

The architecture shown in Figure 4 would perform well in providing HTML-based GUI access to applications or services for other applications such as Web portals. But what about application users who expect the sub-second response time and keyboard buffering capabilities available in emulation—people such as contact center representatives, who are evaluated based on speed and performance?

A benefit of emulation is that it uses a direct mainframe connection. It’s faster than a multi-tiered solution delivered via the architecture in Figure 4. This contributes to the myth that screen-based solutions don’t perform well—the increased architectural complexity and choice of user access (often a browser) make the solution slower when compared to emulation. You might be able to re-engineer the workflow of the application at the modernization layer to improve performance, but the browser itself won’t allow emulation features users expect, such as keyboard buffering.

Your mainframe serves different types of application users; some of them expect emulation-level performance. Modernization solution vendors know that, and many offer client-style deployments that replace desktop emulation with a Java or Windows GUI equivalent. You can typically deploy these solutions to desktops as browser plug-ins— applications that run inside the browser but leverage a direct mainframe connection, just as emulation does. This type of deployment blends emulator-like performance with Web delivery (see Figure 5).




More info about the author:

Greg Mummah (no biography detail available)