As banking institutions increasingly look to technology in an effort to improve operational efficiencies and reduce costs, key software vendors survey the market for opportunities to enhance and extend their product ranges for their own financial gain. The question is, to what extent are the new products and upgrades - that consistently emerge - of real value to the investment banking industry? Or, are they simply a means of survival for the software vendors?
Summit is viewed as one of the market-leading software solutions, providing support from the front through to the back office for interest rate derivatives and treasury businesses and has been implemented by many of the major investment banks.
The Summit application has in the past few years undergone a radical redesign process and moved on from the 2.x series to the 3.x series of releases. Users of core Summit technology will realise that there have been a number of significant changes, although perhaps not immediately apparent from the previous functionality. In fact, the technical architecture has been substantially overhauled, with virtually all of the underlying tables’ structure and data types affected, as have the ‘hooks’ provided by Summit that enable it to connect to external code. This will have a significant knock-on effect on extensions and interfaces to Summit.
However, these changes to the technical platform are at first glance, less immediately visible to the users in terms of improved performance and greater reliability. As a result, Summit’s decision to upgrade has been met with mixed reaction and some of the more skeptical parties have raised doubts about the extent to which the upgrade and enhancements will bring added value to their organisation.
Key areas of new functionality
The key benefit of this reengineering to the core Summit application and therefore to the end user, is that all version 3.x implementations have the potential to add on new real time functionality in the form of bolt-on modules. There are a number of these modules already available and more are in development at present. This represents a much faster and more standardised way of adding some very powerful functionality, in addition to the client extensions already allowed.
Risk monitoring
Real time credit risk monitoring can be achieved using the real time credit server, which provides instantly updated real time credit limit utilisation information to both traders and risk managers. And it includes alert functionality to highlight potential or actual credit limit breaches to the risk manager.
Improved market risk monitoring capabilities have been developed with the ability to run the highly processor-intensive Monte Carlo simulation calculations intra-day, using distributed parallel processing techniques to make use of spare machine capacity.
Front office
Significant improvements for the front office of FX trading have been performed, which involves the introduction of real time FX position-keeping. It is also expected that real- time position-keeping will be extended to cover additional product areas - a significant improvement to the Summit product. This could replace some extensions for a number of banks where real time position-keeping has previously been added to the application in house.
Back office
With the drive to reduce operational risk, Straight Through Processing (STP) has been high on risk managers’ agendas and the STP module of Summit v3.x may be of interest to some financial institutions. The new functionality is in the form of a set of workflow rules which are user-configured to determine which trades need to be fed into particular workflow streams – i.e. amend, allocate payment instructions, verify and send straight out with default payment instructions attached. There is also a new real time graphical user interface (GUI) which enables the user to both view and interact with the trades and execute the workflow.
Why upgrade at all?
Software vendors cannot economically support legacy versions of their software indefinitely and at some stage will require clients to upgrade their installation to one of the newer versions. There is significant new functionality in version 3.x of Summit but the key driver to the upgrade decision for most clients at present is Summit’s intention to withdraw support for version 2.6e4 and all previous versions from March 2001. The implication of this is that Summit will be under no obligation to provide patches or fixes to any bugs after this date to these legacy versions.
The challenge of version 3.x
The key features of Summit, which have contributed significantly to its success, are the flexibility and extensibility offered. However, these same features make it difficult to upgrade compared to a more standardised product. The flexibility means that each implementation is unique, with almost every piece of functionality tailored to the needs of each particular client through extensive configuration utilities and menus. The extensibility functionality has been widely used to build highly complex, powerful and, in many cases, business-critical tools as extensions or add-ons to the core Summit application.
Consequently, for many investment banks, making major changes to systems already in place is a daunting prospect. In order to understand the size of the task, the first step should involve a detailed analysis of the implication of the upgrade to the specific implementation, identifying and assessing the effect of the upgrade on all the Summit extensions present. It is possible that some of the additional functionality previously added as a client extension may now be provided by Summit as part of the enhanced offering.
Summit does supply upgrade scripts to assist with the conversion process. These appear to be reliable for upgrading core Summit functionality and may work with some client extensions. In some cases, however, client extensions will require additional effort to upgrade. A thorough analysis of the implications of the upgrade for the particular implementation should be undertaken at an early stage in the planning process to identify which extensions could require extensive work to upgrade.
Which version to choose?
The decision as to which version to upgrade requires a great deal of consideration. The very latest version should not be the automatic first choice - if the latest functionality is not required, it may be preferable to use a more robust tried-and-tested earlier version. All systems documentation contains errors and omissions and all software contains bugs! When upgrading the bank should agree with Summit the level of support it will supply in terms of assistance with the upgrade process. It should also include details of a mutually acceptable mechanism and timeframe for reporting bugs and supplying patches to fix them. A greater commitment should be expected from Summit to assist with bug fixes with the newer versions, especially if there is no other bank that has successfully implemented the version for a similar type of business.
Alternatives to upgrade
There are other options, which should be explored during the upgrade decision-making process, especially where an upgrade is not anticipated to be a straightforward exercise.
In some cases the upgrade may require such significant effort and cost that it may be similar to re-implementing from scratch. In this case it is worthwhile considering the decision to upgrade alongside other options – this may involve implementing an entirely new system.
There may be a case for taking the potentially high-risk option of ‘going it alone’ and continuing with the existing implementation without the vendors support.
This will probably only be a sensible option if:
· There has been a substantial level of in house development of the core application directly from the source code and thus sufficient depth of understanding of how the application works;
· There is adequate in house resource to support the system in future;
· The system is considered stable and robust and the upgrade is of little or no business benefit.
To continue with a legacy implementation of Summit without support from the vendor, the bank must ensure that it has access both to the source code and to sufficient appropriately-skilled resources. It should also ensure that this course of action is within the scope of their license agreement. However, we understand that Summit do not intend at present to sell the source code to any further banks.
A final thought
Upgrading to version 3.x of Summit is potentially a major exercise. But at the same time it introduces to the investment banks the possibility of accessing newly developed functionality and further enhancements planned for the future that will not be available to version 2.x sites. However, the effort involved in the upgrade should not be underestimated and a detailed planning process should be initiated as soon as possible by any banks intending to go ahead with the upgrade before March 2002, if they have not already done so. Taking all of this into consideration, it is fair to say that Summit should prove to be a reliable and flexible platform for future growth.
Xavier Bellouard, managing director Summit Systems International Limited, responds:
“Here at Summit, we acknowledge that a version upgrade is a non-trivial event for our clients, but we supply the tools and help to make it as smooth as possible. Our philosophy at Summit has always been one of evolution rather than revolution, and from the very start we designed the system in such a way that client extensions could be carried out without making problems for our clients when we release new versions. The Summit Toolkit provides all of this extension ability, rather than the more traditional vendor approach of licensing source code, that has backfired on so many vendors and their clients alike. We now see many of our clients live on version 3.x, many more in the process of moving, and are confident that all will have moved successfully by next March.

How to go about the upgrade
Planning and strategy review phase
Discuss with all stakeholders; front office, risk accounting, back office operations and payments, credit and IT to identify:
- Scope and objectives of the upgrade
- Potential areas that can be improved
- All interfaces into/out of Summit
- All extensions and patches to Summit. It will be necessary to schedule testing early on and make allowance in the upgrade plan for amendments and to consider whether patch or extension is still needed - the upgrade may have an alternative method of approach
- Extent and nature of the testing required
- Discuss the upgrade with Summit
Testing phase
- A test script will need to be compiled, possibly based on the testing done for the original implementation
- A unit test should be carried out to ensure that the functionality is as required
- An integration test will be necessary to ensure all components work together
- Hardware compatibility must be checked, carrying out performance tests and ensuring benchmark performance levels are met. Old hardware may still work but performance could be degraded to an unacceptable level
- Use of testing tools should be considered to automate testing routines. Tools may be useful for stress testing where they can be used to simulate high volumes and/or multiple concurrent users.
Rollout
- Conversion of live deals over to the upgraded version once full testing has been completed
- A data clean-up exercise is likely to be required
- User training should be carried out and changes to workflow should be documented
- A back-up plan should be on hand should problems occur once the new system has gone live
- Business continuity plans must be updated and the new version of application and extensions should be stored offsite along with other applications.