A conclusion that can be drawn from this year's American Banker/Tower Group technology survey - to paraphrase Gen. Douglas MacArthur - is that old banking systems never die, they just fade away.
That's the case with most of the nation's top financial institutions who responded to the 1995 Survey of Technology in Banking: two-thirds of them said at least one of their current core processing systems is over 20 years old. And one-fifth said their oldest production system has been around 25 to 30 years, dating them back to the dawning of the Age of Aquarius.
But it appears these venerable software packages - mostly homegrown systems that banks have patched up repeatedly over the years - have remained in fashion long after lava lamps and pet rocks went out of style.
The fact that banks still rely heavily on these so-called legacy systems for the core accounting tasks - mostly developed using the Cobol programming language and running on big mainframe computers - stands in stark contrast with the mountains of hype surrounding newer, PC-based technologies like object-oriented programming and client/server computing.
These new software technologies claim to ultimately speed up software deployment and make modifications to application programs less of a headache.
According to the 1995 technology survey, banks seem to want the best of both old and new computing technologies. The survey reported that even though financial institutions are increasing their spending on client/server systems and other newer technologies, maintenance of mainframe-based computers and applications still makes up more than three- fifths of the $17.4 billion budgeted by banks for technology this year.
And while consultants believe banks' continued reliance on old "spaghetti code" does not pose much of an immediate operational risk, there is some concern about the longer-term effects.
"The problem is these things become so costly to maintain that they suck resources away from things you'd rather be doing," said David Medeiros, a technology analyst with the Wellesley, Mass.-based Tower Group.
Bankers counter by saying the advanced age of some of their key systems is just a result of setting priorities.
"What banks are trying to do is juggle the backlog" of applications development, said Donald R. Hollis, an executive vice president at First Chicago Corp. "If there's not a lot of dynamic change in one area, they'll put more of their resources into the new stuff where the market's driving them."
Peter DiGiammarino, an executive vice president in charge of the financial industry business at Fairfax, Va.-based software developer American Management Systems Inc., agreed that some bank systems have been chugging along for decades because "if there are other places you could invest your scarce resources and time and get a big payback, you do that.
"There's been so much to do to develop systems to support new products, we're only now getting to the point where banks are going back to look at how to make the existing things better," Mr. DiGiammarino said.
Another sign in the 1995 survey of this technological conservatism was banks' continuing use of Cobol, one of the first structured programming languages, dating back to early 1960s.
According to the American Banker/Tower Group survey, the banking industry still relies on more than 57 billion lines of Cobol code to operate its bread-and-butter systems.
And while 48% of banks surveyed said the size of Cobol-based application software suites were remaining constant, 36% said their Cobol libraries were growing at up to 5% a year, and 10% pegged that figure at greater than 5%. Only 6% of banks said they were reducing their use of Cobol-based applications.
"Given the fact that banks have large amounts of Cobol applications they have to maintain, they will want to keep their Cobol programmers," Mr. Hollis said. "Most of the new Cobol generation will be in existing application suites. Increasingly, banks will use new technologies like object-oriented programming for brand-new application development."
He added older banking systems are being extended through use of so- called "middleware" that provides links to PC-based client/server systems.
"A legacy system doesn't need to be rewritten just because it's old, or because it's in Cobol, or because it's spaghetti," Mr. DiGiammarino said. "It only needs to be rewritten for a business reason."
However, Mr. Hollis warned that many of banks' legacy systems are not immortal, due to the fact many Cobol-based applications cannot accept dates past Dec. 31, 1999. "That's going to force abandonment or replacement of this old code," he warned. "Some these applications just can't be extended any longer."
Mr. Medeiros said banks could start reducing their reliance on Cobol- based applications as they shift from in-house developed systems to third- party packages that are often written in object-oriented languages or other advanced programming tools.
"Core systems don't really provide much competitive advantage," he added. "No one is going to change banks because they (want) the best deposit system on the block. These are workhorse-utility things.
But even so-called commodity products like checking accounts and installment loans are subject to competitive pressures, Mr. Hollis argued, exigencies that will force banks to eventually retire their accounting systems to that big data center in the sky.
"Even toilet paper gets differentiated," he said. "The fact that something's a commodity requires more differentiation in packaging and customer service. In our business, it's technology that does that."
