Dedicated to providing comprehensive and up-to-date coverage on Business Transaction Management and its growing place in the IT management industry

Trading Application Case Study

Project scope

A proprietary trading application serves the bank’s clients and internal traders over the web, enabling them to perform all of the electronic trading services provided by the bank. The application supports approximately 30,000 clients and several hundred professional traders. Use of the system generates billions of dollars in revenues with estimated profits of several hundred thousand each day. The trading platform is used across several times zones: Asia Pacific, Americas and Europe. It is characterized by low-latency transactional activity and spiky volume. Due to the application’s general reliability and good reputation, the user community is expected to grow at a rate of 50% annually for the foreseeable future. Therefore, the application and environment are required to grow by similar proportions and measures need to be taken to ensure the planned growth in scale does not result in degradation of service.

Application details

The application is comprised of a complex set of software components deployed over 30 physical servers and networks, using the FIX protocol. It is surrounded by other applications, users and transactions that compete for a finite set of resources. The application’s interactions cannot be an impediment to timely transactions which must traverse this complex infrastructure, because they are handled by different processing tiers.

Goals

The bank wished to achieve tight business and IT linkage including:

  •    Visibility into all trade transactions including FIX and surrounding applications
  •    Understanding the business impact of the infrastructure's tier-mapping to trade transactions
  •    Proactive prevention of application performance problems and outages

Methodology

The bank was looking for a software solution that could monitor trade transaction performance across the entire application infrastructure – at the trade instance level. This solution would need to monitor individual trade transactions across FIX and surrounding processing tiers of the application architecture. Trade transaction monitoring would allow for real-time and historical views into the complex operations of the application and would enable the system to operate effectively at all times, even at peak demand.

Challenge

Service availability and application stability
The organization had a solid reputation for system reliability. A key driver for seeking investment was to protect this reputation as the system aggressively expands over the next few years to accommodate many more users and increased activity levels.

Slow trading at peak times
The application was increasingly experiencing performance issues during peak usage times, resulting in poor user experience. Any slowdown might result in a significant loss of profit, particularly with large value trades. Handling large volumes of trades on behalf of important brokerage houses – and making sure that service level objectives were being met – was becoming increasingly difficult.

Increased infrastructure complexity
The increase in hardware is expected to be proportionate to the projected usage growth.  This growth will result in increased hardware budgets, additional resources to manage the application and larger floor space to accommodate additional boxes. The expected increase in infrastructure and users would result in a much more complex environment. It would also significantly increase the difficulty in pinpointing and eliminating performance issues that result in downtime, loss of revenue and user dissatisfaction.

To this organization, any loss in reputation, clients or profits – due to poor service delivery – was deemed unacceptable. A solution was needed to significantly reduce these risks.

Solution

A Business Transaction Management solution was chosen to answer these challenges. It tracks and monitors all trade transactions – across FIX and surrounding applications, all the time – in order to create and maintain a complete profile of transaction activity in terms of both time and resources. BTM monitoring provided:

  • End-to-end visibility into all trade transactions in real time
  • Understanding of trade transaction latency from the business and IT perspective of and the exact business impact software components were having over trading activity
  • The ability to respond to trade transaction latency issues in real time with pinpoint accuracy into each single transaction executed by internal or external users
  • Quicker problem resolution, resulting in higher system uptime reduced trading losses and more effective use of IT development resources
  • Improved accuracy of capacity planning by using real-life transaction resource consumption data to simulate increased workloads
  • Real-time alerts enabling IT to preemptively resolve problems before they could affect users

Result

The implementation of BTM technology provided:

  • Low-overhead response-time breakdown and resource consumption statistics of a single business transaction
  • Accurate transaction tracking of approximately 2,000,000 trades per day – without resorting to less reliable performance monitoring methods such as sampling or using synthetic transactions
  • Transaction flow monitoring, with a tier-breakdown view and the ability to adapt to topology changes with no need for application code changes
  • The time a single transaction spent in each tier and the ability to differentiate actual service time from the overall elapsed time on each tier
  • Transaction resource consumption data from a tier perspective and understanding of transactional resource allocation
  • The ability to identify and isolate latency caused by both the database tier as well as external FIX feeds to the trading system
  • Visibility into the round-trip path taken by each transaction and an accurate breakdown of trade times to sub-component latency times, despite the asynchronous nature of transaction flows