Which Architecture Would You Buy, Legacy or Modern?

The big debate of this decade, and perhaps the past two decades, is about legacy systems vs. modern systems. We all know what a legacy system is mostly by its age (30 to 50 years old) but also by its characteristics-flat files, COBOL, serial processing, day-delay postings, disparate customer balances, silos where each application stores its data independent of the enterprise, proprietary operating systems which is what IBM's fortunes were made of, and CIO supremacy-"I'm in charge here." These are not very attractive traits today for the architecture of any system. It didn't happen because of stupidity. It happened because in 1960, that's all we had.Following is what I believe constitutes a bank system operating in a modern architecture environment:

• A database orientation, preferably Oracle. I'm not selling Oracle, just going with the popular flow.

• Internet enabled. If a system doesn't relate to Internet protocols, it's like a global traveler trying to get anywhere without a passport as well as several other IDs that www.dhs.gov now issues.

• Universal operating system. If it has a hardware vendor's name on it, it ain't universal.

• Hardware indifference. The original ITI core system ran only on Burroughs/Unisys computers. It took two decades for the company to realize that was a very difficult imposition on bankers who had a strong love-hate relationship with Burroughs/Unisys over the years. So Premier now runs on IBM. An improvement, but still not universal.

• Modern programming languages. If a system doesn't have the benefit of current languages, it's like using a bucket of ice and a fan to cool a room. Get with the real convenience of doing the job that is constantly changing-software maintenance. Software revisions should be made, tested and released in a matter of days. If it takes months, it must be legacy.

• An infrastructure that separates housekeeping with user-specific needs. Here's what every sensible banker says to the CIO: "You do the grunt work for the enterprise; let me do my own work." We call that client/server.

• A welcome mat to all ancillary applications. There will always be a best-of-breed application somewhere that has to find a parent. Any good core system should say "yes" to any ancillary application.

• Real-time processing. That's the way this world works now. If a customer invokes a transaction from any device, he/she/it expects to see the result instantly, not at 7:00 AM the next morning. Real-time has evolved over three generations of computing. 1) Originally, banking transactions occurred between the hours of 9 to 3. If you needed a banker after 3:00 PM, you went to a golf course. 2) Then in the 1970s, online terminals allowed a teller to memo post a withdrawal if the withdrawer looked a little shady. Of course, deposits were not memo posted no matter how the depositor looked. Banks took all manner of deposits and wouldn't pay out on them until they cured for a week or so. 3) Then as online technology matured, bank systems did the entire transaction task at the source, a done deal.

Here is the dilemma, folks. Legacy systems possess deep and broad functionality. Modern systems possess the ideal architecture, but they haven't been around long enough to develop deep and broad functionality. So which system would you choose? Look at the stats. Today, legacy systems represent 92 percent of all new core system sales. Is there something wrong with this picture, or is it because bankers care more about what a system can do rather than how it does it? The philosopher in me says, "One thing is certain. Like everything else in life, one never gets everything one wants."