Create New Interfaces for Existing Assets

This is the final installment of a five-part series about how mainframe shops can embrace the needs of new mobile workloads.

Last time, we looked at a solution that would replace the existing online processing and add new storage for the new application, but leverage all other parts of the legacy infrastructure. In this post, we’ll take a close look at perhaps the best: one that leverages what you have, and gets you where you want to be with a minimum of time and expense.

Of course, existing applications weren’t built with mobile access or, in most cases, even web access in mind. This solution is an integration framework that provides APIs / servlets that are able to deliver the needed interface to the existing online processing environment. The solution extends the existing online processing by implementing an integration layer that can define and deliver customized APIs to interact with the existing systems.

The new infrastructure provides the online processing environment with new screens that are designed for web and mobile. This makes a lot of sense in environments where the need is just to enable the web / mobile to be part of what is already being done today, or where improved mobile user interfaces are badly needed.

New Interfaces

The image above shows an environment updated with this type of configuration. To the original mainframe configuration in Part 1, we have added two new components: a new integration layer that provides some new APIs that drive a set of new web / mobile interfaces, and the interfaces themselves. Here is a summary of what the environment looks like in this scenario:

  • Data Storage (Db2, IMS, VSAM, IDMS, QSAM, Oracle, etc.) – Unchanged from before
  • Multiple Programs that are linked together with JCL that define the batch jobs that process the data – Unchanged from before
  • Multiple Transaction Programs that are managed and sequenced by the online processing environment, Transaction Server (CICS, IMS-TS, etc.) – Unchanged from before
  • New Integration that can be used to define and deliver customized APIs that can drive new web and mobile interfaces
  • New Web / Mobile GUI Interfaces – New components that are associated with the legacy TS

The APIs present the GUI interfaces, and can actually reside anywhere: on the mainframe under z/OS or zLinux, or on a distributed system.

Benefits of New Online Processing and Data Storage

  • This solution is one of the shortest paths possible for supporting web and/or mobile
  • Fully leverages existing investment in batch and online processing
  • Provides an infrastructure that is adaptable, that can start with simple integration, and that can grow over time
  • Solution has built-in flexibility for future requirements

Drawbacks of New Online Processing and Data Storage

  • Not all transactions developed can easily be repurposed to work with a different screen because the screens are embedded in the transaction
  • Little to no opportunity to move workloads to other platforms
  • Two user interaction scenarios to maintain – existing and the new web / mobile

This is probably the most effective approach for protecting the existing investment (in code) and for providing the richest experience for mobile and web users.

Development Details

An integration layer solution provides APIs delivering modern web and mobile application that works well with modern application construction such as JSON, XML, HTTP, JS, REST, etc. They are also developed in modern languages—server side JS, Java, and .NET, etc.—familiar to web and mobile application developers, enabling them to understand how to extend the APIs as the demands from web and mobile applications change over time. The APIs are specific to the transactions and they may need to link several existing transactions together.

The environment in which APIs are developed has a deep level integration with the current online processing system. More simplistic interfaces such as screen scraping will show a rapid return, but will quickly run into challenges as the sophistication of the users’ demands evolve.

Using APIs in this way also minimizes the impact the integration will have on the additional work added to the existing system. New workloads from mobile and web applications will add more load to the existing system, this is unavoidable, but ideally the integration processing should be minimal.

Conclusion

The growth of web and mobile usage and the looming impact of IoT have created a demand for legacy systems to conform to these customer access preferences. This has led to a wealth of good technology choices for developing these new online systems and solutions. Legacy improvements can be accomplished in many ways, including creating:

  • New interfaces for existing assets
  • A new online environment
  • A new online environment with new data storage

And in some cases an organization can opt for the complete forklift replacement solution, which will always be the most complex, expensive and time-consuming and personnel resource-consuming solution. It should be noted that some rare instances exist where this is the only practical solution.

All these solutions have advantages, but Solution 1—New Interfaces for Existing Assets—will get you there faster, will cost less than the other solutions, and will allow you to leverage existing reliable, secure, and trusted legacy assets. It will also be inherently less risky: you can leverage staff with more modern programming skill sets right away, and you will require less from your mainframe-centric staff.