Enhance an existing function pattern

← Back to Application modernization patterns

Many organizations rely on existing core applications on IBM Z to run their business-as-usual operations. These applications, both transactional and batch, maintain systems-of-record (SOR) data on IBM Z. Most of these are monolithic applications and are architected and built as one large single entity. As a result, each application operates as a single unit, with components such as presentation, business process, shared functions, or business rules, acting as part of the same large single entity. Furthermore, the applications have evolved organically over a long period, reflecting the accumulated changes in business and its changing requirements. Adding to the challenge, organizations are often risk averse in making large changes, and hence, the changes have accumulated technical debt making future enhancements difficult.

Therefore, working with their core and with the advent of new technologies, many organizations have found it difficult to continue to deliver enhancements and stay competitive with their mainframe-based monolithic applications. As similarly outlined in the Extend pattern, challenges in updating these applications to support new business initiatives are multi-fold.

• Business risks: Updating core critical mainframe-based monolithic applications to support new requirements for existing business initiatives introduces a range of risks. These include potential disruption to core solutions, timeline for meeting marketplace needs, requiring a large investment, etc. In addition to the risks involved, there is also effort required to modify existing functions or develop new functions and test the applications.
• Skill shortage and preference for Open Enterprise languages: Backlogs of the required changes to the applications are increasing, and available skills have diminished. 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: To keep up with the market demand, it is necessary for organizations to transform their core applications on IBM Z and take advantage of cloud-native technology to support business agility with lower risk. These organizations would like to leverage both Open Enterprise languages and cloud-based deployment by incrementally modifying or deploying existing applications on Cloud. 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 implementing data sovereignty and optimizing deployment to reduce chattiness in supporting services to be delivered via new channels and to reduce overall cost.

IBM Z supports the enhancement of selected components of a monolithic application (e.g., presentation, business process, shared functions, or business rules) by incrementally rewriting only the selected function with a lower risk and a lower cost. Rewriting an existing application from scratch requires a huge effort and has a good amount of risk associated with it. Instead of rewriting the entire application, you can incrementally rewrite only a part of an existing application driven by an immediate business need (see the first diagram below). Utilize latest COBOL or PL/I compilers to take full advantage of new IBM Z features that are specifically designed to optimize the performance of your business-critical applications and operating costs. You can choose to use new language features shipped in these compilers to extend the capabilities of your existing applications. You can also selectively rewrite existing functions or develop new functions using open-enterprise languages and deploy them as a cloud-native application. Alternatively, you can redeploy some existing COBOL based functions on cloud or choose to replace the existing function with a new Third-party based service. Finally, integrate the enhanced function using APIs to and/or from the existing application components by leveraging a co-existence model. IBM Z provides multiple options to deploy a cloud-native application on z/OS or Linux (also see Extend pattern). The use of cloud-native principles, enterprise DevOps, open languages, and container technology on IBM Z or IBM LinuxOne to develop the enhanced function can help make for a seamless transition to hybrid-cloud based solution and a lower risk of failure.

While the business drivers and starting points for enhancing an existing function are different from the pattern for extending with a new function, the solution approaches for developing enhanced function follow the same scenarios:

• Rewrite as cloud-native application for API-based integration
• Rewrite using open-enterprise language-based function and collocate on the same environment as the existing application for tighter integration
• Replace with a packaged solution and integrate with APIs
• Redeploy an existing COBOL based application on Cloud with a hybrid-cloud architecture

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

A. Rewrite as cloud-native application for API based integration:

Consider rewriting 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 on IBM Z and LinuxONE

The diagram above illustrates the flow and architectural capabilities that are involved to replace a part of the core application on IBM z/OS® (i.e., CICS®, IMS™, or batch) by rewriting a selected function as a cloud-native application. Here is an overview of the approach to rewrite a selected component.

1. Identify the function and code segment to be enhanced: IBM Z provides tools to analyze existing code assets and understand the relationship across code segments. See Application discovery pattern and Refactor pattern for more details.

2. Identify the integration points for the enhanced function with the larger/remaining core application: Based on an understanding of the relationships of the code component to be enhanced with the overall application, define how the enhanced component will integrate with the larger core application. For example, an enhanced presentation code segment rewritten as a cloud-native application will invoke the core business logic using an API. For this scenario, see Expose pattern on how to expose APIs from core applications on IBM Z. Alternatively, for a shared function or business rules to be enhanced, the core business logic needs to call out to this component using an outbound API. See Extend pattern for this implementation.

3. The cloud-native application may already exist or may need to be developed driven by this specific need. Parallel development can take place where the cloud-native application can be written to consume the API to invoke existing functions (see Expose pattern for developing and invoking an API). Alternatively, the cloud-native application can implement the enhanced function as an API to be invoked (see Extend pattern for extending existing code to call an API) and the z/OS application develop against the prototype as an API consumer until the implementation is ready. Refer to Enterprise DevOps pattern on how to fully integrate z/OS application development into existing enterprise CI/CD pipelines. Finally, collocating the new enhanced component closer to existing z/OS based components is essential to avoid higher latency, and hence lower performance as well as to maintain high SLAs. The collocation of a new cloud-native component can be achieved following the Collocate pattern.

Example A: Rewrite as a cloud-native application An insurance company was looking to modernize their existing core individual insurance application by leveraging cloud-based services. In order to minimize risk to this core application as well as to lower cost of modernization, they chose an incremental approach in transforming the existing application. As part of this modernization initiative, they also want to simplify access to and from the mainframe application using industry standard REST APIs and make selected existing functions (e.g., premium calculation service) reusable by rewriting the function into a cloud-native application. Furthermore, in matching available developer skills they chose an Open Enterprise Language, i.e., Node.js. They rewrote the premium calculation service used by their individual insurance application to Node.js and then deployed it as a cloud native application and made it accessible via REST API to different consumers. One of the consumers, an existing z/OS batch application, was updated to call the premium calculation service using z/OS Connect EE.

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

Consider rewriting the existing function using open-enterprise languages and additionally, use inter-operability across languages if you want to exploit the following:

• Simplification of development and deployment by leveraging open-enterprise language interfaces and deployment tools.
• Maintaining 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 and monitoring processes.

Transactional scope of the enhanced component: Pay close attention to the transaction scope covering the component to be rewritten/enhanced. Some application logics do not make any changes to the SOR data, i.e., either prepares data such as by presentation/systems of engagement logic before calling the core transactional application or provides a supporting computation function that can be called by a transaction logic to perform a computation. Such code can be easily rewritten as independent cloud-native services without affecting data integrity. All other components can be refactored for enhancement but need to remain in the scope of the overall transaction. Transactional update to SOR data is critical to maintaining integrity of data. The component can be rewritten in open-enterprise languages like Java, but it must remain under the original transaction scope. Hence, the new code must be deployed on the same runtime environment under a Transaction Manager (e.g., CICS, IMS). For details, please see Refactor pattern.

If rewritten or enhanced code needs to be deployed outside of same transaction runtime due to business need, transactionality can be maintained by using CICS Transaction Gateway (CICS TG) as a connector for CICS applications. With CICS TG, rewritten/refactored code can be in Java, .NET, C++, or Node.JS and connected to CICS applications preserving the transactional integrity.

Example B1: Rewrite with Java application on IMS An IT service provider introduced Java in IMS alongside COBOL in IMS on IBM Z to accelerate creation of new services and extend the life and value of their existing applications. One of their banking clients, wanted to modernize their core banking application with an incremental approach. With the long-term goal of evolving the mainframe application infrastructure from COBOL-centric to Java-centric, they started out by examining their existing IMS landscape and identify the part that must be Java-enabled. Some of the requirements to write Java IMS applications are (a) the ability to handle the Unit of Work across IMS DB, Db2 for z/OS and IBM MQ; (b) have the ability to cascading calls (from COBOL to Java to COBOL to Java); (c) ability to exchange data between COBOL and Java in an efficient way (JNI-based); (d) output from COBOL and Java must appear chronologically in the same Job or application output; and (e) errors in Java must be percolated back to IMS. With Java in IMS, the IT service provider was able to establish Java as the next-generation language for the mainframe and helped their banking client modernized their banking application.

Example B2: Enhance common shared function for ease-of-use and faster performance. An enterprise software company leveraged Go to enhance the performance of a frequently used command-line function to calculate and verify 128-bit MD5 hashes. This hash is used as a digital signiture to identify and verify the integrity of a file. This function is used as a part of a file synchronization process between z/OS and a workstation, where MD5 hashes are calculated at each endpoint. This facilitates the verification process to identify files quickly, without the need to transfer data between the systems for comparison. This function enhancement has produced significant increase in performance, decrease in I/O, and load reduction of the general processor.

C. Replace with a packaged solution and integrate with APIs

Consider replacing 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. The Pros and Cons of developing customized functions for competitive differentiation vs. using SaaS based commodity solutions are beyond the scope of this discussion. In some specific usage scenarios, new enhancements to existing ISV applications (that are deployed On-Premises and/or customized by the adopting organizations) are delivered as new cloud-based services. As in approach A, the new services are invoked via APIs from existing core applications.

Example C: Enhance with Third-party cloud-based services A large financial organization has adopted a core banking application running on an on-premise IBM Z. Over time, the application has been extended and customized in meeting changing business requirements. The ISV application provider decided to deliver certain new enhancements as Cloud-based services. The organization integrated new enhanced services deployed on Cloud replacing selected existing functions and used z/OS Connect EE to call out cloud-based services from existing CICS and IMS based applications.

D. Redeploy an existing COBOL based application on Cloud with a hybrid-cloud architecture

Consider redeploying an existing COBOL function on cloud if:

• You want to leverage cloud native technologies for deployment yet want to minimize the investment in rewriting the code.
• You want to optimize the architecture by redeploying less critical workloads to cloud and have the higher performing core application on Z
• You want to cater to data sovereignty requirements in quickest possible time while retaining the core assets on Z. This requirement is explained in detail as below.

Governments around the world are mandating that data and applications should be kept in their local geographies. IT leaders need a lightweight solution to manage the on-premise applications and data in question, that sit outside of the country where an application is initially deployed. IT leaders can select the crucial workloads effected by GDPR, containerize them using Docker technology, and move them into the cloud, keeping original application as is on IBM Z.

This approach is particularly useful when rewriting these workloads into new technologies for the cloud becomes too risky and the time-to-deliver window is small. ISVs typically create multi stack solution in such cases, i.e., cloud-based stack for smaller geographies where the workload is less so that it can cater to the number of users in that geography effectively, and an IBM Z based stack where the workload is large which can cater to millions of users concurrently.

Example D1: Redeploy COBOL application in cloud for GDPR need A Payment Service company wants to launch their solution into new market/geography. Their solution consists of Card Payments application, that processes user data relating to credit card transactions. Majority of the business logic is deployed as a COBOL-CICS application. This application typically connects with a front-end web application using an integration layer. The application is primarily hosted on IBM Z and is able to process millions of records per second for multiple geographies. In summary, this is a centralized application catering to workload from multiple geographies.

One of the new geographies mandates data sovereignty. As this new geography is still a small new market for this company, so they decide to deploy this application in containers in cloud instead of creating a new datacenter in this geography.

The CARD Payments application is recompiled and with some platform specific modifications, it is redeployed in cloud.

In the above example, CICS TS on IBM Z is used to process high volume workloads in IBM Z, while CICS TX is used to process low volume workloads in cloud. CICS TX provides capability to run JCICS and C workloads as well. Hence this approach requires minimum changes to make application suitable for running in cloud. Later, the cloud deployed application can be moved to IBM Z when workload increases beyond a certain threshold. Architectural analysis will have to be done to understand suitability of cloud deployment of the application.

Example D2: Redeploy a subset of COBOL programs for optimizing hybrid architecture Consider another example where a retail chain company uses a large application to boost their retail experience. This application contains an initial landing module, that consists of multiple tasks like login processing, initial validations, showcasing initial product catalog, etc. This module is non-critical and does not generate revenue. During peak season time, retail store observes that traffic to initial landing module becomes manifold and sometimes reaches their datacenter threshold as well. This causes the customer requests to be rejected during peak time. To avoid this issue, the retail company decides to optimize its architecture by deploying initial landing module into cloud.

In the below example, it has chosen initial landing application code written in COBOL to be redeployed in cloud. It provides multiple advantages. With this module being moved to cloud, Kubernetes scaleup feature can take care of elastic scaling and optimized IPIC connectivity can ensure that customer requests are not rejected rather queued up for a response from core applications. Core applications remain on IBM Z and continue to run high performance workload in retail application. With easy sharing of business logic across CICS TX and CICS TS runtime, this pattern provides a risk-free approach to optimized architecture.

A key business benefit of using this pattern is that enterprises do not have to abandon their decades of investment in existing core applications on IBM Z, and instead breathe new life into these applications by enhancing the existing monolith piecewise and rewriting selected parts as cloud-native applications. This approach could help reduce technical debt by using a better approach that would take longer but will result in creating applications that are not only easier to build, but also easier to maintain. The use of cloud-native technologies can enable organizations to build highly scalable applications in today’s modern environment with private, public and hybrid clouds.

Specifically, the ability to enhance existing core z/OS applications piecewise with cloud-native applications can:

• Enable speed to develop and deploy new capabilities faster and eliminate backlog
• Address skills shortages of older technology by leveraging open standards-based languages
• Take advantage of security frameworks available with modern applications to meet compliance standards
• Avoid the high risks of completely rewriting business-critical applications
• Provide the ability to deploy updates without redeploying the entire application

Here are a few additional considerations in implementing this pattern.

Collocating enhanced component: The key decision criteria include reduction of latency with collocation of cloud-native applications closer to existing z/OS based applications and data as well as meeting stringent SLAs on security, availability, and scalability (see, Collocate applications pattern for additional details).

The use of containers with cloud-native applications offers flexible options to deploy a hybrid cloud solution:

• Deploy containers inside z/OS and closer to the z/OS application using the z/OS Container Extensions technology.
• 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.

Leveraging Middleware capabilities: As you rewrite existing functions with enhanced logic, consider the use of cloud-based Middleware services (e.g., business process, business rules, analytics) leveraging IBM Cloud Paks®. For example, when extracting business rules from existing core applications on z/OS, consider using a business rules engine like the IBM Operational Decision Manager which is included in the IBM Cloud Pak® for Business Automation. The business rules engine provides a central location where rules can be stored, created, and updated to meet changing business requirements and regulations.

Replacement with packaged solution: Use of a cloud-native application by using a packaged or an existing solution could be an option for certain components. A good example of this is replacing a presentation logic with the use of third-party portal-based services for enabling customer self-service functions. As mentioned earlier, the captured data from such interactions are to be reflected in the SOR system by propagating such updates and invoking core transactional applications.

• Review these patterns:
  • Application discovery for business alignment pattern
  • Expose API pattern
  • Extend with new function pattern
  • Collocate applications pattern
  • Refactor pattern
  • Enterprise DevOps pattern

• Read the customer solution example Business process modernization on the business challenges, solution approach and outcome in transforming an existing business process.

• Review the Create services section and Create APIs section of the z/OS Connect EE Quick Start Scenarios to learn how to perform the tasks to expose a z/OS asset as an API.

• 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 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