A Better Approach – Self-directed, Self-Funded COBOL Modernization

In our previous writings, we’ve discussed the scale of COBOL investment over the last several decades and the challenges of continuing to depend on this legendary programming language. The drivers for modernization remain, and COBOL can’t help but be caught up in the plans of many mainframe organizations. 

ANY modernization approach has risks associated with it. The volume of that risk is directly related to the number of components, programs, and applications that need to be changed or touched in the process. Not only does the volume of changes – simply to maintain functional equivalence – directly impact the risk of the systems being altered, but it may also impact the “connections” within and between these systems!

With so many moving parts, it’s easy to understand why organizations have been reluctant to touch these legacy systems in any meaningful way. External service providers or packaged software vendors are quick to offer large-scale solutions that completely replace all the components of your existing applications, albeit with more modern technologies. 

Whether these solutions are proposed as a total application rewrite or as an implementation of a complete packaged software solution, these approaches often struggle to create functional equivalence OR clearly identify the differences and their impact on business users.

Defining Acceptable Risk

Only you can define the level of risks you are willing to take to modernize your existing systems. 

Some organizations take a “packaged software” approach to their future IT architecture. In cases where the existing IT systems provide no discernible, stand-alone value but instead simply support business functions, this might make sense. 

However, one trades the challenges of custom-developed software for increased dependence on the packaged software vendor. Most organizations that modify these solutions face a “you broke it; you own it” philosophy from these vendors. The vendor assumes no responsibility for retrofitting these changes to a newer release, forcing companies to remain on older versions of a solution to avoid undergoing application modifications again.

A complete application rewrite may appear attractive for different reasons. The major external service providers offer the allure of implementing a solution that matches the modern needs of the business, built with modern technologies. Unfortunately, these providers often minimize the necessary understanding of the EXISTING system and therefore create functional dissonance within the company. Your business users, and perhaps even your clients, have become accustomed to certain business rules and processes, and the new application may not match these. The result is new or expanded friction in the organization.

The best approach is to avoid the downsides of both methods and reduce risk with a self-directed, self-funded, incremental approach to application modernization. While it might be a more extended trip to the final desired end-state, the organization has the power to define the level of risk they will accept. This also puts the organization in control of costs, minimizing upfront budget requirements to fund the project. 

The Benefits of an Incremental Approach to COBOL Modernization

The “increments” of the modernization project can be prioritized according to business needs rather than the priorities of the technological tactics. The risks of disrupting the “connections” within and between systems are also reduced. 

“Slow and steady wins the race” is the philosophy behind this approach. The continuous evolution of the application can be done without introducing significant risks to the business. It’s true that, for a time, you’ll have a mixed bag of technologies during the process. However, you ALREADY have a mixture of technologies in place. With a well-designed plan, the destination will yield a more homogenous technology base, and this intermediate mix can be reasonably managed.

For an incremental approach to modernization to be successful, organizations must develop a plan that defines a continuum of steps along the path to the desired architectural end-state. Each step should provide value but reduce the amount of risk. A well-defined destination architecture makes each step a move toward an organization’s goals for its application stack. 

New technologies require new skills. As the technology underpinning the application portfolio changes, so can the skillset within IT. Some of your existing staff will make the change, while others – particularly those associated with COBOL or the mainframe – are likely within shouting distance of retirement. Your plan should evolve your application technology and IT skills base at a managed pace that recognizes the realities of your business’s hiring capabilities while respecting those contributions of your retiring workforce.

A carefully planned application modernization strategy reduces organizational risk and disruption while allowing for a technological shift at the architectural and resource levels. 

Software packages and third-party custom-built applications lack the progressive and stable nature of a self-directed and self-funded incremental approach. 

For most companies, that incremental approach means the difference between chaos and a smooth move to a new era.

– Guest content from Dale Vecchio, Mainframe Modernization Thought Leader