Traditional and Nontraditional Approaches to Application Modernization

A discussion of traditional and nontraditional approaches and techniques for application modernization.

This is the fourth post in this series on application modernization. The focus here is on a discussion of traditional and nontraditional approaches and techniques for application modernization. It’s difficult to imagine modernizing an application without opening up the source code, but when you examine the details behind the nontraditional approaches, you can see the ways they can be used and the benefits they bring.  

What’s the Traditional Approach?

Traditional modernization is the conventional way to modernize business applications. These operational applications can be anything from COBOL on a mainframe to a client-server or web-hosted application with multiple tiers or layers. Traditional modernization involves opening up the application source code and changing it. 

Traditional modernization for long standing applications is often associated with intense use of different middleware software components and products. For decades, middleware has played the role of programmer productivity agent. In this role, it injects programmers’ work with high-quality functions at low costs. Let’s look at CICS, as an example, in order to see how interfaces might be used to enhance the functionality of an application. These interfaces can be used in both traditional and nontraditional ways.

Interfaces to CICS Transactions and Programs

CICS has an intense variety of interfaces that have been developed over the decades. This variety gives programmers a tremendous diversity of ways to work with CICS transactions and programs. In the overview of CICS external interfaces, more than 10 different powerful interfaces are discussed. Here is a quick view:

1. WebSphere MQ users can use the CICS 3270 bridge to access CICS transactions
2. MVS applications running in MVS address spaces can use the External CICS Interface (EXCI) to access CICS programs
3. ONC RPC clients can use CICS ONC RPC support to access CICS programs
4. DCE RPC clients use the Application Support server to access CICS programs
5. User socket applications can use the CICS Sockets feature of CICS Transaction Server
6. Web browsers can use a variety of methods, including the CICS Web support as a CICS-provided facility for supporting Web browsers
7. Java Virtual Machine applications can use a local gateway connection that uses the EXCI to pass requests to CICS
8. Java-enabled web browsers can use applets that communicate with CICS 
9. CICS client applications use a distributed CICS client (either CICS Transaction Gateway or the CICS Universal Client) and the ECI or the EPI
10. Programs running in CICS Servers on any platform can use EXEC CICS LINK to call a CICS program, or they can use transaction routing to send transaction requests to CICS Transaction Server. Programs running in CICS Transaction Server can use the CICS front end-programming interface (FEPI) to start transactions in the same or another instance of CICS Transaction Server.  
11. Telnet clients can use TN3270 to start transactions 
12. Users of the IBM 3270 Display System can start transactions (the traditional method of introducing work to CICS Transaction Server) or use intelligent displays emulating a 3270 Display System 

If you are seeking to modernize a CICS application, this list of interfaces (along with their informative support documents) is a place to start to explore. Certainly, these interfaces aren’t the only factors to consider but it would be foolish to overlook these areas of opportunity.

What’s the Nontraditional Approach?

The information about nontraditional approaches is dominated with discussions of REST and SOAP. Use of REST and SOAP (and some of the other interfaces already described) doesn’t require modifications to the application but rather seeks to develop modules that “sit on top of” or “outside of” the application. Java often plays a role in this as well as the program that drives the REST and SOAP API calls. 

This is a non-disruptive way of harvesting data and application functionality without actually changing the application. For example, to revise the application’s UI, leave the old one in place and present the new UI using API development and management software. No COBOL updates, just a new presentation layer. This approach is gaining traction, but it’s not for use in every situation.  

Inside out Versus Outside in  

Changing an application “inside out” is the traditional approach that I wrote about earlier in this post. If, for example, you want to add a completely new UI, you change the application to handle this. In the program logic, you might examine the source device of the inquiry, determine that it’s from a smart device, then invoke a different set of middleware to create and manage the presentation layer. This change is a functional change made inside the application. How would we do this “outside in”?

The “outside in” approach requires middleware but typically no changes to the running application itself. Instead, a module is created that uses APIs like REST or SOAP to invoke the application functionality, gather data and present it in a new way on an intelligent device. This is just one of many uses of this approach. It’s used for more than just the UI. 

The acronym “API” has been around for decades and means different things to different people depending on when you started to work in IT. Context is everything when you’re trying to figure out the kind of API that’s being discussed. Chances are the application already uses APIs like CICS or IMS commands, but REST and SOAP are different. How are REST and SOAP different? And how are the Java modules containing the REST and SOAP calls combined into something meaningful to a user of the application? 

What’s Next?

In the next post, I’ll focus on different aspects of the “outside in” approach, specifically REST and SOAP. I’ll also explain base components with Java and other languages and other layers of software and organization like microservices and management control.  

---