As we work with our enterprise customers and prospects on CICS integration opportunities, we’re increasingly hearing about IBM® z/OS® Connect EE. The question we’re getting is simple: aren’t HostBridge and IBM® z/OS® Connect EE competing solutions? If so, why would an enterprise IT organization choose one over the other?

On the surface, it does appear as if these solutions compete. The IBM website says this: “IBM® z/OS® Connect Enterprise Edition provides a framework that enables z/OS based programs and data to participate fully in the new API economy for mobile and cloud applications.” At HostBridge, we use similar language to describe the HostBridge value proposition, so it’s easy to understand why z/OS shops are confused about the differences.

HostBridge has a long-standing partnership with the IBM, and we have for decades engaged various IBM product management teams to share our sometimes not-so-humble opinion of the best ways for CICS to participate in hybrid IT. From these discussions and our analysis, we’ve discovered two, significant differences between HostBridge and IBM® z/OS® Connect EE:

  1. In the context of CICS support, IBM® z/OS® Connect EE can only invoke a single LINKable program in CICS.
  2. The primary value add of IBM® z/OS® Connect EE still seems to be the transformation of external data representations (e.g. JSON) to internal representations (e.g. a COBOL copybook).

The following matrix summarizes the key differences, and the importance of these differences is discussed in greater detail in the rest of this post.

Comparing z/OS® Connect to HostBridge.

Invoking  a LINKable Program in CICS

The limitation of only being able to invoke a single, LINKable program in CICS matters because it forces orchestration to occur outside of CICS. To understand why this is so important, let’s first look at what orchestration is, and the impact of where it runs.

In the two decades that HostBridge has helped enterprises make CICS applications available via an API or as a service, we’ve learned this: much of the time, the need isn’t simply to provide an interface to a CICS application, but to orchestrate the interaction a human operator was originally intended to do. For example, the case study about Bank of Ayudhya perfectly describes this orchestration use case.

One of the bank’s CICS application access sequences required a human operator to navigate more than 20 host application screens, at an average of a minute per screen. The bank’s IT team created a web service with the HostBridge JavaScript Engine (HB.js) to orchestrate the navigation sequence and data flows. The orchestration script runs inside CICS, but is invoked with a single click from a human operator from a middle-tier application. Now the sequence, including human operator time, completes in a minute, reducing the elapsed time by 95%.

Intellyx president and analyst Jason Bloomberg, in his recent post, “Integration Idées Fortes on the Mainframe: Stronger than Ever” shares why where the orchestration layer runs matters: performance. Most enterprises aren’t willing to see response times for core business applications go from milliseconds to seconds because the integration and orchestration layer runs off the host. When orchestration occurs outside of CICS, the latency goes up. For this reason, HostBridge has long advocated doing integration and orchestration inside of CICS. A recent benchmark reveals the performance differences that result from where this layer resides.

The Transformation of External Data Representations

A not-so-secret rule of building robust, high-performing integrations to host applications is to not do any more transformations than are necessary. In our discussions with members of the IBM® z/OS® Connect EE team, they shared that one of the primary value-adds of z/OS® Connect EE is the transformation of external data representations (i.e., JSON) to internal representations (e.g., COBOL copybook). Okay. However, HB.js processes native JSON (as does Node.js).  Transforming JSON-to-Copybook in order to invoke a script would add cost and inefficiency to the integration and orchestration process. HostBridge users would have to convert the copybook back to JSON to work with it.

We have customers that use z/OS® Connect and HostBridge, but not together. However, they would like to. All that is required is for z/OS® Connect to support a “transparent” mode in the solution that does JSON-to-JSON mapping.  If IBM perceives that the true value of this solution is transforming data from JSON-to-Copybook instead of facilitating robust integration and orchestration work, we’ll probably not see this feature. However, we feel that a JSON-to-JSON mapping feature in z/OS® Connect would add value to enterprises that need to do on-host orchestration to minimize latency.

Different Horses for Different Courses

Given the current status of z/OS® Connect EE and HostBridge, here are the recommendations we’re giving to anyone who wants to use either product to help accomplish integration and/or orchestration for CICS applications:

As it stands today, z/OS® Connect EE is unable to front-end HB.js because it insists on mapping data flows. We would love for IBM to recognize the value of a “transparent” JSON-to-JSON feature so that enterprises can use these two powerful solutions together. Regardless of what happens in this space, HostBridge and z/OS® Connect EE are NOT competing solutions. They truly are different horses for different courses.