The greenfield modernization approach is a tempting option for IT teams, but it’s also one filled with significant risks—as we’ve discussed in previous articles of this series. However, a less risky and more effective approach is available, so let’s unpack it and see how it addresses or avoids many of the problems greenfield faces.
A Better Way
The better way is easy to summarize: modernization teams should use automated code transformation for the bulk of the effort (typically on the order of 80%) and reserve manual re-writing only for those modules where it’s necessary and justified by the business value they provide.
Admittedly, a tool-assisted transformation has been challenging to implement in past years. Newer methods avoid the dangers of simplistic “one-to-one” transformations by mapping functionality and hard-coded dependencies into cloud-native, microservice-based, and DevOps-ready frameworks built to scale horizontally (rather than purely vertically, as mainframe programs assume). Such methods can be enhanced with tools like AI-assisted code analysis and assessment and automated test case generation, which can be powerful force multipliers for pools of often scarce developer talent.
The benefits of this approach are usually immediately apparent: consistent and predictable code, delivered at high speed, conforming to robust test cases, and comprehensively mapping back to the functionality and data dependencies of the original COBOL. Since risk reduction is such an essential part of the business case for tool-assisted transformation, let’s recap the significant risks from the greenfield approach and see how it mitigates them:
Requirements Uncertainty
The direct translation of code brings both explicit and implicit requirements into the new system. An automated transformation tool can copy comments in the original COBOL code and place them next to the Java code that the relevant operation has been translated into—a “chain of custody” showing how the old system was transformed into the new one, greatly enhancing auditing control.
Estimation Errors
This approach minimizes project risk by reducing time and maximizing the predictability of task duration through fast, automatic code transformation, re-focusing the time estimation problem on the much less numerous and more complex functions that require expert-led manual re-writing.
Consistency Challenges
Automated conversion means perfect consistency in coding assumptions and patterns, right down to the level of the specific open-source libraries used. This means that the transformed code will be more understandable, that the range of coding knowledge required by project teams and operations teams will be more tightly focused, and that both maintenance and future changes will be easier, cheaper, and less risky.
Opportunity Costs
Because it is automated, tool-assisted transformation implies fewer (scarce) coding resources committed to a modernization project and less project duration overall. In the near term, this allows an enterprise to capture business value faster (in cases where the automated transformation work covered complete functions which moved into production more quickly). In the medium to long term, it means an enterprise will be able to respond to market shifts or new opportunities much more rapidly because its best people aren’t tied up in a modernization journey that seems never to end.
The goal, ideally, is modernization transformed: COBOL turned into cloud-native Java rapidly and inexpensively, with greater operational maintainability and improved agility for the entire business.
In our final post, we’ll look at a real-world automated code transformation tool that your teams can start piloting and experimenting with today. And in case your curiosity has been piqued, we’ve prepared a webinar that you can watch in the meantime, covering many of the transformative innovations that make the above outcomes possible for the first time.
