What's Data Got To Do With IT?

The problem with most technologies that address one or the other is that increasing throughput puts strain on underlying networks and software that latency goes out the window. The reverse is also usually true, as an intense focus on minimizing latency has a tendency to restrict throughput. This is especially challenging because the back- and front-office environments each have their own priorities. In the back office, throughput is key as banks struggle to process more and more trades, while in the front office they strive to squeeze every microsecond out of data delivery despite an increasing amount of data. So, latency and throughput are equally important business objectives.

The primary rate limiters remaining in market data delivery are in software and operating systems, so the next logical step is to move to an all-hardware solution.

By contrast, in environments that are relatively insensitive to latency, such as distribution systems for human end users, throughput can be tackled without much concern for latency. Most systems today can handle hundreds of thousands of messages per second without getting close to latencies that a human could detect.

Hardware is actually just a new, simpler-to-use form of financial application infrastructure. You can buy new servers, rev them to a specific operating system version and patch set, then install software-or you can buy an integrated hardware appliance that's certified and ready to go. Upgrading a software environment entails patching the OS, revving the software and testing to see what each dependency might have disturbed. Upgrading hardware is a single instruction to refresh firmware. Beyond that, interacting with hardware middleware is through APIs and client libraries, exactly as it works now. Any middleware team can adapt to hardware as easily or probably more easily, as it does to any new software middleware product.

For deployments of any size, hardware is a lower-cost solution than existing software and servers. It is not uncommon for large investment banks to have thousands of software servers just to handle horizontal scale and redundancy of various market data and back-office middleware systems. Hardware can reduce that server/software footprint by anywhere from 10:1 to 30:1, such that tens of hardware devices can do the work of a hundred software boxes. On any single cost dimension-hardware, software, power or cost of maintenance-hardware is a lower-cost solution. When all dimensions are factored, it is a runaway winner.

Reduced hardware infrastructure also means less support, better maintenance and fewer failure points. Overall, this translates to greatly reduced support costs with substantial reliability gains.

Guy Tagliavia, president and chief executive, Infodyne: Hardware acceleration may raise the threshold at which message volumes can be handled, but without the ability to scale, the solution and return on investment can be short-lived. Aside from the higher cost of entry, hardware acceleration may also limit functionality and make it difficult to adopt changes imposed by the feeds and/or customer requirements. Such a solution needs to be based on a proven product methodology and flexible deployment strategy.

We applaud the evolution of independent analysts and testing agencies like STAC that publish legitimately independent performance numbers based on publicly available platforms and benchmarks that are starting to be standardized. This allows the realities to be separated from the hype by standardizing test cases so vendor claims can be verified in the context of very specifically described test environments-for example, how many publishers, how many servers, what machine types and OS was used, what NIC cards were used, what were the message rates, what was the message size. And the most critical point to define and standardize is how throughput and latency are measured. Additionally, performance at the edge is critical, as claims of average latency without standard deviations and outlier measurements are of little value.

Tagliavia: There will always be varying levels of latency tolerance, depending on the client's application requirements. It's not always latency that differentiates one program trading application from another-quality of data can be equally as important, while consolidated views of the market, complex event processing, and statistical analysis all require quality data. It is also equally important to have a system that can deliver high-quality data to latency-sensitive applications and, in parallel, support applications that are not so latency-sensitive, all from the same data source. This provides economies of scale and allows customers to leverage their investment in direct feeds throughout their data enterprise.

The second wave of performance anxiety will be in order execution and order routing to the best available source of liquidity. It does you no good to make a trading decision in 10 microseconds if your order can't be routed in less than 10 milliseconds. There are plenty of legs left in infrastructure performance overhauls.

Tagliavia: Most customers see a need to support both analytical and desktop applications. Desktop applications are also becoming much more advanced and capable of summarizing the strategy of the firm to the trader, rather than delivering the raw data, and leaving the real number crunching to high-powered application engines.

Tagliavia: CEP vendors are now finding the same low-latency demands placed on them as the platform providers. Therefore, it is a natural extension to incorporate CEP within the market data platforms themselves. Depending on the strength of the partners and their relationships, customers may find varying levels of value in these partnerships. An ideal scenario is that a big enough player has all the software, hardware, and support resources necessary to deliver a coherent, holistic, and fully integrated solution to customers.

Tagliavia: Location is a big factor, given the laws of physics, but sometimes there is no choice but to centralize data collection and usage given some firms' broad market data sourcing requirements. Location aside, the most critical aspect of latency tolerance is not so much shaving microseconds, but ensuring a consistent, jitter-free latency profile, regardless of message rate fluctuation. Also, since latency can occur for any multitude of reasons-the least of which is the result of any one consistent issue-it is critical to be able to detect, report, pinpoint and resolve latency breaches when they occur. How well this is done differentiates vendors in this market.