Shifting COBOL compute to less expensive platforms is a great first step on many organizations’ application modernization journey. There are multiple reasons an organization might want to begin with shifting COBOL compute, including low risk, the straightforward nature of the approach, and the potential for extraordinary ROI.
NOTE: Cross-compiling COBOL programs into Java byte code is CloudFrame’s recommended shifting COBOL compute approach and is accomplished using the CloudFrame Relocate product. You can learn more about this product here.
But once an organization begins its journey, frustration and project failure may occur. If this happens, it is usually because of one or more of these shifting COBOL compute mistakes.
Undefined Business Case
The first mistake many organizations make is not having a business case, or if they have a business case, it needs to be better defined or include relevant elements. While you want your business case to be as simple as possible, it must still be comprehensive.
To accurately report the economic impact of the shift to less expensive platforms, the business case will need to include certain baseline costs like fees for MSUs or MIPS, developer resources, and testing. Your business case will also have to identify the current mainframe usage and the anticipated reduction.
Additionally, the business case should identify risk, strategic goals, and where this approach fits into the modernization “big picture.”
Initiating a shift COBOL compute project without some sense of the business impact and what goals you’re trying to achieve will not help you successfully implement this modernization approach.
Shifting the Wrong Program
Shifting COBOL compute might seem like a modernization pattern for all your COBOL systems. After all, every organization wants to reduce current and avoid future costs. But only some COBOL systems are good candidates, and a common mistake is to shift the compute of the wrong program.
The ideal candidates for shifting COBOL compute are programs and applications that are computation-heavy, batch-oriented, and have sequential data access processes aligned to Db2, QSAM, or VSAM. This profile best fits the shift modernization pattern and may also represent your highest mainframe MSU and MIPS consumers. Examples include financial organization end-of-day, start-of-day, and trading processes.
The least favorable candidates for shifting compute would be programs that do not contain heavy computation processes and are “chatty.” That would mean making many reads or updates to files and databases to initiate and drive processes.
Selecting the right program to begin this journey is one of the critical success factors. Choose incorrectly, and no matter how good your intentions are, the square peg isn’t going to fit into the round hole. Make the right choice, and things will go easier.
Validation Failures
All modernization projects must have a rigorous and comprehensive validation plan. It’s a critical measure of the success of your project.
A great validation and testing plan will include a process to measure performance and resource consumption as an individual execution and compared to the baseline COBOL system. Additionally, you’ll want to analyze inputs, outputs, integrations – upstream and downstream, and other dependencies. If this is a mission-critical application, it probably has established service level agreements (SLAs) like execution time and duration. Those SLA requirements must be compared to the baseline to ensure they are met.
A great plan is essential – but without data, the plan can’t be proven. Your plan will also include the methods and processes to capture the necessary measurement data.
Two primary objectives of your overall validation plan will need to be the demonstration of functional and data equivalency. Proving that you can shift COBOL compute to less expensive platforms and achieve the same functional processes and data precision will be necessary for project success.
Ignoring The Incremental Modernization Approach
Another common mistake is to attempt too much change at once. Experience tells us that large-scope, long-duration, and expensive modernization projects often fail. Big-bang modernization can be a dangerous endeavor. Instead, organizations should use an incremental modernization approach.
Incremental modernization allows you to select one or a small number of best-case shift scenarios and work with those to gain confidence and momentum. Once you have demonstrated that the business, technical, and SLA requirements can be met, you can begin to scale your modernization projects. You’ll become better at selecting the best candidate COBOL programs delivering the results anticipated in your business case.
A Final Note
The best solution to common shifting COBOL compute mistakes is never to make them. That begins with understanding the mistakes and actions you can take to ensure those risks are mitigated.
Additional information you may find beneficial:
Download this helpful business case tool: Business Case Calculator.
Watch the recording of this recent webinar: Shifting COBOL compute to Azure.
Learn more about our product: CloudFrame Relocate Product Sheet.