Living with Mainframes

Credit Suisse embarks on ambitious plan to use SOA to disentangle legacy applications.

By Emily Fraser

When a technologist tries to imagine a flexible, agile and service-oriented computing platform, the mighty mainframe is probably the last thing that springs to mind. Nonetheless, financial services firms seem rather stuck with these monoliths, after adopting the powerful computers early on and making significant investments in the technology over the years. For example, according to IBM, every one of the top 25 financial institutions and all the larger enterprises in the Fortune 500 have their mission-critical systems running on IBM System z mainframes. These legacy applications are generally home-grown, run on proprietary operating systems such as AIX and HPUX, both flavors of Unix that are made by the mainframe vendor, and have been developed in languages such as COBOL and PL/1.

In its Swiss IT organization, financial services giant Credit Suisse has over 400 core banking applications running on the mainframe host, containing approximately 17 million lines of code, written in the now-waning PL/1 language over the last 35 years. The bank has 11 mainframes in Switzerland with a total processing power of 40,000 million instructions per second (MIPS). The mainframe has its advantages; namely, it is very secure, highly (vertically) scalable and is, after all, very good at the transactional processing it is designed to do.

But the more than 400 applications are very tightly coupled, which makes it difficult to alter the code in one application without affecting the other programs that consume its data. "Changing program code in one application regularly leads to bugs in other parts of our application landscape," says Helmut Imboden, vice president and leader of the Disentangling the Mainframe Applications Landscape (DiMA) program, an ambitious service-oriented architecture (SOA) project under way at Credit Suisse. In order to allow one application to draw information from another, developers have, through necessity, built in very fixed links or interdependencies over time.

For example, creating a credit limit in the credit application domain (CRE) requires information from the customer domain (CUS), says Imboden. When entering a customer's credit data, an employee types in the account number, and the application has to retrieve the customer's information needed to complete the credit form from the CUS domain's database, says Imboden. "If the CUS database is accessed directly by the CRE application, we speak of an unwanted dependency, because any change to the CUS database can heavily impact the CRE application accessing it," Imboden explains.

Because of the sheer size and complexity of the mainframe development landscape within the firm, it is not always this easy to predict where the fallout will be. "If we change a value in one place, we do not know which other parts of the system will be influenced. We have a well-documented code base, but since we have so many lines of code, the complexity is overwhelming," Imboden says.

THE DiMA PROGRAM

Credit Suisse's solution to this problem is to attempt to disentangle the mainframe applications, so that they communicate with one another via a clearly defined, managed interface that hides all implementation details. This should make it possible to apply changes to the underlying database-i.e., CUS-without affecting users of the interface-i.e., CRE-Imboden says. The firm is breaking its 400-plus interconnected applications down into approximately 100 blocks, or DiMA components, which consist of three to five applications each. There are no plans to break individual applications into components as yet, but this could be an option for the future, he adds.

The new interfaces will be written in a meta-language, so they can be converted into whatever language the application attempting to access the interface needs it to be. This will enable PL/1, IDL, Java or .Net applications to interact more fully with the mainframe systems.

Darmstadt, Germany-based SOA solutions vendor Software-AG was selected to manage the component interfaces. The vendor's product, CentraSite, is designed for SOA with out-of-the-box Web service support and serves as a central repository, where all the interdependencies are catalogued and monitored. "We document all the metadata, the interfaces, the components, and the relationships between all of them," says Bjoern Brauel, vice president and deputy CTO at Software-AG. The system allows all the firm's developers to search for components and figure out who is using them, who is responsible for them, how they interact, and what the interface looks like.

The system implements a number of workflows on top of the metadata that describe typical activities developers should undertake when they want to change the system. For example a workflow called "change interface" can be triggered to drive the developers toward a typical interface re-engineering process. The system sends out notifications to the consumers of a particular component, and notifies them of the imminent change.

To help standardize the interfaces after decoupling, Credit Suisse has described a common data model within the repository solution, representing common entities such as customers, contracts, transactions, and accounts. For example, an account must comprise an account ID of a specific length, an account name, and so on. When the engineers go through the workflows defined inside the solution, they are encouraged to reuse and transform the existing interfaces toward the common data model. "The system tracks the developers to see whether the occurrence of common structures throughout the interfaces increases or decreases over time based on the workflows that they are using," Brauel says.

The CentraSite product is very young, released in May 2006, with only pilot installations available, but Credit Suisse believes it could have the potential to become the market leader. "We gave the prospective vendors a simplified data model to extend their product with some of our specific needs. Some of the vendors lost interest, and only two of them went forward and realized a prototype," Imboden says. When looking at the prototypes for the first time, Software-AG's CentraSite showed low performance and crashed, and the other system was not complete, he says. However, Software-AG solved the stability and performance of the prototype within two weeks, Imboden says. "Commercially available SOA repositories are still missing functionality, maturity and scalability for large applications landscapes. This maturity has to be created and is not part of the product you are buying," he adds.

CentraSite uses an XML database, which was also seen as a disadvantage by the bank, as XML is not one of Credit Suisse's infrastructure standards. "If you want to handle large amounts of data, our experience shows that relational databases perform better than XML databases. Considering the fact that we want to build a service repository that is able to manage about 5,000 interfaces and all the descriptions of them with about 50 concurrent users accessing the system, we would have preferred a relational database system," Imboden says.

RIP-AND-REPLACE

The Swiss firm entered the second phase of the 15-year program this September. By 2015, the firm hopes to have fully disentangled its mainframe environment. Considering the amount of time and effort it will take to complete the program, it might seem easier to look for a new, more agile host. But replacing the mainframe host at this point in time is not an option: Imboden estimates that it would cost somewhere in the region of $3 billion.

This is a common dilemma for large financial services firms that want to make the most of more modern technology developments but also want to continue to leverage their long-term investment in the mainframe, says Morten Nygaard, financial services business development executive at IBM. Technology research firm Gartner estimates that there are about 200 billion lines of COBOL code in use today around the world. COBOL is the language most commonly used for mainframe development. At the cost of $25 per line of code, this represents an investment of about $5 trillion worldwide.

As to whether the mainframe is here to stay or whether it should eventually be retired, opinions are divided at Credit Suisse. Some say they clearly want a change from the mainframe to a client-server system, says Imboden. Others say that as soon as the firm is able to create a flexible host, the problem will no longer exist and replacing it will no longer be necessary. Imboden says that this decision can only be made once the DiMA program has been completed.

The fact that the majority of legacy mainframe applications are written in languages such as COBOL or PL/1, which are no longer taught to current IT students, poses a further problem for firms. The majority of mainframe COBOL and PL/1 developers are over 45 years old, says Brauel. "We do have the option of outsourcing to India, but having people on-site who understand the coded knowledge of the past remains important," says Imboden.

GETTING A 'FRAME-LIFT

Another, more common way that SOA is used to extend the lives of legacy mainframe applications is to detach the applications from their unsightly black-and-green screens, and give them a more user-friendly, Web-based, graphical user interface (UI).

For example, Boston, Mass.- based State Street has made its portfolio accounting system (PAS) available to its users via the Web, with the help of Netmanage, a Cupertino, Calif.- based firm. Without changing the core systems or anything on the back end, the firm was able to expose its legacy applications as Web pages via Netmanage's product OnWeb. Brokers reselling State Street third-party funds now log into the State Street PAS application via the Internet, whereas before they needed to download a screen emulator.

Many financial services firms are taking this legacy modernization approach, according to Software-AG's Brauel, and although it does not go anywhere near as deep as componentizing the entire mainframe landscape, it serves a very real tactical business need. For a generation of bloggers and online gamers currently entering the workforce, little could be more horrifying than the idea of using an application that offers only two colors and no mouse. But for all the glitz and glamor, and media attention they receive, true agile Web-based applications form a relatively small fraction of the modern financial institution's application base.

While exposing mainframe access to the Web is useful, firms must be careful not to tie any system to a particular UI, says Stevan Vidich, an industry architect with Microsoft's US Financial Services Group. "The ideal approach is to expose mainframe transactions as Web services, and simply exchange data with a mainframe, while leaving the UI or presentation open," he says. In this manner, a bank can later use that solution to service multiple channels. Rather than tying themselves to the Web channel, they could also use it for the ATM channel, the telephony channel, for a call center application, or make it programmatically available to other mainframe distributed applications. "Tying it to any particular UI would be somewhat contradictory to the tenet of service orientation, where you want to see services exchanging messages. These messages contain data; they're not really specific to any UI," says Vidich.

In the case of State Street's PAS, the initial win was providing a better-looking UI to the users of the application, without having to change the core of a system that does everything it is supposed to do well, says Jim Dobbie, vice president, portfolio systems division at State Street. But the OnWeb technology does not limit access to the Web channel, says Archie Roboostoff, director of product management at Netmanage. "With OnWeb in place, you're able to leverage the old technology and then develop on top of it with new technologies like Web services, C#, Java and .Net," he says.

LIPSTICK ON A PIG?

While acknowledging the short-term business benefits of using SOA to extend the life of a mainframe application, Luke Flemmer, managing director of technology consultancy Lab49, warns against thinking that giving an application a new face makes it a better product. "The fact that the screen looks ugly, weird and old is not just a coincidence. It's indicative of the overall time and level of sophistication of technology when this stuff was developed," he says.

The majority of legacy applications were designed when a lot of the structured products in circulation today had not been invented, and there was no overlap between asset classes. Today, prop trading groups hedge with various different instruments and use cross-asset strategies, and all these things need to be supported by software systems under the covers, Flemmer says. "The reality is it's an industry where a big part of the innovation is technical. So simply putting a pretty new screen on top of an application-it's very much lipstick on a pig," he says.

However, although many firms would most likely prefer to just upgrade the technology, budgetary and practical reasons prevent them, for the time being at least. Aside from the huge migration costs, a lot of historical information and business logic tends to have been built up within an application over 20 or 30 years. "In 90 percent of these legacy application cases, re-creating that business logic is just not possible," says Netmanage's Roboostoff.