Extend with a new function pattern

← Back to Application modernization patterns

Many organizations rely on core applications on IBM Z to run their business-as-usual operations. In order to accelerate their digital transformation, it is important to embark on a strategy to modernize these core applications and to build new ones. There could also be a backlog of net new functions waiting to be added to an existing application.

Typically, while adding new functions to an existing z/OS based application, organizations face the following common challenges:

• Business risks: Updating core critical mainframe-based monolithic applications to support new business initiatives introduces a range of risks. These include potential disruption to core solutions, timeline for meeting marketplace needs, requiring a large investment, etc. Other challenges also include the effort that is required to develop the new functions and test the application.
• Skill shortage and preference for programming languages familiar to modern developers: There may be a shortage of skills in updating existing applications and there may be a backlog of new functions to be implemented. As organizations transition to digital and online technologies, the need to use Open Enterprise languages (i.e., languages such as Java, Node.js, Python and Go that are familiar to modern developers) that support these capabilities is becoming more critical.
• Preference for cloud based deployment: The organization would like to leverage both Open Enterprise languages and cloud-based deployment. Cloud-native applications use the features of cloud so that enterprises can develop and deploy new capabilities with speed to quickly respond to market demands and remain competitive in the digital environment.

In addition to the development challenges, larger organizations may face other deployment challenges, even for their existing functions, such as local/country data autonomy, optimizing deployment to reduce chattiness in supporting services to be delivered via new channels, and to reduce overall cost.

IBM z/OS supports different options when developing a new function to extend an existing application on z/OS.

IBM Z delivers new hardware features that are specifically designed to improve the performance of business-critical applications written in COBOL and PL/I. These applications are often complex and monolithic in nature so an incremental approach to modernization is recommended. This is because re-writing the entire application can be very costly and pose a high risk to the business. By utilizing the latest COBOL or PL/I compilers you can optimize the performance and operating costs of your business-critical applications. You can also use new language features shipped in these compilers to extend the capabilities of your existing applications.

One can also easily develop the new function as a cloud-native application, and existing applications can easily invoke the new cloud-native application using an API. Cloud native applications can be deployed in a variety of platforms on public and private clouds including on IBM Z and LinuxOne platforms.

IBM Z provides multiple options to deploy a cloud-native application (as shown below)

Available on Linux on Z or LinuxONE:

• Containers on IBM Z and LinuxONE: Containers which enable multiple encapsulated workloads to run on a single Linux instance are available on IBM Z and LinuxONE.
• Red Hat OpenShift for IBM Z and LinuxONE: Red Hat OpenShift provides a trusted Kubernetes enterprise platform that supports modern, hybrid-cloud application development and provides a consistent foundation on IBM Z and LinuxONE.

Available on z/OS:

• IBM z/OS Container Extensions (zCX): zCX is a new feature of z/OS 2.4 that expands and modernizes the z/OS software ecosystem by allowing applications and workloads built for Linux on Z and packaged into a Docker image to run on z/OS.
• IBM zCX Foundation for Red Hat OpenShift (zCX for OpenShift): zCX for OpenShift provides the capability to run Red Hat OpenShift on z/OS, using IBM z/OS Container Extensions. Red Hat OpenShift provides open, enterprise-level, cloud-native tools and orchestration capabilities for your hybrid cloud architecture on z/OS.

Communication between the core application on z/OS and the cloud-native application takes place by using a well-defined interface – an API. With z/OS Connect Enterprise Edition, one can (1) create consumable APIs in minutes to make z/OS applications and data accessible to your hybrid cloud applications and (2) call APIs from within z/OS applications to extend them with the power of cloud native functions. z/OS Connect can be deployed either directly on z/OS or as a container-managed version (IBM Z and Cloud Modernization Stack), which like the cloud-native function can be deployed in the above configurations.

Additionally, IBM z/OS supports development of the new function using Open Enterprise languages. The IBM Open Enterprise language portfolio brings popular programming languages like Java, Go, Node.js and Python into the z/OS platform. These programming languages come with many packages and frameworks that can help you get started and deliver new enhancements quickly. While a new Open Enterprise language-based function can be developed as a cloud-native application, and hence, is deployable on any cloud, there are many key considerations (i.e., lower latency, performance/throughput, security and lower TCOs) that may prefer deploying this function in a collocated manner next to existing z/OS applications (See Collocate applications pattern for further details). Additionally, it may be easier to develop the new open-enterprise language-based function as a tightly integrated function, and have direct access to SOR data (e.g., VSAM and other z/OS based data sources) and integrate under a global transaction scope.

Alternatively, the new functions may be realized by a third-party packaged solution running on any Cloud. Existing applications can easily invoke such a packaged solution using APIs. Finally, for certain scenarios, the new function can also be developed as COBOL based application that is deployed on the Cloud.

The key drivers for selecting each of the solution approaches, and further elaboration of scenarios with examples are provided below.

A. Develop a cloud-native application for API based integration:

Consider writing the new function as a cloud-native application if you want to exploit the following:

• Cloud computing frameworks and their loosely coupled model of cloud services
• Modern software development techniques like microservices and containers
• Provide a way to deploy updates without redeploying the entire application
• Provide flexibility to deploy on any cloud – public or private, including IBM Z and LinuxONE

When writing the new function as a cloud-native application, the new function should not have any hidden data dependency, hence the parameters passed through an API must be sufficient for the execution of the new function. Additionally, there should be no requirement for a global transaction scope across existing, and new functions.

Calling the cloud-native application from a z/OS application using an API starts with the use of an API description format to document and understand the interface to the cloud-native application. Such a format might be based on the OpenAPI specification. From the OpenAPI document, you can use the z/OS Connect EE API Toolkit to build the artifacts to enable a z/OS application that is written in COBOL or PL/I to call the API. The following artifacts are generated:

• An API runtime file (API requester archive) that contains the transformation logic to convert the request payload from binary format to JSON format and convert the response payload from JSON format to binary format
• An API information file that contains information such as the path and method of operation that is supported by the API
• The request and response data structures that are used for each operation in the API

To call the API, the z/OS application must be updated to include the required data structures, prepare the data for the API request, call the communication stub program, and handle the response.

The cloud-native application to be invoked might exist already or might need to be developed, driven by this specific need. Parallel development can take place where the cloud-native application (API provider) can implement the API and the z/OS application (API consumer) can develop against the prototype until the implementation is ready.

The new cloud-native function can be deployed in any container managed environment, i.e., on public or private cloud. As shown in the diagram, there are several options for private cloud deployment on IBM Z (i.e., Linux on Z or zCX) or LinuxONE.

Example A: Extending with cloud native applications – A bank was looking to build new capabilities into an existing function that calculates the prepayment charge if a customer decides to break their current closed mortgage. As part of the modernization initiative the bank opted to write the new capabilities as a cloud-native application in Java and running on Red Hat OpenShift Container Platform. The existing IMS application was updated to call the new calculation service using z/OS Connect EE based APIs.

B. Develop an open-enterprise language-based function and collocate on the same environment as the existing application for tighter integration:

Consider writing the new function using open-enterprise languages such as Go, Python, Node.js or Java if you want to exploit the following:

• Simplification of development and deployment by leveraging package ecosystems support for open-enterprise languages and deployment tools.
• Interoperation with traditional z/OS high-level languages and reuse of existing functions written in COBOL, PL/I and Assembler.
• Ability to exploit the pool of readily available developers that are familiar with development using modern languages, and the associated development environment.
• Tight integration with the existing system of record, enabling the new components to seamlessly extend the qualities of services of the existing runtime without complex design choices. This can provide global transaction recovery across traditional resource managers and modern XA based resources, robust security controls and auditing, exploitation of existing management tools like backup/restore, and monitoring processes.

Although the open-enterprise languages can be used to build pretty much anything, you need to consider the strengths of each programming language.

• Java: If you are looking to extend a CICS or IMS program or interact with major subsystems or z/OS resources, then the preferred approach is to write the new function in Java. CICS and IMS provide Java class libraries (e.g., JCICS for CICS and IMS Universal Drivers for IMS) that make it easy to call native CICS and IMS resources using Java interfaces. Major subsystems like Db2, IMS DB and MQ provide open standards-based libraries based on JDBC and JMS specifications, and the z/OS operating system also provides the JZOS Java class library to simplify access to operating system resources and data. Furthermore, CICS and IMS provide a runtime environment for Java applications which makes it possible to run the new function and the existing application within the same recoverable unit of work (UOW), i.e., Global transaction scope. Lastly, Java provides support for interlanguage communication which makes it easy for Java to talk to existing COBOL and PL/I programs.

• Node.js: Node.js is designed to build scalable network applications. Therefore, it is best suited for I/O intensive applications. It has over 1.5M good-to-go packages to help accelerate software delivery. It provides a highly scalable, module-driven approach to software development that encourages agile practices. You can use Node.js to securely aggregate data on z/OS and implement APIs for report generation or enable dashboard applications. It is also a good choice for API orchestration where business logic is required. Node.js can run as a standalone z/OS application or as a CICS application.
• Python: Python is ideal for data science applications. You can use it to perform advance data analysis using popular packages on z/OS where data is stored. You can also streamline automation for applications deployment and IT infrastructure with Python and Ansible. You can also use Python to develop new APIs to interoperate with critical applications running on z/OS and take advantage of collocation.
• Go: Go is a general-purpose programming language for building large-scale complex applications. It has a powerful standard library of packages and built-in functions to support application development. Go is a compiled language which generates high performance code in z/OS. It is ideal for developing new applications or APIs to extend existing business critical applications on z/OS. You can also use Go to enable popular applications on z/OS. Go applications can interoperate with applications written in other languages (e.g.,COBOL, PL/I, C/C++, and Java) via CGO and IBM middleware via APIs developed with z/OS connect.

Example B: Extending with Java application on CICS – A national social security fund which provides consolidated benefits for all its citizens. In the initial phase, a new interactive application for citizens was implemented in Liberty with Spring MVC. The main driver for that approach was a shortage of COBOL developers. The ability to use readily available Java development skills, frameworks and tooling made it an easy choice. In the past, new Java based functions were developed and deployed on a distributed platform. Integration of the overall solution included both MQ based integration of web applications with CICS applications, as well as web services-based integration of CICS based business logic invoked by Web UIs, hosted externally on a distributed platform. In contrast, use of JCICS for COBOL/Java integration made it very easy in developing new Java based functions. It provided easy access to both persistent SOR data and common shared data across new and existing functions. Batch integration using Java applications was deployed into a Spring batch framework. All data in Db2 were accessed using JDBC in CICS with global transaction support. Finally, IBM RTC, Jenkins, Junit, Maven build and IBM UCD were used for development.

C. Integrate a packaged solution with APIs:

Consider extending an existing application on IBM Z by integrating with an external third-party cloud-based SaaS (Software as a Service) solution if an organization has already decided to purchase the new service from a third-party, rather than developing in-house, and the latest rendition of such services are delivered only as external cloud-based solutions. Pros and Cons of developing customized functions for competitive differentiation vs. using SaaS based commodity solutions is beyond the scope of current discussion.

Typically, modern SaaS based solutions provide standards-based REST APIs (i.e., OpenAPI) for invocation of these services. As in the Cloud-native scenario, the overall solution consists of existing z/OS based applications invoking SaaS based services using REST APIs.

Example C: Extending with third-party services – A financial organization wanted to leverage an Express Shipping and Delivery service in delivering a “new account package”, including a new Credit/ATM Card. In the past this has been a deferred batch/semi-manual process. Sometime after the account opening transaction is completed the post processing is performed and the “new account package” shipping occurred. With a modernized solution the organization uses the services of a third-party. These services are invoked directly via REST API calls from the account opening transaction, thus reducing the delay.

D. Extend with existing or new COBOL based application deployed on Cloud:

Consider writing the new function using CICS COBOL language under the following considerations:

• The organization has already deployed CICS COBOL based functions on distributed systems and/or on Cloud. Hence, it is easy to develop new CICS COBOL based functions while also benefitting from Cloud based deployment.
• There is a need for tighter integration with back-end functions running on IBM Z for some applications. The new CICS COBOL functions/applications while deployed in cloud, need to be able to connect to core applications running on IBM Z platform under a single global transaction. A tightly coupled business logic deployed in cloud is able to share transactionality, data sources, and the same business context as the applications operating within IBM Z.

Here are the primary drivers for this kind of scenario:

• There is a need to preprocess data or add new validation logic. This helps optimize the deployment architecture by performing non-critical processing on cloud and then calling the core CICS application on z/OS to perform actual/core business logic. It is usually the case that the new function will only deal with read-only data.
• Create a pipeline of innovation with new functions on cloud and then move it to IBM Z after testing the markets.

Example D: Extending with CICS TX on Cloud based COBOL applications – An existing insurance application on z/OS extends its functionality by adding new validation logic & pre-processing logic to prepare data coming from a cloud service. This preparation of data and validation happens on cloud, and it is then passed to the core application on IBM Z, which can be directly processed by COBOL applications on IBM Z.

A new reward points determination program, for example in an insurance application, might be added to utilize health tracking data from cloud services. It can fetch health tracking data from 3rd party cloud services, do validation on that data, marshal it into a record-based format using a COBOL copybook and then pass it onto an existing COBOL application running in CICS TS on IBM Z. Such new extensions take advantage of shared data and transaction context with z/OS deployed applications.

The above example is implemented using CICS TX in IBM Cloud for the new functions and CICS Transaction Server in z/OS for an existing application in a hybrid setup. CICS TX and CICS TS share a common set of CICS APIs. They can be connected using the IPIC communication protocol, which can share business logic and data constructs in seamless way. Deploying CICS TX in IBM Cloud brings an additional advantage of running regulated workloads securely and in an optimal way. If the front-end application uses native SDK style of programming, CICS Transaction Gateway can also be used along with CICS TX for creating hybrid applications.

New applications may be designed utilizing this common architecture that can either deploy on the cloud using CICS TX or run in IBM Z using CICS TS.

A key business benefit of using this pattern is that enterprises don’t need to abandon their investment in core applications on IBM Z. Instead, they can breathe new life into those applications by extending their capabilities with modern application development approaches like using open-enterprise languages, cloud-native applications, and cloud-based solutions. The use of modern application developments can enable organizations to build highly scalable applications in a modern environment with private, public, and hybrid clouds while staying relevant in a quickly changing industry and meeting their clients’ increasing expectations.

The ability to extend core applications on z/OS with a modern application development approach provides many advantages:

• Enables speed to develop and deploy new capabilities, responding to market demands by using modern development tools, processes, and leveraging existing libraries and frameworks
• Addresses skills shortages of older technology by using open standards-based languages
• Takes advantage of security frameworks that are available with modern applications to meet compliance standards
• Avoids the high risks of completely rebuilding business-critical applications
• Provides a way to deploy updates without redeploying the entire application

There are multiple considerations in implementing this pattern.

• First, select a solution approach that best matches the drivers and constraints (as detailed in scenario A, B, C and D): i) Cloud-native application, ii) Develop new open-enterprise language-based function with tighter integration, iii) Third-party cloud based services or iv) New COBOL based function deployed on cloud, respectively.
• For Open Enterprise language-based function, select the language based on the workload needs, (as detailed in scenario B).

• For the new cloud-native application, the use of containers with cloud-native applications offers flexibility of deployment for a hybrid cloud solution:

  • Deploy containers inside z/OS and closer to the z/OS application using the z/OS Container Extensions Technology or zCX Foundation for Red Hat OpenShift.
  • Deploy containers on Red Hat® OpenShift® Container Platform on premises on IBM Z or a distributed platform.
  • Deploy containers on Red Hat OpenShift Container Platform on public cloud.
  • Deploy containers on any Kubernetes platform.

  The key decision criteria include reducing latency with the collocation of cloud-native applications closer to z/OS based applications and data as well as meeting stringent SLAs on security, availability, and scalability. (See the Collocate applications pattern for additional details.)

Use IBM® Application Discovery and Delivery Intelligence to discover and understand the impact and interdependencies of extending the core application. For more information, see the Application discovery for business alignment pattern.

• Review these patterns:
  • Collocate applications
  • Application discovery for business alignment
• Review the Calling an API from a System of Record (SoR) section of the z/OS Connect EE Quick Start Scenarios to learn how to call an API from a core application on z/OS.
• Check the GitHub sample for calling an API from a CICS and IMS application.
• Learn about CICS and IMS with Java use cases
  • Get started with Java in CICS
  • CICS and Java
  • Java application development for IMS
• Learn about the IBM Z and Cloud Modernization Stack and how this single package provides all the necessary capabilities for developing and deploying cloud native applications as well as integrate with APIs with existing z/OS based applications.
• Learn about the IBM Open Enterprise language portfolio
  • IBM Open Enterprise SDK for Python
  • IBM Open Enterprise SDK for Node.js
  • IBM Open Enterprise SDK for Go
  • IBM Semeru (Java) Runtime Certified Edition for z/OS