emember the movie, 'Who is Killing the Great Chefs of Europe?' This B-film was released in the late 70's and its plot parallels the current trend in IT today. No, I'm not suggesting a sequel ('Who is Killing the Great COBOL Programmers of America?'). What I'm driving at is that while COBOL programmers aren't exactly a dying breed, they are at least a rapidly retiring one. Who's going to take care of the legacy systems they leave behind? And should we care?

Consider these facts from industry watchers: 70 percent of the world's data is processed by COBOL and nine out of 10 ATM transactions are done using COBOL. Thirty billion online COBOL transactions are processed daily; 492 of the Fortune 500 use COBOL, including the entire Fortune 100, and current COBOL investment tops $3 trillion. You get the ideathese legacy systems still have an important role to play in business today.

The COBOL dilemma neatly highlights the love/hate attitude that enterprises can have toward legacy systems.

At first, the Y2K challenge fueled a "rip and replace" mentality regarding the millions of lines of badly documented code left behind by long-departed programmers. Because it was deemed too risky to attempt to replace the intellectual property that had accumulated in these systems, the vast majority of systems were not ripped out, but updated.

Of course, after the boom came the bust in the form of one of the worst slumps the IT industry has seen in decades. In one fell swoop, IT departments' purse strings were tightenedthe slogan suddenly became "economize." Organizations can no longer afford extravagant, wholesale re-structuring of their IT infrastructure. To add insult to injury, the newly installed programs have begun to show their limitations. Clearly, it's time for a new way of thinkingone that doesn't advocate throwing the baby out with the bath water.

Smart Enterprises Adapt
So what does the smart enterprise do when viable programs outlive the programmer, or when the rip and replace methodology is no longer an option? The smart enterprise improves on what it already has.

Training plays an essential role in this process. What's required here is increased investment in training to bridge the technology divide. Hardware and software have both changed almost beyond recognition in the last thirty years along with the skills a developer needs to deliver relevant applications. Gartner says this difference between old and new skills is as fundamental as the difference between Romeo and Juliet's Montagues and Capulets—between the COBOL 'dinosaurs' and the Java 'coding cowboys'.

However, the goal for organizations should not be a replacement of legacy systems and therefore legacy skills, but rather, a greater understanding of what it takes to extend an application's capabilities.

At the most basic level, this means training new staff on the disciplines of old systems, and vice-versa. Don't forget to train 'old' staff on the new fangled technologies such as XML, J2EE, and .NET. Take a long hard look at existing processes and examine how they can be improved, with a more structured approach to legacy environments. Also, use external providers, where necessary, for short-term need, but not at the expense of the long-term skills management (and therefore the viability) of the enterprise.

Web services has shown that it is possible to make legacy applications talk not only to each other, but to the outside world in general, using Internet standards. Therefore, a partial solution to the challenge of declining programmer numbers is simply to cash in on your legacy.

Investing in small, quick, additional Web services software will increase the value you get from existing systems, without the need for a complete rewrite. Think of this type of program as an IT form of Esperanto—the universal language—which can be used to translate the information buried within the legacy system into a format that the end user can not only understand but actually utilize. The result is less cost, greater profit, a more mediated risk, and faster time to market.

What's the moral of the story? The progammers who first implemented COBOL are retiring, but the work they've done is tightly woven into the fabric of every major business in the country. That makes the programs they've built and maintained far from obsolete. If they aren't broken, why replace them? Instead, go one betterupgrade. Use the people, processes, and technology around you to improve on your legacy systems.