Critical Business Processes May Rest on Crumbling Foundations

If COBOL were a person, it could belong to AARP by now. In 1959 — 55 years ago — the need for a common business oriented programming language was apparent. Existing languages were designed for scientific and military uses. That’s when

Commodore Grace M. Hopper, USNR, Special Assistant to the Commander, Naval Data Automation Command

Grace Hopper and a user group asked the U.S. Department of Defense to support the development of COBOL, and the rest is history. By the 1970s, the explosive development of smaller and cheaper computers made new sales forecasting, manufacturing material supply, and production scheduling systems possible.

Although IT has gone through many generations of evolution since then, a recent Computer World survey found that 98% of businesses still had some IT systems written in COBOL, and even some new COBOL programming going on. The problem with COBOL is not so much that it is a bad language. It has been updated by many revisions, including one as recently as this year, and still has its uses.

The problem is that aged and outdated code is embedded in the systems manufacturers depend upon the most. If you looked into the guts of some critical ERP systems, you are likely to see millions of lines of ancient COBOL program code, patches, and old routines running on top of even older ones. Dead or dormant routines occasionally trigger mysterious problems. And with your most valuable data and operations sitting on top of a pile of old code, you may be less safe from hacks than you think. COBOL was never designed to provide the level of security needed in today’s connected world.

Moreover, hidden COBOL system maintenance costs are high. “Joe” and his fellow veteran programmers can’t help anymore. They have retired to the sunny south, travel the world, and live their dreams. When new COBOL programmers — if you can find them — try to figure out what Joe’s code is doing, they find poor or lost documentation and individualistic nonstandard styles of coding.

Decades ago, Grace Hopper foresaw the problem, saying, “Ignoring the future results in inadequate, outmoded systems continually in the need of costly change and updating, and never quite in tune with the work requirements. Concomitantly, no innovation or standard should be rejected as too costly without careful evaluation of the ‘cost of not doing it.’”

Not doing it, not tearing down and replacing your current core systems, comes at a cost that is hard to quantify. But, given the hidden costs and vulnerability of retaining old code, the investment in replacing old databases and applications may be the most important investment you consider for next year.

Karen Wilhelm has worked in the manufacturing industry for 25 years, and blogs at Lean Reflections, which has been named as one of the top ten lean blogs on the web.

Grace Hopper image courtesy of http://www.history.navy.mil/.