Editor’s Note: We recently had the opportunity to brief an analyst at a well known IT analyst firm. The topic was how HostBridge enables CICS integration, orchestration, and modernization. This post summarizes what HostBridge CEO Russ Teubner gave in response to one of the analyst’s questions.
During our briefing last month, we were asked about the scalability of the HostBridge JavaScript Engine web services approach to CICS integration and orchestration. The question was: “What about the enterprise with thousands and thousands of screens? How would this approach work for them?” It was a great question. This post shares our response.
We work with some very large enterprises, such as the largest credit union in the world. These customers have thousands of CICS screens. Could HostBridge extract the metadata from all the screens automatically? Of course, but that’s not how customers get value from the web services approach to modernization that HostBridge enables. They are not typically trying to “webify” all their screens. Instead, they want to orchestrate a repetitive, high-value business process; that is, automate the flow of a sequence of screens to perform an important business function.
Integrating CICS applications is much more about the flow of a business logic sequence than it is about “webifying” CICS screens.
Thus, our customers don’t typically use HostBridge to provide access to all screens. Instead, they come to us with requirements like “we need to allow customers to add a new automobile to their existing policy from their smartphone” or a similar request. On the back-end, there are always a series of CICS screens. Our tooling makes it easy to create scripts that encapsulate the business process represented by the flow of those screens (i.e., inputs, outputs, and even error conditions). Once created, the mid-tier or mobile app simply invokes the “add new auto to existing policy” web service. And, there’s no need for the mid-tier or mobile app to have any awareness of screens.
Customers are more concerned about the flow between specific screens than the sheer number of screens. It’s fair to pose this question: could we create tooling to automatically detect all possible screen-to-screen flows across a collection of COBOL programs? With this harvested knowledge, could we generate JavaScript to preclude the customer from having to walk-through the screen-to-screen flows involved with the business process they are implementing?
Theoretically, it’s possible to do COBOL source code analysis and detect most (but not all) of the possible program-to-program flows. However, detecting all possible screen-to-screen flows is a different matter. The most common CICS screen mapping tool is BMS (Basic Mapping Support). And, using BMS, you can create 1:1, 1:Many, or Many:1 relationships between programs and BMS maps. Furthermore, these inter-relationships are subtly encoded in the program source code, and often predicated on the actual user input. Thus, it would take some extremely deep source code analysis (augmented by humans) to ever get it (close to) correct. And this begs the question: Is it really worth it? The answer from our customers is: “No, it’s not.” Why invest the resources to analyze the source code for an entire application (potentially hundreds of programs and thousands of screens), when the business process they want to automate is implemented by a handful or programs and a dozen screens?
With all this as background, what we’ve learned is: CICS integration isn’t about the number of programs or screens. It’s about the business process they want to implement. Even if there are 1,000 or more screens in the application inventory, we take a business process view of integration, not a screen view. We then help the customer create a web service to execute proper workflow, whether it involves a few screens or hundreds. The resulting service is easy to integrate with middle-tier or mobile apps to invoke a business process. And, it performs extremely well.
Some recent HostBridge blog posts provide more insights into the approach we take and how well it performs for:
- Orchestrating CICS transaction sequences.
- Reducing latency.
- Speed of developing and deploying CICS web services.
Pilot HostBridge with Your CICS Applications
We’ve been helping make CICS applications available for 20 years. The CICS web services approach we promote is ideal for shops which need high-performing integrations that are not brittle. This is what we designed HostBridge to do when we launched it. The HostBridge team will provide free software and support. We’ll even come onsite to help you make the business logic in your CICS applications available via an API, or as a service. To discuss doing a pilot project with a member of the HostBridge team, simply submit the form below.