Mainframe COBOL application modernization projects are often characterized by a single measure: cost.  When infamous projects are reported, they don’t cite the complexity, mission-critical value, or what percentage of an organizations’ financial processing depends on the application.  Often, it’s only the cost. Seven figures pique interest, and an eight figures cost causes further investigation.

Failure at that level brings external analysis and observations.  “This” should have been done.  “That” would have made a difference. That degree of scrutiny results in second-guessing and the FUD factor — Fear. Uncertainly. Doubt.  Enter the management consultants …

This heightens the obstacle of cost in mainframe COBOL application projects.

Cost will always be a factor anytime COBOL modernization projects are considered. That doesn’t mean that cost analysis will always be the death knell for making mainframe modernization progress. 

To overcome cost, you must segregate the issue into two categories: least controllable and more controllable.

The category of least-controllable cost includes existing hardware and software license agreements and the costs associated with COBOL support. You can’t renegotiate license agreements overnight or discover inexpensive COBOL support personnel readily available to ensure your application is sustainable into the future.

The more controllable category represents the areas of COBOL modernization projects that provide the opportunity to make a huge impact.  Those opportunities exist in several areas:

• Clearly identifying success
• Defining and protecting project scope and duration
• Using automation for transformation and application testing
• Moving execution or compute to lower-cost platforms

3 Best practices to overcome the Cost Obstacle

Best Practice 1: Define Success

Your COBOL transformation project success must be clearly defined.  If “done” isn’t specified, then you’ll never reach the goal. Without an explicit agreement of success, the risk of never-ending effort is real, which brings increased cost. Simply put, this is the definition of done (DoD) in Agile.

Mainframe mission-critical COBOL applications usually have many integrations, downstream dependencies, enhancement backlogs, and technical debt.  Your definition of success should include a thorough analysis of those areas, and your plans should include efforts to prevent any confusion about project success.

Defining success allows you to identify investments and tie off any increases in scope, our next best practice.

Best Practice 2: Control Scope and Duration

It’s widely known that large IT projects are risky.  Mainframe modernization projects may be riskier than the “normal” project.  Scope creep and project delays are frequently cited as contributed factors for project failure, and those items obviously increase project costs.

To control scope and project duration, consider smaller, incremental mainframe modernization projects.  Your overall modernization portfolio strategy should be built on the concept of concise scope and duration projects that allow you to prove concepts, deliver success, and gain momentum incrementally and perpetually.

The Fail Fast Theory is applicable here.  While no one wants to project manage the next epic IT project failure — it’s best to learn lessons on smaller-scale projects than traditional mainframe big bang transformation projects. This has always been great advice from Ken Rubin, “If you don’t know what you’re doing, then don’t do it on a large scale”.

Concise scope and minimal project duration will reduce the cost of your COBOL modernization.

Best Practice 3: Leverage Automation

Automation plays an important role in overcoming the cost obstacles of mainframe modernization.  There are obvious cost-saving scenarios when using automation compared to manual modernization efforts; this is the empirical basis of DevOps value. That assumes the automation produces a quality output (product) that doesn’t require remedial effort to achieve its purpose.

Modernization projects can address cost obstacles with automation in several areas: harvesting business rules, data lineage, data migration, code refactoring, and testing.

Code conversion or transformation from COBOL to quality Java is no longer an aspiration. Configurable and customizable transformation engines that produce high-quality code, as measured by credible third parties, are a reality. These COBOL code transformation processes can significantly reduce time, effort, and cost. What differentiates these products in the marketplace is their assumptions about the data. For example, will the generated code be backward compatible with mainframe EBCDIC, packed-decimal, etc., while being suitable for cloud deployment, or will it require a data migration to UTF-8 ASCII? If the latter, there is a considerable increase of scope, duration, cost, and risk, particularly for integrations with systems beyond the scope of the modernization. Yes, you definitely will migrate your data to UTF-8 ASCII, however, that doesn’t need to be the first step. Why not lock in the cost savings from moving to a lower-cost Java platform first, then gradually reinvest some of those recurring savings into a well-conceived data strategy?

Testing is another area where automation plays a role in overcoming cost obstacles.  Automated test case generation and execution can drastically reduce the development cost and project duration of transformation projects.

Summary

Removal of budgeting and cost forecasting isn’t an option. Every mainframe COBOL modernization project will have some cost and budgets obstacle to overcome.  Your business case and project plan should include a clear definition of success, details of how project management will hold the line on scope and duration, and opportunities to utilize automation in code transformation and testing to ensure quality and mitigate risk.