Print this
Ron Dembo, president and CEO of Algorithmics, explains how to overcome the problems that slow down installations.

Systems Implementation in Three Months

Implementation of an enterprise risk management system used to take much longer than it does now—two years or more in some cases. But if you carefully consider your needs up front, design an appropriate systems architecture, map all your data properly and build extensibility into your system, you'll find that it's possible to do a large portion of a bank in three months.

Typically, banks that manage to install systems in three months are those that have done a lot of preplanning. One of our clients worked for quite a while thinking about how it was going to go about managing enterprise risk. It thought on an architectural level: It considered what kind of system it wanted, what the system would do, where it would get data, what limitations the system would have and what the budget would be. At that stage, our client met us, evaluated our system and was able to put it into production in three months, because it knew what it wanted to do.

Systems architecture is one of the important things you will have to agree on right away. Let's use the analogy of a building. If I want to build a building that will accommodate a certain number of people, I couldn't even conceive of starting work until that building had been designed. I can't simply get a builder to come in and build it. The builder might start hacking together some building that looks like a nightmare. It wouldn't function—the elevators wouldn't work or connect to the floors.

If I want to build a building that will accommodate a certain number of people, I couldn't even conceive of starting work until that building had been designed.

The analogy of the building applies. You shouldn't call in software people to build or implement a system unless you've put the architecture together first. The best systems architects are people who understand the business, who understand the needs of the software and its limitations, and who know where they can get what data.

Another big part of reducing implementation time is the use of mapping tools. If you are not making use of them, a three-month project might take a year and a half. Mapping is important, because it allows you to input directly the business logic required to transform data.

A risk management system typically involves a tremendous number of different data sources. When people think of implementing a system, they usually think only of the position and trade data: what they own, what they've bought and what they've sold. But a system is much more than that. It involves terms and conditions of instruments, default pricing configurations, market data, historical data, scenario data and so on. For example, when you are pricing instruments, you use certain specific data just to calibrate the instrument pricing.

Let's take a typical swap. You might be able to extract from a front-office system 13 pieces of data describing the swap. Typically, this will not include many attributes of the swap that are important for pricing, such as the day-count basis or business-day rules. Unless you have the mapping tools in place, how would you find the data that are missing? Simply discovering where that information resides takes considerable time. Proper mapping tools, however, can speed the process.

In certain cases, it is quicker to get missing data from external sources than to find the data in-house. To help facilitate this, in our implementations we provide a great deal of preconfigured data for risk management, including links to third-party market data and terms-and-conditions data vendors. These packaged data can save many months in an implementation project.

Tools and data alone are not enough, however. You also need to know how you're going to tackle the implementation. For example, our company maintains a systems implementation methodology, a step-by-step process with defined intermediate deliverables for carrying out an implementation project. This document captures our best practices and provides a road map for planning and tracking the project through completion.

Another important thing systems architects must consider is flexibility and extensibility. You'll need to design a software environment that can extend to new instruments created during and after the systems implementation—instruments that you have never seen before. Take, for example, inflation-linked bonds. When you built your system, you may have presumed that every instrument could be priced off one curve. Then, after you finish your system, you realize there are inflation-linked bonds and you need more than one curve. If the system were inflexible, the change would require a fundamental redesigning.

The same applies to extending the number of system users. Let's say you start construction of a building for 2,000 people, but halfway through, you realize it has to support 4,000. If you didn't build into the design the notion that you might want to extend the building a few more stories, well, it will be too late to start over. Too late—and too costly.

In order to handle a financial product you have never encountered before, the system must have an external mechanism for incorporating the product. This involves something called metadata, or data about data. When you communicate to the software that you've added a new instrument, you should be able to communicate all the attributes that this instrument has and what they mean. The software should then be able to extend itself automatically.

If Bill Gates wanted to build a risk management system in three months, and took a billion dollars out of his cash account, he couldn't do it.

This is not unlike what you can do in products such as Excel now. The original spreadsheets were hard-coded. You could not add new menu items or customize them in any way. Now you can go in and create a particular menu that suits you because the product can handle that extension. This is a new type of software environment.

Here's the most important advice I can give on speeding up systems implementation: Go with a vendor that specializes in building systems—it's better than going it alone. If you go it alone, you'll have to build the whole software infrastructure and conceptualize all the things you might need. But a vendor that has worked with 60 banks already knows all the different variables they have in common.

In some ways, you can think of software like wine. Let's say I gave you $10 million and told you to give me wine in three months equal to a Chateau Lafitte, 1951. No matter how many millions I gave you, you couldn't do it. If Bill Gates wanted to build a risk management system in three months, and took a billion dollars out of his cash account, he couldn't do it. It would take him time to put an effective team together, and a long while for the team to conceptualize a solution and agree on it. Then it would take more time to build it, and years more for it to mature.

The total person-years we've spent at my company building our risk management solution is something on the order of 300. That means 300 people working for a year, or 100 people working for three years. If we rebuilt it knowing everything we now know, it would still take at least 100 person-years of development time.

It is difficult for people at a bank to design a system such as this, because the world is changing under their feet and they have experience only with their own historical needs, not the diverse needs of 60 customers. Plus, there is a tremendous amount of software to write that is complex and that would take a lot of time to develop. They could hire a lot of software developers, but they wouldn't find many who understand finance as well. And considering the turnover in banks, they also need to realize that the developers they hire today are likely to move on before they've finished their system.

One final word about three-month installations. I don't mean to suggest that everything can be completed in that time frame. In most cases, there is an 80/20 situation, in which 80 percent of the book can be modeled easily and 20 percent is either poorly documented or is made up of complex, exotic instruments that need specification and expert financial engineering to model. But if you do things right, you should be able to get the most important functionality in place within that time frame.

Was this information valuable?
Subscribe to Derivatives Strategy by clicking here!