The idea of integrating the mainframe more widely is not new; it has gone through numerous iterations including messaging middleware, ESBs, and SOA before arriving at APIs. The lessons learned can drastically shortcut the effort to API-enable the mainframe while increasing the likelihood of a successful project.
Four main factors to consider when API-enabling the mainframe
There are four main categories of technology-related factors that users should consider when embarking on API-enabling the mainframe:
- Applications and resources
- Environment
- Unique mainframe attributes
- Mainframe skills
Most mainframe systems of record embody applications, environments, and resources that are alien to those not steeped in mainframe tradition. The IBM transaction processing products, CICS and IMS, provide a complete environment in which to run high volumes of transactions, reliably and effectively. CICS is ubiquitous, and used by almost all mainframe establishments, while IMS is more specialized but heavily used in the finance industry in particular. Non-IBM products such as CA-IDMS, CA-Datacom, CA-IDEAL, Natural, and Adabas are also quite common. In programming terms, COBOL is by far the most popular language, although PL/1 has its fans. The DB2 database system and the WebSphere MQ messaging middleware may be a little less inscrutable to outsiders due to their existence on non-mainframe platforms, but other system facilities such as RACF and SAF are largely unknown outside of the mainframe. So any toolset designed to API-enable the mainframe must be able to address the needs of these specialized resources and environments.
Mainframe Environments
To some extent when API-enabling the mainframe, technology can shield the non-mainframe world from these mainframe-specific products and environments, but the greater challenge comes in meeting expectations in terms of unique mainframe attributes. Companies that rely on mainframes for much of their business have come to expect a range of benefits from their mainframe implementations. These benefits accrue in areas like reliability, robustness, scalability, performance, security, integrity, and manageability. The problem is that when services are delivered within the API model, client-side components in particular will be running in a wide range of environments and technologies, each with its own associated characteristics. The risk is that for mainframe users used to a high level of service quality based on innate mainframe capabilities, this quality of service could be jeopardized by influence from non-mainframe technologies like phones, tablets and chips sitting inside household appliances or cars. For example, while a mainframe user will typically run their workstations or other devices in at least a semi-secure environment, a phone user may well leave the phone unattended for a while, quite possibly in a public place. Any tools or technology involved in API-enabling the mainframe must take these sorts of factors into account.
Regarding skills, as discussed above, it is likely to be difficult and expensive to find IT developers who are comfortable programming in both mainframe and mobile environments. Therefore, any toolset for enabling the mainframe should make it easy for mainframe and non-mainframe programmers to quickly create API components and services without the need for expensive and time-consuming re-education.
All of these mainframe environment-specific factors must be taken into account in evaluating best-of-breed tools for mainframe API enablement.
– Steve Craggs, Lustratus Research
Want to find out more about API integration? Download the complete ebook from Lustratus Research.