BrainBlog for CloudFrame by Jason Bloomberg
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.
