For banks that have been developing core banking applications since the 1970s and are still relying on those codes, the costs to manage those systems will likely be increasing, while the pool of talent that understands those systems will decrease over the next five to 10 years. The time may be nigh, some in the industry say, to at least begin planning a conversion of those applications to a more flexible, open environment, away from pre-rational databases based on Cobalt code to more flexible, rational databases running on Microsoft or Oracle.
Not many banks have gone this route yet. After all, it's an expensive venture, one that costs millions of dollars. And there is the prevailing wisdom that "If it ain't broke, don't fix it." It can take real persuasion on the part of IT staffs to convince management of the need. "It took us a decade to get approval for conversion," remembers Barry Ibey, who managed the conversation at National Life Insurance last year using a technology from Sophisticated Business Systems.
But, finally, the pros of conversion began to outweigh the cons. National Life had lost all its IDMS programmers-a recent survey found that the average Cobalt programmer is 53, with few new grads bothering to learn the old language. And there were constant rumors that Computer Associates would drop support for the old system. The institution also realized it could actually reap immediate ROI by converting its CA IDMS system to run on IBM's DB2 system, which it also supported. And, finally, different areas within the insurance company wanted to access customer information in the database. "We had no utility for them to get in there," Ibey says.
The reluctance of executives go beyond the sheer cost of the project, including the concern over something going awry. After all, these legacy systems are often at the heart of the enterprise. Any down time in the eyes of customers is inexcusable, and the heightened regulatory environment is also a consideration.
"A lot of big banks like mainframes," Bart Narter, a senior analyst at Celent Communications. "They're secure, and you don't hear about viruses on the mainframe. They say, 'It's old, but it works and I'm not going to take the risk.' It's actually no big deal to extract data and populate some new database, but mapping what that data means to the same specification to the new system is the trick."
That is precisely the trick that several technology vendors claim to have mastered. "With our conversion, you take the unique software and move it to the new technology," explains Cindy Howard, an evp at Sophisticated Business Systems. "It opens up the legacy system that can't always get at the data, but it protects the business rules and moves them to a new environment."
She says that preserving these business rules is key, not only so the enterprise can operate seamlessly after the conversion, but because often these legacy applications are a competitive advantage.
Ibey's experience at National Life bears that out. "We wanted to create the least amount of disruption to the business community as possible," says Ibey, now a principal at Keane Consulting. SBS's "shuttle tool" converted all the language of the database from IDMS to DB2, and preserved all the business rules from the IDMS environment. The actual conversion occurred over a weekend and went off without a hitch, Ibey says. The price tag was $1.5 million to convert five IDMS applications, a 50 percent discount since National Life was helping SBS "work out the kinks," he says.
BluePhoenix Solutions is another vendor that claims to have mastered the conversion of data with the preservation of business rules. Arik Kilman, CEO of BluePhoenix, describes the BluePhoenix product as "open-heart surgery. We don't touch the business rules, but we replace the technology, such as IDMS, with Oracle or Microsoft. We're not touching the design or the business rules. We just upgrade the technology."
He puts the cost of using BluePhoenix at a maximum of $5 million. Already BluePhoenix has a number of clients: RSI, a group of banks in Spain; a Swiss bank he declined to name; Leumi Bank in Israel; and a large U.S. bank, which he also declined to name.
Kilman, as well as others in the industry, expect it to take another five to 10 years before this kind of conversion takes off in the U.S. By that point that 53-year-old programmer will be retiring, and there will be a tipping point where so many new applications have been written that converting the old systems will make economic sense. "As they write new systems, they're not going to write to the old code," says Donald Feinberg, an analyst at Gartner, "and that will pull them further away from the older system. And these newer systems prove you can do it without the older systems."
