If the CEO asks what to do with the COBOL
Over time, issues linked to COBOL have been postponed and today innovation is being crippled by this ongoing debt. Here's how to defuse it.
The COBOL Challenge
COBOL ascended to become a dominant programming language and a standard in the Mainframe Era throughout the 1960s and 1970s.
In 1977 a Jimmy Carter's officer declared "If It's Not Broken, Don't Touch It". The idea was to save billions if the government adopt this simple motto. It was explained: 'That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken.”
The motto sounded good to institutions CEOs. Those years they regarded IT as an expense, never as an investment.
Since then, the IT world went through constant evolution but any CIO looking for budgets to modernise the systems would hear that it is not broken.
The COVID-19 pandemic brought to light the difficulties associated with the computer systems within U.S. government agencies. The sudden increased demand for services, especially unemployment benefits, overwhelmed systems that used COBOL.
Facing COVID 19 and the difficulty to bring COBOL to the cloud government and the private enterprises understood the need to modernise their systems.
There is no quick solution. Modernising COBOL is a slow process that starts by recognising the immense inversion made building those systems and it contains a huge number of intelligent solutions that must be preserved. It is also necessary to understand that COBOL prevailed sixty years because it is the best software language for business. COBOL is not the responsible for the data storing Americans of 150 years of age and the so-called spaghetti is consequence of patches, repatches of the code through the years. No other software language survived.
Modernisation Solutions
Many are the alternatives for COBOL modernisation.
Recommended by LinkedIn
· Rebuilding is not only expensive and risky - it is almost impossible. Defining the business rules, regulations and promises embedded within legacy COBOL code presents a significant challenge.
· Translation to JAVA will not erase the data problems or untangle the spaghetti. It will only create another layer of difficulties for maintaining the COBOL.
· Microservices create redundancy problems.
SO, if any CEO ask you what can be done tell them:
· Build your future team: Start paying your COBOL programmers better salaries. Instruct HR people to stop discriminating older people and start COBOL courses on the premises.
· One by one, slowly but steady refactor your COBOL program: Break the monolithic programs of ten thousand lines into small modules and document them.
#LegacyModernization, #COBOLTransformation, #TechnicalDebt , #ITLeadership,
#MainframeEvolution
Aspiring Junior COBOL Developer | Mainframe & Legacy Systems Enthusiast | JCL, ZOS, VSAM | Cyber Security | Background in Project & Marketing Management | Multilingual 🌍
3wSpot on: the problem isn’t COBOL itself, but decades of accumulated technical debt. Rewriting from scratch is often unrealistic or too risky. The real solution lies in steady modular refactoring, preserving business logic and training a new generation of developers. COBOL survived 60 years for a reason — it’s still unmatched in precision and business rule clarity.
médico e ambientalista, na Universidade Federal de Minas Gerais
1moBoa noite Mely, aqui tá bom demais....
Solutions/Application Architect, IT Project Manager, IBM-i (AS400, iSeries) Specialist
1moVery good analysis. COBOL is never the issue. Its the numerous changes applied to the aging programs over the years. Loads of commented out codes that obscure the logic. And then there's the lack of documentation in the old codes because in the past, memory was limited. Which makes IT teams scared of modifying these ancient programs. And yet somehow, most decide to junk and redo everything. JAVA even. And then the CIO complains when it all goes over budget???
Master Mariner | Mainframe Guru | Six Sigma Black Belt | Co-Founder & CEO at ZedInfotech Canada
1moThe owners of the cobol codes should do an introspect and examine if their codes are still in cobol 74 or before or in cobol85 format. From my years of experience in this line I can bet that more than 75 % of the codes are still not in 85 cobol. Changing over from 74 to 85 version will do an immense change to the performance of cobol programs. It is better than switching over from cobol to Java on the name of modernisation. Cobol is still the only business oriented language and is customized to run batch programs on the mainframe which none other modern languages can.
Master Mariner | Mainframe Guru | Six Sigma Black Belt | Co-Founder & CEO at ZedInfotech Canada
1moVery informative