Modernization of legacy systems can be an essential enabler of any digital transformation effort – or a frustrating roadblock impeding all meaningful progress with digital efforts.
For enterprises with hundreds or even thousands of mainframe-based COBOL applications, the modernization challenge can seem insurmountable. Such applications have accumulated over the years, the result of generations of COBOL developers with different backgrounds and skillsets responding to an ever-changing set of requirements.
While retiring the lot and starting over may sound like an appealing strategy, there are far better approaches that lower the risks of modernization while supporting modern business needs.
The Best Way to Eat an Elephant
Elephant on the menu by any chance? Your best bet is to consume it one bite at a time.
Taking an incremental approach is a well-established best practice when faced with a difficult, multifaceted task. The modernization of many COBOL apps is a perfect situation for incremental progress.
Prioritizing modernization targets is an essential part of this approach as well. Focus on ‘low-hanging fruit’ – apps that are higher value while having a lower risk of modernization. Such prioritization will suggest a likely ordering of individual projects within the overall modernization process.
Following a consistent, repeatable modernization process is also essential to an effective incremental approach, especially when a large number of applications are involved.
Repeatability provides marginal benefits when people complete repeated activities manually, but the big repeatability win appears when automation is brought to bear.
Repeatable, automated modernization of large numbers of COBOL apps gives reality to the notion of a ‘modernization factory.’
Automating the Modernization
Approaching the challenge of automating the modernization of hundreds of COBOL apps as though you could pour them into one end of a meat grinder, turn the handle, and pop out a series of well-architected, modern replacements sounds unrealistic – because it is.
There is, in fact, more to this story. Each app doesn’t stand alone. It likely accesses one or more databases, either via queries or stored procedures. It may run as part of a job that itself has its own code. The app may have other constraints that reflect dependencies on other parts of the mainframe environment.
It’s also important to take the target architecture into consideration, as it’s likely to be quite different from the original COBOL architecture. Depending on the purpose of each application, the target might be an n-tier architecture leveraging object-oriented principles in support of a scalable web application.
Alternatively, the target is also likely to be a microservices architecture that will run in a scalable cloud-native environment. Understanding the specifics of the target architecture should steer the modernization process.
Any factory-like approach to application modernization must take all these factors into account, automating those tasks that can be automated while supporting the developers that must still handle remaining tasks manually.
The CloudFrame Approach to a Modernization Factory
CloudFrame converts COBOL code to functionally equivalent Java that will run on any standard JVM.
There are two sides to this notion of functional equivalence. On the one hand, the output Java code will pass the same tests as the original COBOL code.
Equally as important: the Java code will work with the same databases, stored procedures, JCL routines, and other aspects of the mainframe environment.
In many cases, an organization will eventually want to migrate its mainframe data stores to modern on-premises or cloud-based data management systems.
CloudFrame affords such organizations the flexibility to separate the modernization of the applications themselves from data migration challenges, leaving such efforts to take place at the appropriate time once the team has completed the modernization of the applications.
On the output side, the modernization team can refactor the resulting Java code to meet the requirements of the target architecture whenever business needs call for such refactoring. In many cases, however, the output Java objects will continue to meet business requirements with few or any updates.
Neither considerations of data migration nor refactoring to meet modern architectural requirements need slow down the modernization factory. Any enterprise can proceed with its prioritized list of COBOL modernizations at speed, putting the resulting Java applications into production whenever is appropriate.
The Intellyx Take
The CloudFrame approach to building a COBOL modernization factory provides the predictability, consistency, and repeatability that are essential to managing the risks and costs of such complex modernization initiatives.
There is one risk factor, however, that no one can automate away: the unknown technical debt buried inside the original COBOL applications.
In other words, there’s no telling what sort of mess lies inside such apps until someone actually tries to modernize them. Taking a spaghetti code mess of COBOL and turning it into a spaghetti code mess of Java doesn’t help anyone, after all.
Neither CloudFrame nor any other vendor can automate the modernization of such an application unless somebody is willing to clean up the mess.
What CloudFrame can do, however, is limit the ‘blast radius’ – the direct and indirect impact of the technical debt and its cleanup.
Because CloudFrame’s modernization factories take an incremental, prioritized approach, any problematic application will only require cleanup limited to its particular functionality – while the rest of the modernization effort can proceed at its own pace.
At its best, modernization can still be unpredictable and risky – but building a modernization factory with CloudFrame can lower the risks substantially, leading to a straightforward and successful modernization initiative.
Copyright © Intellyx LLC. CloudFrame is an Intellyx customer. Intellyx retains final editorial control of this article.