Modernizing mainframe applications is an important element of many digital transformation strategies. Letting legacy apps participate in the hybrid cloud is a high priority for the IT organization. It can also save money. An Accenture study shares that modernizing legacy applications can:
- Create 15 to 35% infrastructure year-over-year savings
- Lower application maintenance and run costs by 30-50%
I recently presented a webinar on using APIs for CICS modernization. During the session, I polled attendees about the status of their modernization plans:
What we learned is that almost everyone is in the middle: just one attendee reported completing their modernization journey, and no one said they had no plans to modernize. For almost everyone, modernization is a work-in-progress (just over one-third of our poll respondents) or they are in the planning or pre-planning stage (63%).
I spent the bulk of my time sharing the modernization via API strategy. This is a strategy that Gartner referred to as “encapsulation” in a December 2020, article, “7 Options to Modernize Legacy Systems.” Of the options ranked and referenced in this post, encapsulation earned the top spot for easiest to implement and lowest risk.
For many, the belief is that modernization essentially boils down to one of two mutually exclusive approaches: replatforming or modernization-in-place. I see the options differently. Modernization is not an “either-or” choice between these options. To think that it is requires buying in to a false dichotomy for reasons I’ll unwrap as we go deeper into this discussion. What is clear is that those who modernize-in-place have a different experience. Whether you consider cost, duration of project, complexity, or risk, modernizing-in-place via APIs is less expensive, completes faster, reduces complexity, and lowers risk.
Not All APIs are the Same
The foundation to exploiting APIs for modernization is understanding the different types of API design. I place API design into two categories:
- Technology-based APIs: these are platform-dependent APIs that expose the details of the current implementation of some business logic or data. This API type requires more effort and skill to exploit because of the tight-coupling these APIs create. The origins of technology-based APIs are almost always “bottoms up.” For example, suppose you need to expose a valuable COBOL program that runs under CICS using an API. Inevitably, the API that gets built has many technical dependencies on the program you are exposing.
- Business-level APIs: rather than developing APIs to call specific programs, it’s better to design APIs around business-level activities. Rather than build an API to call a program, a business-based API allows the invocation of a particular business process. These APIs are platform agnostic and expose workflows. They make it unnecessary for the programs that wish to use the APIs to worry about the technical details of the API, or the artifacts underneath them. They create a loose-coupling that requires less effort to use, and they are less brittle than technology-based APIs.
Here’s how I summarize the difference between these types of APIs, with business-level APIs the preferred approach:
Business-Level APIs are a Pivot Point
Business-level APIs are critical because they create an enterprise “pivot point.” What do I mean by that? We design business oriented APIs for our customers to satisfy objectives for both the mainframe and the cloud computing environments.
Looking to the mainframe side of the modernization challenge, we want to optimize the things running there the API gives access to. When the API itself is technology-based, the tight coupling it has to the underlying mainframe application becomes a barrier. The irony here is the very mechanism that provides access to mainframe business logic – the API – itself becomes a barrier to scaling hybrid applications and evolving them. A term I use to describe this is “application rigor mortis.” This occurs when screen scraping is the pervasive integration technology. It leads to an unwillingness to evolve the applications out of fear the change will break the integration. Decoupling the implementation from the use of an API lets us decouple development activities, timelines, and in general reduce the risk.
On the cloud side of the modernization challenge, rather than having to focus on technology-based APIs, the focus is on enabling the business process. Using business-level APIs creates a loose coupling that makes it easier to extend and scale functionality. As a result, it’s easier to evolve mainframe assets and extend them to the hybrid cloud. The business-level API serves as a pivot point when the organizational objective is migrating business logic off of the mainframe. A business-level API simplifies this migration in this way:
- Create a business-level API to the existing mainframe application.
- Use the API to access the business logic on the mainframe.
- Develop the business logic on the new platform.
- Redirect the API to the logic on the new platform whenever it’s ready.
The API becomes the pivot point for migrating business logic. Business-level APIs are both strategic and tactical at the same time, depending on an organization’s migration strategy. Regardless of where business logic will ultimately run, the best, first step is creating an API that makes it available. Such an API preserves the flexibility to evolve the backend while also serving as a strategic pivot point for possible future migration.
Modernization Via API Philosophy
We can summarize our philosophy of using APIs for CICS modernization in this way:
- Leverage existing business logic that runs on the mainframe.
- Deploy business-level APIs to make this logic available.
- Extend the reach and business value of these underlying System Z components to cloud, web, or mobile platforms.
- Evolve your hybrid application portfolio quickly and easily.
So what does such a modernization journey look like? From the HostBridge perspective, it begins with Integration Analytics, the best entry point to a modernization effort. Integration Analytics provide transaction insights about usage patterns and volume that facilitate API design and ultimately, API fulfillment.
Integration Analytics create an informed view of how your mainframe connects to – or perhaps collides with – the outside world. What Integration Analytics have proven time and time again is scaling hybrid architectures can have unintended consequences on the mainframe. We created an Integration Analytics process and framework to “connect the dots” between the mainframe and everything that interacts with it: hybrid apps, and increasingly, automations.
The HostBridge Transaction Analytics Connector (HTAC) is our software for enabling Integration Analytics. HTAC captures all the request-response data flow that comes into CICS and enriches it with metadata about those requests. This additional metadata is added to CICS monitor data and ultimately as SMF 110 records. We then transport this data into Splunk to analyze it.
Use Case: Global IT Solutions Provider
A use case will illustrate the value of analyzing CICS interaction data. A global IT solutions firm whose global field sales force are heavy users of Excel spreadsheets. These spreadsheets contain various macros that “chatter” with the mainframe using terminal emulation software and screen scraping techniques. For example, it’s not unusual for a sales rep to use a spreadsheet that invokes a macro to get order status information from the mainframe. Retrieving host data in this way often takes 10 minutes or more. Why? As it happens in this case, thousands of CICS transactions are orchestrated and run by an Excel macro to populate the spreadsheet. This type of integration and activity is occurring at some level in every organization for which we’ve done analysis.
What’s far more efficient is doing the orchestration on the mainframe, where it occurs at memory-to-memory speed with no network latency:
It may seem counterintuitive, but doing orchestration on the mainframe saves CPU cycles. It does so by eliminating the overhead of having to start multiple transactions the middle-tier orchestration layer requests. When the middle-tier can call a business-level API, only a single request is sent to the mainframe, consuming less cycles and lowering costs.
Creating and Fulfilling Modernization APIs
To reinforce how efficient HB.js is in productive use, one HostBridge customer, shared production data from a week in July 2020. During this week, over 2 million CICS transactions were run through HB.js APIs, the average response time was 82 milliseconds, and there were zero abends of HB.js. I recall asking this customer why they felt it was so remarkable that there were zero abends. They said the integration technology that HB.js replaced suffered regular abends.
Advantages of Business-Level APIs for Modernization
The advantages of using business-level APIs and using HB.js for CICS modernization are one and the same:
The best, first move for organizations trying to make CICS application logic and data available through modern, hybrid applications is to modernize around business-oriented APIs. This answer is true, whether the mainframe is a strategic IT asset or heading to the IT scrap heap. Either way, business-level APIs built with HB.js will get you where you need to be, faster, and at a lower cost.