Tell an IT leader or a developer that the world runs on COBOL applications, and they will nod their heads knowingly. That’s because the core systems of some of the largest brands and most critical industries still rely heavily on their legacy systems.

With 92% of IT leaders reporting in a Vanson Bourne survey that their COBOL applications are strategic to their business, it’s paramount that these applications remain functional and supported. That’s a tall order, however, with high demands from the business on innovation and updates and a dwindling developer pool to leverage.

Transformation of these applications will be a key means of keeping them reliable and viable as a path to meeting the goals of the business. But the modernization of COBOL applications doesn’t happen overnight, and it doesn’t happen in a vacuum. These applications are not only important but there is still a significant amount of code that’s relevant – estimates put the 220 billion lines of COBOL as making up 80% of the world’s actively used code. Time, money, and teams are all required resources to enable transformation.

You can plan a perfect modernization project for your COBOL application, but without the proper support, the project won’t be successful and might not even get off the ground. That’s why creating a proper business case for modernizing your COBOL applications is so important.

Business and technical leaders need to understand why the modernization project you’re proposing is so important, what’s involved, and what’s at stake. A well written and well-developed business case will:

• Get everyone, from business leaders to technology stakeholders on the same page about the need
• Set expectations on the effort and expectations for the project
• Make clear what the modernization will and won’t do, and keep it focused on what’s most important
• Help your project manager carry the project to completion and fight scope creep because you’ll have defined what done looks like.

Of course, the easiest part is understanding that you need a business case. The greater challenge is in creating an effective one. CloudFrame has defined the seven key elements that your COBOL modernization business case must include to get across the importance of the project and secure the resources that you need.

7 Elements of a Truly Persuasive Business Case for Modernization Legacy COBOL Applications

Element Number One: Problem and Opportunity

Table setting is an essential part of your business case. By establishing the problem that you’re trying to solve, upfront, and the opportunity that the transformation offers, it’s easier to make the case for the need.

For instance, if you’re planning on refactoring a COBOL application to work within a JVM on the mainframe and, in the process, create opportunities for leveraging APIs that will extend secure access to the data stored on the mainframe in a native way, your problem statement may discuss how the lack of data access is slowing down business decision making and that running the application on the mainframe is an expense.

It may also be worth noting that your highly valuable COBOL developers are spending significant time on maintenance tasks and reducing technical debt instead of providing value to the business with new features and functionality. The opportunity then becomes the chance to better meet the business needs for data and speed leveraging modern design and development practices while reducing operational costs.

Note that both the problem and opportunity are stated in terms of the larger business, not just the technical issues with the application. A clear description of the problem is the one that will gain the most support. As Dan Roam explains, “Whoever best describes a problem is most likely to solve it.” A clear definition shows that you understand the need for modernization not just as a technical solution but as a business one as well.

Element Number Two: Vision

Once you’ve established the need and opportunity, you’ll want to create a picture that illustrates clearly what the future state of the application looks like, including the importance of your vision.

Transforming an application inherently includes modernizing it, but it’s important to make that clear as part of the business case. The transformation is an ideal time to adopt modern DevOps practices, leveraging current best practices and technology, embracing the value of integration and the cloud.

It’s also critical that your business case depicts accurately the gap between the system’s current state and the future state that you’re proposing. This includes a discussion of how long it will take to reach the desired end state and any timing factors that influence the timeline, like budget restrictions, license agreements, or end-of-life notifications.

Element Number Three: Strategy

While the project itself may be tactical, the business buy-in will be grounded in strategy. This section should call out the strategic objectives – financial, growth, risk mitigation, and so on – that are driving the need to modernize the solution now.

Whenever possible, your COBOL modernization business case should align with both the overarching business strategy and IT goals. For instance, if the business has a goal of reducing operating costs and IT plans to do that by moving some workloads to the cloud, it would be to your advantage to discuss how the project can meet those objectives. Whatever the objectives, this is a good time to present the idea of an incremental modernization approach and how that will make progress toward your end goal while letting you realize benefits along the way.

This is also the time to ensure that you have overall agreement on what success looks like for this project. The strategic objectives – such as reducing costs by limiting the reliance on the mainframe for processing that can be done elsewhere – give you a basis to define the strategic measurements that the project success will be judged by.

Element Number Four: Alternatives

There is more than one way to approach the challenges associated with a legacy COBOL system. This section is your opportunity to present alternative approaches to addressing the needs.

Include the evaluation criteria used in determining that the proposed approach is the one that offers the greatest opportunity for success as it is defined. Fully discussing the alternatives can bring forth additional, unknown facets of the project. This is also the time to propose what the decision-making process looks like – who will make what decisions, and what are the criteria used to define the importance or severity of issues or questions?

Remember that “do nothing” is an alternative to the solution you’re proposing. Be clear and realistic as to the impacts of choosing not to take action, and what that choice could mean for application reliability, costs, and business continuity.

Element Number Five: Background

Continuous improvement and learnings from the past play an essential role in a business case presentation for modernizing your legacy systems. Your modernization business case should outline what has been done before and learnings from those instances, emphasizing those that aren’t successful.

This is the time to acknowledge and account for the technical debt created from those previous endeavors and what previous failures may have cost the business both in opportunity cost and real dollars.

Pulling forward both the successes and the failures of previous attempts gives you the chance to discuss how you’ll leverage that knowledge to protect this transformation from missing expectations.

An application might be the decision to use automated COBOL refactoring based on the expectation of the reliability and maintainability of the transformed source code. This might be a “lesson learned” where a previous project failed because of a manual rewrite based on an abundance of tribal knowledge surrounding features or data access functionality.

Another learning area may be the impact of change on business processes, business cycles, maintaining SLAs, and resource demands. Key questions might be oriented toward handling mission-critical processes like the end of the day, week, month, quarter, or year. Have changes in these processes or systems been disruptive or costly due to inadequate planning or anticipated impact? 

Element Number Six: Metrics & Parameters

Measurement and parameters are how you’ll show progress as the project progresses as well as drive home the need to transform the mainframe application into a modern asset.

The metrics that you should consider for your business case include:

• Lines of code involved or affected
• Systems that will coexist, interface, or integrate
• SLAs that must be considered
• Data sources for the applications and impacts on their access and use
• Support hours
• Technical debt to be taken into account

For obvious reasons, the technical team should be included in determining the parameters and data that will make up how you measure the need, current performance of the legacy application, and what restrictions might exist.

Element Number Seven: Financials

The last section is where the rubber meets the road. When presenting the financial impacts, it’s better to be factual and conservative, leaving open the possibility of overdelivering instead of running over.

There are two distinct views of financial impact. 

The first is understanding your current cost structure how it is measured, cross charged, and budgeted? Once you have a firm understanding, apply post-transformation changes to the cost structure and analyze what will change.

Key questions might include the impact on that costing structure, what will increase, what will decrease, and the long-term trajectory of these changes.

The second financial impact area is the cost. Begin your business case with a high-level overview of transformation project costs, along with the supporting details. For instance, you may start by explaining the overall cost of the project but have a breakdown of development costs to refactor or transform the application, product license cost (both new and retiring), the costs associated with system overlap while applications are migrated, the costs of MIPs and cloud hosting.

When plotted on a chart, it’s likely your financial analysis will form a bell curve. Costs will rise and then fall and stabilize. You should be prepared to describe and defend this type of financial projection.

Conclusion

Modernizing your applications and legacy systems is really code for updating them for cost savings, maintainability, reliability, and innovation. But COBOL can be its own enemy when it comes to pitching a legacy modernization project – the code in question has been in use, running some of the business’s most important processes, for decades. That’s why a clear and persuasive business case that answers questions before they are asked and speaks to what is important to the organization is key.

If you’re ready to build out your COBOL
modernization business case, CloudFrame can help. Leveraging our expertise in
COBOL and mainframe transformation challenges and solutions we can help you
define your solution, call out the tangible and intangible elements that can
impact the project, and develop the case that supports you in creating and
presenting a clear and comprehensive business case for system and solution
modernization. Contact us today to understand how we can help you make the
right case for your project.