Big iron isn’t going away.
Regardless of the thousands (or maybe tens of thousands) of information technology experts and professionals who plot to reduce mainframe relevancy, it grows year to year. A study from Allied Marketing Research reports that global mainframe marketing is expected to grow to $2.90 billion by 2025. This report can be easily validated if your organization is an IBM shop (and who isn’t as they have 90% of the market) and you received their notice of upcoming price adjustments.
While there is undoubtedly a camp of mainframe detractors, there is an equal or greater community of mainframe architects and COBOL and PL/I application owners that are recognizing opportunities IBM has delivered to the market. The release of new IBM Z platforms and programs like Tailored Fit Pricing (TFP) open opportunities that were unrecognized before.
Acknowledging there are new opportunities does not address the existing problems for mission-critical COBOL application owners and support teams. The risks of transforming or modernizing their applications are historically consistent: business disruption, cost-to-value reconciliation, rising support and maintenance cost, and losing control due to vendor lock-in or outsourced “big bang” projects.
Organizations focused on cost reduction and looking for value gains should evaluate opportunities to shift COBOL application compute to less expensive environments. As detailed in this article on the CloudFrame blog: CloudFrame Relocate Economics and Java on Z, there is a clear path and justification to gain the benefits of Java on Z for your COBOL workloads.
As you realize these opportunities, enthusiasm must be balanced with risk mitigation. Here are three primary risks and their mitigation strategies to inform your COBOL application cost reduction project(s).
Selecting the wrong application(s)
To succeed in reducing the mainframe COBOL cost of compute, you must select the right application(s). Often, but not always, the most appropriate applications will have these characteristics:
- Batch orientation,
- High MIPS consumption, particularly at peak,
- Predictable volume and outcome.
Selecting the correct first application(s) will allow you to better maintain control, anticipate issues, and measure effectiveness—all elements of success.
Overextending the scope of your initial cost reduction project
The typical COBOL cost reduction project might be defined by its failures. Cost overruns, extended project duration, and inability to meet success criteria are common attributes of mainframe COBOL cost reduction projects.
To mitigate the risk of overextending the scope of your efforts, you need to tightly scope your project phases and determine and build consensus around the appropriate measures of success. You do this with an incremental approach to relocating the COBOL application compute. Developing an incremental approach involves identifying isolated applications, jobs, or even job steps and prioritizing those above those more complicated. Additionally, you will want to prioritize applications that don’t have to be relocated together.
Take multiple incremental steps to transition the entire application onto less expensive compute while leaving shared data intact on the mainframe.
Losing Control of your COBOL Compute Cost Reduction Project
You must maintain control of your COBOL application cost reduction project and the measure of success.
Each project and project owner will define their level of control but generally speaking; you want to decide the scope and sequence of transition, success criteria, and project artifacts/deliverables. And most importantly, you want to deliver and sustain hard financial benefits quarterly from the onset.
Leveraging backward compatibility here is critical. Use the existing data sources. Don’t try to replicate data and manage data coherency across multiple platforms from the onset. And definitely don’t even think about data conversions to UTF-8 ASCII at this stage. The same is true with Job scheduling. It’s generally a high-risk null reward change. Instead, develop solutions that retain the mainframe batch JOB orchestration as-is. Finally, be mindful of existing dependencies on 3rd party utilities and 4th GLs such as SORT, DYL280, E-Ztrieve, and others that may not have an off-mainframe alternative.
Instead of outsourced or externally managed COBOL cost control initiatives, your organization should have a hand on and in the approach. Maintaining control with your teams, internal and external, will increase your chances of a successful COBOL compute cost reduction project.
Want More Information?
CloudFrame’s recorded webinar concentrates on COBOL Compute savings. Watch the event here.
IBM Mainframe Image: Erik Pitti, CC BY 2.0, via Wikimedia Commons