Intellyx BrainBlog for BMC
Just like the Fast and Furious movie franchise, it seems like mainframe modernization is a predictably repeated story that never runs out of sequels in most enterprises, even if the plot is pretty much the same every time.
Organizations delay changing and evolving their application estates because developers fear they will break systems they don’t understand, and IT operators fear what will happen if live mainframe production environments are disrupted in any way.
Regardless, enterprises must realign their most critical core systems to keep up with the pace of change required to become more agile and responsive to customer needs, or they will risk losing customers. Instead of fearing change on the mainframe, we should fear not changing fast enough.
Breaking the calcification of COBOL
As an early programming language, COBOL isn’t particularly complex in and of itself. There’s a rather limited instruction set, and when most COBOL code was written, there was no need to even think about object orientation—much less extended libraries and frameworks or a distributed cloud architecture.
The calcification that prevents refactoring doesn’t come from COBOL, it comes from the fear of change: the risk of layering on each additional procedure and workaround, in order to add just one more feature to the monolith.
As new code is appended one function at a time over the years to adapt to change, mainframe-based applications start to accrete technical debt and become more unstable and harder to change without failures.
Worse still, at this point, nobody knows the intent of the original builders, as they have likely already moved on or retired from those roles long ago, without leaving behind adequate documentation.
Rather than having to check out, review, and rebuild the whole program every time a change is needed, what if we could instead refactor mainframe programs into separate logical components? Then, even an individual developer could check just one component of the whole program out, and develop and test a new feature in isolation, away from the entire monolith…
Read the whole article on BMC.com here: https://www.bmc.com/blogs/mainframe-application-changes-without-repeating-risks
