June 16, 2008

StreamBase 6.0 Product Analysis and Thoughts on Leadership

June is a big month for CEP product releases, and the past few weeks have been no exception:  Aleri  StreamBase-Debugger announced version 3, Apama announced version 4, and StreamBase announced version 6.0.  Unsurprisingly, all these announcements contain proclamations of leadership.  Aleri's headline claimed a better look and feel, and Apama announced integrated sample applications and unsubstantiated performance claims.  By contrast, I think StreamBase announced an important breakthrough:  the first visual debugger, profiler, and unit testing environment in the industry. 

One of the main reasons I chose to join StreamBase is that in my time in the CEP industry, I've heard from customers, prospects, and industry insiders that the technology is simply superb:  it's fast, it's open, it's scalable (multi-threaded), and it has adopted a language metaphor (SQL) that is standards-based and familiar to most developers.  The visual environment uniquely enables business users and IT alike.  

I think release 6.0 extends that lead.  The ability to debug, test, and profile event processing applications is absolutely critical to ensure fast, reliable, and managable deployment in large enterprises, as well as adoption by smaller firms that need to do more with less. 

The release contains the following:  

  1. StreamBase Visual Debugger - One of the hidden problems with some CEP platforms is that the visual tools were added as an afterthought, and, as a result, they generate code that's impossible to test, support and debug.  This is not the case with StreamBase, that started with a visual development tool from the very core, which has made it an incredibly powerful, integrated platform on which to debug and analyze applications, because there is no code generation - what you see is what you get and it's what you debug. 
  2. Profiling - Profiling provides the ability to test, profile, and provision software and hardware resources associated with a CEP applications.  Once again, with StreamBase profiling, you profile and optimize the actual code you designed, so the result is a better, faster, more reliable application.
  3. Unit Testing -  As the CEP market matures, larger and larger development groups are involved in CEP application development, which motivates the need for more sophisticated group development capability to test applications.  StreamBase Unit Testing allows teams to work in parallel, and allows teams to reduce application errors during development.  Unit testing also enables business developers to more fully participate in application development by providing IT the ability to test code supplied by business analysts before putting it into production,

The release of these features further demonstrates that CEP platforms are coming of age and ready for enterprise adoption and large, group development.  Yes these platforms are mature - today.

June 03, 2008

Event Processing Technical Society (EPTS): Thanks, Opher

The press release finally hit the wire today announcing the EPTS.  The goal is simple:  promote awareness about event processing technologies.  Immediate reaction has ensued, both negative and positive.   To me, having been involved in many of these discussions, I think any step forward is a good step.

This has taken about 2 years to formally announce this group. And, although the spirit of this has been to work as a community, and not single anyone out, there's no doubt that without a determined leader in the group nothing would have happened - from my point of view that's Opher Etzion - so I'm going to simplys link to Opher's blog, and his perspective, on this release as the best source for perspective.  I remember meeting Opher in New York at IBM for the first time about 3 years ago and discussing a vague vision of vendors, analysts, and academics all coming together to help resolve disputes and push a common understanding.

Here's hoping that the EPTS continues to advance this very important field.

Thanks, Opher.

June 02, 2008

Real-Time P&L Use Case Requirements

Back to our exploration of another use case for CEP:  Real-Time P&L.  Last week, I published an introduction to RTP&L from a paper I did with Bob Giffords.  Tomorrow, Corwin Yu and I will hold a webcast:  The Best Practices of Real-time P&L (register here).   We'll explore the requirements and best practices of real-time P&L systems, and demonstrate the StreamBase Real-Time P&L Framework live.

What are the requirements of real-time P&L?  Today’s trader execution environment involves orchestratingReal Time PnL many different broker, market, and in-house platforms, typically with multiple execution management (EMS) or order management systems (OMS) dedicated to different asset classes.

Consolidated and direct feeds from firms like Reuters, Bloomberg, Comstock and the Exchanges and ECN platforms need to be integrated along with specialist broker and in-house feeds and distributed to the appropriate analytical and trading systems. Trades too need to be tracked, not just back to orders but allocated to underlying instruments, portfolios and strategies if they are to inform decisions. OTC transactions may not be fully automated, so data collection for real time P&L will also need to link into the appropriate work-flow processes within the firm.

Some traders are even integrating elementized news feeds as well as reference data feeds like corporate action announcements into their pricing systems. These can be XML feeds from the news wire services to pull out and tag key event data or market sentiment indicators from the articles themselves.

Where needed for complex instruments, pricing models mediate the data streams to value them based on market reference prices. Indeed there are cases where multiple valuation sources are employed and these need to be cleansed of errors or outliers, normalised and harmonised into a consistent set of prices to be used for the P&L. Where appropriate, foreign exchange translations may be needed to bring all values into the firm’s reporting currency.

The P&L system next aggregates all the valuations and compares them to various baselines to work out the relative gains and losses. These can be rolled up to the book, strategy or portfolio level, and the firm may then apply alert or market signal filters.

On the output side these filters might trigger intraday alerts and generate analytics and graphical charts to enhance trader or investment manager control. Heads of desk may want to drill down into the detail and understand why the values are changing. Automated compliance auditing algorithms can be run and compliance officers may use this real-time view of trading activity to monitor that regulatory and prudential controls are enforced to satisfy demands for intra day due diligence.

As traders gain confidence, the outputs from the P&L calculation can be fed back to algorithmic trading engines as signals to generate automated orders using investment strategy models.

Next up:  A Case Study on Real-Time P&L.

June 01, 2008

What Does it Mean to be Mature?

My rebuttal to Ivy Schmerken's article called Deciphering the Myths Around Complex Event Processing has drawn a surprising amount of controversy.  In Ivy's rebuttal to my rebuttal, she clarified that the point although CEP is used in mission critical systems in the world's largest banks, that it isn't "mature" because:
  1. There isn't a CEP language standard
  2. There is debate about whether some CEP engines have a TIBCO adapter
  3. One CEP user had a problem that the CEP companies all focus on different application areas
These seem to be the basis for broadly concluding that "CEP isn't mature."   Tim Bass also agreed with the view that CEP isn't mature, but didn't cite why.

Wow - talk about glass half empty thinking!  But I think the issue here is we have to define what we're talking about, and examine the state of the market in a clear framework, rather than taking one data point (one panel discussion with one person) and extrapolating a broad conclusion.

First of all, let me start by clarifying:  of course CEP is not as "mature" if you compare it to, for example, J2EE app servers or relational databases.  But let's look a little deeper, and look at a well-known model - the diffusion of innovations model (originally developed in the 50's by Bohlen and Beal, popularized by Everett Rodgers in 1962, then by Moore's Crossing the Chasm in 1991.  The original research actually analyzed adoption of farming practices, and developed the following phases:
  1. Innovators - had larger farms, were more educated, more prosperous and more risk-oriented
  2. Early adopters - younger, more educated, tended to be community leaders
  3. Early majority - more conservative but open to new ideas, active in community and influence to neighbors
  4. Late majority - older, less educated, fairly conservative and less socially active
  5. Laggards - very conservative, smalls farms and capital, oldest and least educated
I cited customers that have deployed CEP that fit the "early majority" characterization.  That is: "conservative, open to new ideas, active in the community and influential to neighbors."  Interestingly, on this point, there was no debate, yet STILL we leap to the statement that CEP isn't mature.

But let's look at the arguments for immaturity, namely:
  • Some vendors don't have all the needed adapters
  • There's no CEP language standard languages among vendors
  • There are no interoperability standards
  • My guess is that Tim would add best practices and reference architectures lacking (I agree)
On the other hand, there are many areas of maturity that enables the early majority to deploy, including:
  • Battle-tested CEP server engines (multi-threaded, highly scalable)
  • Adapters for interoperability (there are hundreds out there from vendors today and I will argue that CEP standards for interoperability are a red herring on another day)
  • There is a vibrant community building around CEP on line
  • Robust development tools for business analysts and IT
  • The existence of robust debugging and profiling tools
  • Language support for Java, C++ and graphical approaches
  • Relational database connectivity
  • Tick database connectivity
  • Visualization / dashboards, connectivity to .NET, web dashboards, and more
  • Simulation and testing environments
  • Fault tolerance
  • Management functionality
  • State recovery
Wow that's a lot of stuff!   I'd call a platform that has all of these things mature, and there are definately a number of CEP platforms that have all of these.

Should the community focus on standards and interoperability more?  Yes, of course.  But just because there are different approaches to solving a difficult problem, and that the industry is starting to come together, we shouldn't feel compelled to thwart that growth with a claim that the products are not "mature" when they actually are in a lot of ways.

May 28, 2008

Real-Time P&L Best Practice, Motivation, and More

I’ve had the good fortune of working with Bob Giffords, the former CTO of a leading bond trading platform and a well-known industry spokesperson in the financial markets in EMEA, on a paper on Real Time P&L.  The paper will be published soon, but in advance and as an augmentation, the web is a great resource.  The web has the advantage of hyperlinking to other resources, for a more interactive style of communication, and to solicit feedback, which is always welcome and is constantly offered by posting here even if it was not appreciated! 

The paper begins by discussion the motivation for real-time P&L systems, the requirements for such systems, some architectural best practices for deployments of such an architecture based on CEP, a case study, and a view of moving forward – what lies ahead in this application area.

First up, a discussion of the motivation for real-time P&L

Motivation for Real Time P&L

The financial markets are accelerating: transaction volumes are up, latencies are down, complex cross asset trading up, revenue margins down. Recently markets have seen sudden spikes in volumes, and nervous volatility when the old rules of thumb broke down. Technology and global regulators have both changed those rules by increasing transparency, intensifying competition and multiplying e-commerce relationships exponentially. Reforms such as Reg NMS in the US and MiFID in Europe have further increased the pressure, along with Basel II and the fair value accounting rules of the new international financial reporting standards (IFRS). The IFRS require, for example, firms to mark more of their assets and liabilities to market, while Basel II is much more explicit about risk adjusted capital reserves needed. Now, when markets move, traders need to catch them on-the-fly to cut their losses and go with the flow to ensure compliance with all the rules and customer mandates. The difference between just-in-time and just-too-late has just got a lot bigger.

It was not so long ago when daily profit and loss (P&L) and risk evaluations were state of the art. In a multicurrency world with ever more automated robotraders and instant, electronic global news, they are now painfully slow. This impacts not only the high frequency traders or global market makers trying to balance thousands of real time orders and quotes against a flood of market data with awesome peaks at tens or hundreds of thousands of messages per second. 

Now the credit squeeze of 2007 has renewed the focus on costs and risk. It demonstrated that some firms can lose billions in a single day, algorithmic trading systems can get confused in highly volatile markets, and end of day positions may mask serious intraday exposures. So now even traditional investment managers are keen to optimise their trading performance and track the impact of intraday movements and fluctuating daylight exposures. If risk can change by the second, traders, investment managers and compliance officers too need to track their P&L in real time in order to provide a sensible framework for judging risk as a key factor in making trading decisions during the day. Not to have at least some idea of intraday performance is like flying blind.

Of course, some trading tools and broker algorithms already have real-time analytics. However, these all work differently and firms typically employ multiple solutions and lack ways to integrate them into a cross-platform view of risk.   In addition, the increased adoption of cross-asset trading further complicates the real-time risk picture, and motivates the need to assess P&L across the enterprise. 

However, is such a firm-wide portfolio map, marked to market in real time, really feasible, however desirable? Would it not absorb huge amounts of technology resources and be meaningless anyway, due to insufficient or stale market data? Would not the overhead of software maintenance inhibit innovation and the trading of new asset types like credit default or volatility swaps, so helpful for total return funds.

Agile investment firms are in fact demonstrating that real-time P&L is not only feasible, but highly lucrative as well. It opens up investment opportunities and trading styles, which might otherwise be excluded as too risky or too  demanding in resources.

New technologies like complex event processing (CEP), applied as a “white box” systemfor real-time P&L, have turned tracking real time market movements into a practical proposition for ordinary firms. They can also play a key role in easing the transition to fragmented markets with their notorious dark pools and to the complex array of order, execution and liquidity management systems to support them.

Next section:  The Requirements of Real-Time P&L

May 22, 2008

CEP Myths: Mature or Not?

Ivy Schmerken recently wrote an article on CEP in Wall Street & Technology called "Deciphering the Myths Around Complex Event Processing."  The myths were:  1) the technology is mature, 2) it's sell-side only, and 3) it's "out of the box and easy to use."   

I thought myths 1 and 3 were well argued, but I couldn't find support for the claim that CEP isn't mature. Quite the opposite, actually.  For example, Ivy cited AITE group's Adam Honore's opinion that CEP's use is expanding and cited a number of the public references like the FSA and Turquoise.  I wrote an entry on this topic a few weeks ago as well based on initial visits with StreamBase customers and their usage.  Public disclosure of initiatives like this argue for maturity, not immaturity.

Marc Adler from Citi said: "CEP is not this golden pill that you take and everything is solved."  True, but this should be a safe statement about any kind of technology - you get out of it what you put into it, and especially in the sophisticated realm of capital markets software systems.  Indeed, the longest pole in any CEP project is integration with the various OMS, EMS, middleware, and database components that often play a big role in any system.  Pragmatic understanding of what it takes to deploy CEP, in my book, is a good thing, and Marc's comments are a helpful reminder of the best practice to apply sound engineering practice, especially when it comes to a relatively new technology like CEP.

I've spoken with Ivy numerous times over the year, and she has always written thoughtful articles, so I'd guess she would respect this rebuttal - frankly, I think the content of this article argues the opposite conclusion - that CEP is robust and maturing and reliable, not "immature."

May 21, 2008

Perspective on Today's Vhayu / StreamBase Partnership

Today our press release hit the wire describing a partnership with Vhayu.   Here's the link to the release on the Vhayu web site:

Vhayu and StreamBase Partner to Provide Real-Time and Historical Market Data Solutions for Hedge Funds and Investment Banks

There was significant press coverage of this release, I think for two reasons.  First, partnerships like these are often "Barney" relationships - as in, vendors who issue press releases that essentially say:  "I love you, you love me, we're a happy family" (if you don't have kids or don't know Barney, check out his famous song here.)  This isn't a Barney release;  this is a partnership driven by shared customer need.

The second reason this release is significant, and most importantly, is the why it's important to our customers.  Customers in capital markets care because they must "apply better analytics on shorter timescales." (quoting the press release).   Specifically, Vhayu provides the ability to back-test strategies before they are put into the live market, and identify new strategies, and evolve the intelligence of their proprietary trading, compliance, and risk techniques;  StreamBase allows developers to compose, deploy, test, debug, and evolve those strategies on streaming data.   Increasingly, the cycle time for the discovery, development, deployment, and evolution of CEP-based automation is THE basis for competition among firms as they race to be the first, smartest mover in the increasingly electronic markets.  Firms that employ both historical tick stores and CEP get to market  quickly, and stay ahead by continuously "genetically tuning" their techniques.

Partnership activity is a sign of a healthy, growing CEP market, so it's good news for everyone.

May 18, 2008

Event Processing in the FT Misses the Action

Over the past few years, there has been a noticeable increase in awareness of event processing. This week the Financial Times (FT), one of the most widely read papers in the world, did a nice article on event processing called Event processing: A monitor that can set alarms ringing, quoting StreamBase and our friends at Apama. Algorithmic trading, real-time P&L, and real-time logistics systems done at Dell Computer were all cited as examples of applications that benefit from CEP today.

The article was great, but one flaw jumped out to me, probably due to the nature of the Dell Computer case study cited - the fact that these applications are simply monitoring for changes in event streams. In my first month of travel talking to StreamBase customers, I'm finding the same kind of applications that we had with Apama that do much more than simply monitor streaming data and firing off advisory signals to humans.

It is true that many of the patterns detected by a CEP engine are used as decision-support - to inform a human. Real-time decision support is an important business requirement in most CEP applications. But, at the same time, CEP can automate action that might not even be possible if left to manual intervention. For example, last week I met with a hedge fund who uses CEP monitor a firm's intraday P&L. The system monitors trading activity during the day. When P&L moves too quickly toward its internal limits, the system alerts the head of the trading desk. This is the decision support element of the system. But, at the same time, StreamBase rules can automate action, depending on the nature of the risk. For example, orders above a given size (specified by data that drives the CEP rules) can have their order state automatically altered by the CEP rules so that they can be reviewed by the head of desk. In this way, decisions can be "automated," yet guided by, human decision-making. Small orders, that wouldn't significantly change the position of the firm, and that would be distracting and time consuming to dequeue, are allowed to go through.

And, other "automated actions" include the spawning of new rules based on changing conditions. For example, when risk profiles change suddenly, the system spawns a new rule based on that can evaluate individual order books that are contributing the most to the change. This kind of chained rules - rules that trigger other rules, and maintain complex state, are often the central reason the industry still calls forms of event processing "complex" - it's the ability to identify rich, complex patterns of events that makes the technology so powerful.

I was on a panel this week at the DWT show in London where one of the participants claimed that "robotraders" were making traders obsolete. I have seen no evidence of this. Sure, there are less traders than there were 5 years ago - much of what used to be done manually is now automated. But almost every CEP decision making system is a textured one - some elements of decision making are automated, some are completely left to humans, and some are guided by data and rules - rules that are altered and improved as business conditions change over time.

Applications that do more than just monitor and filter streams unlock the deeper business value in event processing technology: by helping automate intelligent action they can help firms seize opportunity and avert risk before it's too late.

April 30, 2008

The Subprime Crisis and Real-Time P&L

In the past few weeks I've been in New York and London, visiting investment firms who use complex event processing (CEP) technology in their trading operations - before one visit, I was surprised to be briefed that the technical team we were visiting had built a "real time P&L" system. I was surprised because P&L management always seemed to be a very basic element of every algorithmic trading system I've worked on in the past.

Last year, John Bates and I wrote in the Trade about how the electronification and rise of algorithmic trading and regulation were starting to "push the front and back office closer together." At the time we were thinking specifically about compliance, although TCA, best execution, and risk are clearly inter-related when it comes to electronic trading. P&L was one of the functions we saw then starting to creep into the front office function of trading, often in the form of pre-trade TCA which was being used as part of algorithmic execution strategies.

So to find real time P&L as a common stand alone function was a bit of a surprise to me, but in talking to the firms deploying it, it became clear that there's another force at play: the sub-prime crisis. Billions have been lost inside of a day - it's not longer acceptable to wait to the end of the day to gain insight into the firms' trading position, when it may be too late.

CEP uniquely enables real-time P&L. Because an event processing platform can ingest or output any event stream, a firm can add their own feeds, their currencies, their own price roll-ups or their own netting options. Since CEP languages like StreamSQL are open and extensible, developers can change their P&L valuation algorithms with multiple rule sets for each instrument or book, or change the alert thresholds. Indeed any P&L rule or configuration definition can be amended and maintained by the investment firm. And, event processing rule filters can be cascaded so that output signals can be used in subsequent cycles to change the P&L calculation depending on earlier market dynamics.

From an IT perspective, the ability to change parameters or even to add new rules during real time operations provides for a deeper level of flexibility and dynamism. For example, a news flow item might trigger volatility requiring a different analysis, or a sudden loss of profit may demand a more granular analysis to track down the problem. The ability to alter and deploy rules during the day allows firms to adjust how they formulate their real-time view of the market.

So it's becoming clearer why real-time P&L and event processing are being more strongly linked: the simultaneous need for intraday insight, combined with the continued maturity of event processing platforms that can implement it in an open, flexible, and dynamic way.

April 26, 2008

CEP: It's Not Just About Algorithmic Trading

Being at Apama for so many years, I was fortunate to learn about the applications being built with Complex Event Processing (CEP) technology. The academic or deep technical issues of CEP, although fascinating, are well covered by others - I was more interested in the business value of CEP. That is, when a business person considers buying paying money for this technology, how do we answer the question: "Yes my techies tell me CEP is neat and new, but - so what? How will it impact my business?" So naturally, now that I'm with StreamBase, my first order of business is to get back on the road and see what's new through the eyes of a very different product and company. I'm looking to answer the "so what" question from a fresh perspective.

Apama is very public and open about its adoption for algorithmic trading. (Disclosure: my comments about Apama are restricted to public information, given my direct involvement in running the company). Indeed, algorithmic trading was so dominant a use of Apama that some wondered if algorithmic trading was the only application of CEP. And the deep customization of Apama as an algorithmic trading solution only emboldened this perception: of the 150+ articles, blog posts, etc. I did as general manager of Apama, roughly 95% of them were about algorithmic trading.

But looking through the eyes of StreamBase customers, for me, has shed a new light on the business question of "so what?" It's already been a fascinating look into the broad application of CEP. Naturally capital markets has adopted StreamBase aggressively; but what's new and different is the wide variety of use cases, far beyond algorithmic trading. Crossing engines, real time P&L, smart order routing, more generic, supporting applications in the trading space like trade signaling, alerting, and monitoring. Market data cleansing and optimization. And, since StreamBase has historically been a horizontal, general purpose platform, the applications outside capital markets in the government space, such as intelligence and defense applications, are fascinating as well. More on these specific use cases in the future.

On the other hand, one thing has remained consistent: the core value proposition, or answer to "so what?" It's never been about "feeds and speeds"; speed and scalability are just table stakes for mission critical applications. The core value of CEP is that it empowers business users. Graphical tools allow a business analyst, or even a pure business person, to quickly express their "secret sauce" - their knowledge of how they might best react and capitalize on changing business conditions. CEP empowers business users to make better decisions, more quickly than ever before. More quickly than their competition. More intelligently than the next guy.

I'm seeing customers quickly imagine, express, test, deploy, and evolve their most innovative ideas, ideas that can help them better understand and react to what's happening now, while the opportunity to seize the advantage still exists. That's an important answer to the question: "so what?" And I'm finding it's an answer any business person can appreciate.