My favourite quote this week -- one that conveys a fact of life in a few simple words -- is Gary Anthes' story "Love that 'Legacy'" where Northrop Grumman Ship Systems' CIO Jan Rideout cautions against expectations of big maintenance cost savings by moving applications off a mainframe.
"That's overhyped by the suppliers who want to encourage you to replace your mainframe systems," Rideout says.
She's right, of course. So few vendors are making money from mainframes that there's a concerted effort afoot to convince you to abandon them. The easiest way to do that is to create a buzz that positions mainframes as dinosaurs and the person who supports them as a troglodyte who would dent a blade server if he bumped his head on it.
It has got to the point where some vendors who make money selling mainframe hardware and software are embarrassed to admit it. How are they supposed to position themselves as suppliers for tomorrow's technology without intentionally coughing over the word mainframe?
Fortunately, that's not IT's problem. IT's problem is supporting the business, and mainframes are going to play a central role in doing that indefinitely. True, there are legitimate reasons to migrate certain applications off of mainframes when business needs change.
That's what happened at Northrop Grumman. From a technical standpoint, there was no reason to replace the old code. "The mainframe environment is very secure, configuration management is excellent, and we have excellent tools," Rideout says. Process improvements such as introducing wireless devices that needed to be integrated with back-end systems prompted Northrup Grumman's Ship Systems unit to replace some old Cobol and Fortran code with an SAP package.
But the vast majority of business data still resides on Cobol-based systems (70 per cent is a widely accepted figure), and it's silly, if not irresponsible, for anyone to marginalise that fact. As much as the vendors with a vested interest in mainframe-bashing would love to see that old code vanish, it's just not happening.
The reason is simple. The stuff works, and it works really well.
Rideout is unwilling to let the knowledge gained through the creation and operation of those so-called legacy systems go to waste. Instead, she fosters an environment in which older workers share their knowledge with their younger counterparts.
"Once people get over the it's-my-father's-Cobol thing," Rideout says, "the young kids can be a little open-minded and get into these older systems and see that there are some interesting aspects to them."
After reading Anthes' article, one veteran systems engineer wrote that significance of that with the clarity that only someone in the trenches really can.
"Just imagine a hardware system with today's cost-effective gigahertz cycle time and gigabytes of cost-effective memory running a system as bulletproof and secure as z/OS, as flexible as z/VM, with networking control like Unix, the development power of Java and a user interface like Windows! That's what we could have had by now if the young folks would have taken the time to learn from the past."