At many large IT organizations in the public and private sectors, senior development and system staff members will be retiring in large numbers over the next three to five years. Unless we plan now, IT operations will be at risk.
Shrinking IT budgets over the past several years have left many departments running lean on staff and relying on more experienced employees for day-to-day operations. A tremendous number in this employee group will be eligible for retirement—in many cases, early retirement—over the next few years. Senior staff will take a breadth of business knowledge, legacy technology expertise and operational understanding with them.
In an eWEEK.com column that appeared May 19, 2003, Technology Editor Peter Coffee wrote: "If were going to need people in, say, 2008 who have current knowledge of the Internet and the Web, practiced skills in writing COBOL code that can use those network resources, and five to 10 years of experience in leading a development team, now is not too soon to start developing those assets." I believe well need people with those skills before five years are out.
I asked a class of COBOL students I was teaching last year at college if they would consider working with COBOL in their career. All of them said "definitely not." There just arent enough students gaining legacy experience. The COBOL that I taught was Fujitsu for Windows, so there was no chance for any mainframe exposure.
Some organizations are trying to move their systems—and developers—to the next generation while they can. I have been delivering a QuickStart program funded by Microsoft that transitions mainframe developers to .Net. The program is enabling developers to augment mainframe applications with .Net, and some very old mainframe applications are being moved to .Net. However, I worry when students are pulled out of a class to deal with a mainframe issue. Most of my students are within 10 years of retirement. What happens when they cant be pulled out of retirement to fix that problem?
Key to a successful transition will be planning. Begin by apprenticing new employees on legacy systems that are not slated for replacement. Have these applications documented according to business flow. Plan to replace systems with multitiered applications where possible.
Consider transitioning legacy system developers to new technologies to help with rewriting old applications. Examine all your training programs and consider those that help employees transition in both directions—to and from the legacy systems.
The steady disappearance of legacy system expertise is a problem that is silently creeping up on many organizations. Taking action now will help you avert a crisis later.
Peter Goth is a software architect at Infusion Development Corp., in New York. Free Spectrum is a forum for the IT community and welcomes contributions. Send submissions to email@example.com.