Event Processing blog

Rendering Unto Caesar - The Role of the Business User in CEP

"Render unto Caesar the things which are Caesar's
and unto God the things that are God's"

A recent posting in the Enterprise Decision Management Blog entitled "Can we trust business users" addresses a topic that seems equally pertinent to the CEP market. I think there is a tendency to become so enamored with the technical virtuosity of new technology that we may lose sight of who the real users are. In terms of the development of CEP applications, an understanding of the prospective roles of business users vs. that of IT developers seems to be an evolving thing. Apama has long been a proponent of the participation of the business user in the process of building CEP-driven applications. In Capital Markets, the notion of "empowering the trader" has been a key element of our strategy and the Apama product offers a graphical development tool, Event Modeler, that focuses on that constituency. We have another RAD tool that is intended for developers who can create applications in our event processing language, as well.

We are beginning to see third party validation of the value of this approach from outside of Capital Markets, as well. For example, a report from Forrester Research published earlier this year indicated that early adopters of CEP have tended to come from the line of business rather than IT because "developers and architects often know painfully little about these [non-traditional, non-IT] events and how they are used to run a business." That Forrester quote is certainly not intended to diss IT. It just recognizes that there are lots of different kinds of events that are important to a business and not all those events are traditional IT-aware or IT-generated events. In order to make sense and respond to such events, it seems quite logical that providing tools that are amenable to a more "business" oriented audience is important.

But I would argue that it is not just the nature of events - and their varied sources - that suggests a strong correlation between CEP and business users. It is also the nature of the CEP-driven applications themselves. CEP applications are not "one and done", they tend to be iterative and evolving, because they are crafted to respond to what is happening and what is happening is often a frequently changing set of conditions. Or, if the conditions are not changing, how you choose to respond to them may be changing. So you need to continually calibrate and revise.

In another Forrester report published earlier this year, this characteristic was noted within the context of a review of Business Activity Monitoring best practices. Event-driven BAM is a particularly strong use case for CEP and the report stated that BAM efforts "are typically never-ending projects" with a "high degree of change." That makes sense since BAM monitors 'business activities' and the nature of most businesses will change over time. So to support BAM applications, it seems perfectly logical to provide tools for business users who can take on some role in the initial development and ongoing operational calibration of these applications. There is clearly an important role for developers in building these applications – no one would suggest otherwise, but we best not forget what the “B” in BAM refers to.

What seems to be emerging is the notion that we are should not look at CEP and/or BAM deployments as discrete, finite projects with clearly prescribed end dates. They are continuously iterative projects that must evolve to remain effective. That’s the environment in which they operate. Given that, perhaps we should not see the roles of business users and IT as fitting within well prescribed boundaries. The development and ongoing management of these applications will have evolving roles for the line of business user and for IT over time. We might expect IT-centric development to have a more dominant role in the initial deployment, but over time the goal might be to have the line-of-business assume greater and greater roles - because the business will be the dominant user and best positioned to react to changing circumstances.

Perhaps the EDM blog posting says it best, though it expresses it within a "business rules" context. “Too many rules specialists focus on rules that will get executed and not enough on the people that will maintain those rules, although this is where the success of the project resides.” That is quite the same for CEP and BAM. There is a role for business users, driven by the nature of events and the continuously evolving nature of the applications that are “event-driven.” And it is incumbent on the technology provider to offer tools that will facilitate that evolution. All the CEP performance in the world will be of little use, unless that performance is well-aligned with the needs of the business.

So we might debate who is the metaphorical Caesar and who is God in CEP development, but the success may well rest on giving each their due.

SIFMA Retrospective

As a follow-up to my colleague Louis' report on last week's SIFMA show, I thought I'd add some thoughts of my own. My conclusion is that it was the most exciting SIFMA show I have experienced.  While I think attendance was down from previous years, I also think the quality of attendees was up. And for me personally, the excitement of being involved in some industry-moving announcements as well as meeting up with many of my colleagues from capital markets firms, vendors, press and analysts was highly invigorating.

So what were the highlights and take-aways for me?

1. CEP is clearly a theme that is getting a lot of mindshare. So many people said that CEP was a key theme of the show – which is great to hear after many years of working to help define the market. It’s also great to see this add to the momentum so soon after the Event Processing Technical Society was launched. The use cases of CEP are many and varied – and there was a lot of interest and questions around this at SIFMA. We demonstrated on our SIFMA booth 5 different CEP use cases on 5 different pods - algorithmic trading, smart order routing, managing FX market fragmentation, market surveillance and real-time bond pricing. Also the demands of CEP applications continue to make demands on the technology, and we were thrilled to demonstrate Apama 4.0 – which extends performance and user experience of CEP to new levels. Another supporting factor in the maturing of CEP is that there are starting to be very senior people in Capital Markets firms focusing on CEP as an enabling technology. Marc Adler from Citigroup   is a key example. He’s active in the community and on the STAC CEP committee, helping to define benchmarks. It was great to meet Marc at SIFMA and also to catch up with many  other esteemed colleagues from the CEP space.

2. The liquidity wars are hotting up. It was our pleasure to be involved in a press release with NYSE-Euronext which was certainly one of the big releases of the conference. Progress Apama will be hosted in the NYSE Euronext as part of the exchange's Advanced Trading Solutions offering. Traders will be able to download custom logic for algorithmic trading, risk management and smart order routing into the NYSE itself - with low latency connectivity to other trading venues via Wombat and Transact Tools. This arrangement turns NYSE into a technology provider as well as a one-stop-shop liquidity provider. This announcement was picked up by major press, including the Financial Times - in Europe, America and Asia -- see the article here.

3. Hardware is important – and so is “green”. The increase of capital markets data volumes require completely new software architectures – like CEP. But software is not always enough to support the low latency transport , processing and storage requirements. Many firms are turning to specialized hardware, combined with software – to create high performance solutions. Vhayu, for example, launched Squeezer – which combines hardware and software to supercharge their tick data offering. Also, Progress Apama were pleased to put out a joint announcement with Sun on a collaboration for end-to-end CEP solutions – combining Sun hardware and operating systems with Apama’s CEP platform and solutions. We demonstrated an end-to-end bond pricing application using the whole stack. Sun was one of the vendors who have a “green” aspect to their hardware – for example on a major CEP deployment, the hardware can be scoped for peak throughput – but can selectively shut down capacity to save power when event throughput is reduced. In this era of high energy costs and global warming there seems to be a lot of interest in this approach.

4. I love partying on the trading floor. Progress Apama were honored to be invited to a party at the NYSE to celebrate the latest developments at NYSE-Euronext (see picture at the top). It was a great pleasure to speak with our friends at NYSE-Euronext and to meet many of our old friends from the capital markets industry there – while sipping some delicious wine in that amazing place. In a way it is a shame that electronic trading is making the traditional trading floor a thing of the past – but there is something amazing about that place and I hope it stays just the way it is – even if it becomes a cool venue for other purposes. Thanks to NYSE-Euronext for inviting us – we had a great time.

I’m sure I’ve neglected a load of other trends and themes – but there’s my brain dump for the day. I’m interested to hear if you all agree.

John

Asia Report: Fighting White Collar Crime

Hello from Hong Kong. As always it is fascinating to see how CEP is evolving in Asia. One trend I am observing is the huge interest in Hong Kong in rogue traders and white collar crime – and how CEP can be used to detect and prevent this – before it moves the market. Obviously the original rogue trader, Nick Leeson, is well known here. But there has been a great deal of interest in more recent goings-on, at firms such as SocGen. Amazingly, until a couple of years ago, insider trading was not illegal in Hong Kong! Now we have a highly volatile market, with a lot of uncertainty, huge event volumes and a real problem of seeking out and preventing rogue trading activities, as well as managing risk exposure proactively.

Of course CEP provides a compelling approach. In market surveillance - the ability to monitor-analyze and act on complex patterns that indicate potential market abuse or potential dangerous risk exposure can allow a regulator, trading venue or bank to act instantly. Banks want the reassurance that they are policing their own systems. Regulators need to protect the public. The media and public here find this fascinating.

On the topic of a different kind of white collar crime – consider using CEP to detect abuse in the gaming industry. The gambling phenomenon that has propelled Macau to overtake Las Vegas as the world’s biggest gambling hub is also an exciting opportunity for CEP. We have customers using CEP to monitor and detect various forms of potential abuse in casinos. Events that are analyzed to find these patterns include gamblers and dealers signing on at tables, wins and losses, cards being dealt etc. It is possible to detect a range of potential illegal activities, ranging from dealer-gambler collusion to card counting.

As a final thought - having met with some of our customers that operate both in Hong Kong and mainland China, it is clear that China is a massive market opportunity for CEP. Exciting times ahead for CEP in Asia.

CEP down under

I’m sitting here at Melbourne Airport in Australia on my way to Hong Kong. I’ve been delayed by a typhoon – probably a good reason to delay. After a very successful week in Sydney and Melbourne visiting customers, I thought I’d report that the CEP market is hotting up down under! As you would expect financial services is an early adopter and Apama has had several customers in Australia in this space for a few years now. But the demand is increasing. This is driven by factors such as increasing competitive pressures in the trading space and the impending fragmentation of the Australian market. Just like in Europe and North America, it is likely that several new trading venues will join the Australian Stock Exchange in offering liquidity in Australia. My diagram shows some of these in the form of Chi-X, AXE and Liquidnet.

Complex Event Processing offers a powerful way of monitoring, aggregating and analyzing the liquidity across all of these markets, as well as making real-time routing decisions. This of course can work in parallel with traders and algorithms. In fact it is becoming very interesting to see trading decision algorithms routing messages to execution algorithms, routing messages to liquidity tracking algorithms, routing trades to the market, which are being checked by market surveillance algorithms -- and all part being implemented in CEP. I am biased of course, but what other technology can offer the seamless federation of such systems. Events provide a powerful and low latency mechanism for such interoperation. Each component can be built independent of the other - but yet they can work together seamlessly. But I am getting off topic!

Over the last few years Australia has mainly been interested in equities algorithms, but now the interest in FX, futures, bonds and commodities is growing. While I was in Sydney, I was pleased to deliver the keynote address at the Trading Technology conference and met many interesting sellside and buyside participants with a variety of trading interests. It was fascinating to see how the market is developing.

And it is not just financial services where CEP is being applied down under. I also met with organizations in a number of other spaces including travel, transportation and location-based services. I hope to report more on these in the near future.

And now I look forward to finding out what is happening in Hong Kong and Asia beyond. Hopefully I can avoid the typhoon!

John

Apama and Sonic Win Technology Innovation Awards

Progress products have won two "Leaders in Innovation" technology awards in wholesale transaction banking by Financial-i magazine Financial-i.  As judged by a panel of industry experts, Apama  won the award for CEP products and our fellow Progress product, Sonic, won for  Enterprise Service Bus.  Financial-i notes that the awards are for technology leadership demonstrated over the last 12 months, which the magazine judges to be "an ongoing commitment to innovation....built on previous innovations to stay ahead of their competitors." 

Understanding Event Driven Architecture by Schulte / Chandy

Roy Schulte and Dr. Mani Chandy got together on this nice article on CEP and EDA, called Understanding Event Driven Architecture.  It succinctly describes complex event processing, event driven architecture, and business activity monitoring, three topics we're primarily concerned with in this blog.   

One of the sections of the article that I think is important and relatively new is their breakdown of "pull-based" versus "push-based" applications as one of the distinguishing characteristics of event processing applications versus more traditional applications.

The conclusion of this article provides a concise summary:

"EDA is under-utilized because architects, software engineers and business analysts   sometimes fall back on the familiar pull and scheduled models as a matter of   habit. This results in business processes that are slower and less responsive   than they should be. Businesses need to make more of their processes event-driven.   The push concept and the desirability of running some business processes straight-through   are not difficult to grasp and they are being used more frequently as business   pressures grow and as developers get more comfortable with using EDA. Some parts   of all new business systems should use EDA, while other parts should still use   pull and scheduled patterns. The key is to understand the advantages of each."

Read the entire article at the source here:  Understanding Event Driven Architecture

Why use SQL?

SQL is certainly one of the successes of the computing industry. It all started with the much cited and seminal paper of Codd in 1970 which first described the relational model. Over the next few years and after efforts by both IBM and Relational Software (which later became Oracle Corp) SQL was launched into the commercial domain in the late 1970s. Standardisation then followed in the mid-1980s and further support for more modern trends such as XML added more recently. Database management systems now have matured into highly sophisticated environments for the storage, manipulation and retrieval of enterprise information. SQL is the standard language of use in the database world. Attempts to move this on and break with the Codd paradigm, such as the move towards object oriented databases in the 80s and 90s have, apart from in niche areas, failed.

We now see a trend by a number of event processing vendors to represent SQL as the language of choice for building CEP applications. For example, Streambase, Coral8 and now BEA. Why is this? Well, Streambase is simple to explain. Michael Stonebraker is one of the key forces behind Streambase and his background in the database industry is second to none. He was involved in Ingres in the 1970s and also behind some of the work integrating object-oriented principles with relational databases with Illustra in the 1990s. Databases, and therefore SQL, is part of Streambase’s DNA. In comparison, BEA’s use of SQL is harder to understand. BEA’s business is built (still) upon their application server technology and they are strongly going to market with an enterprise integration offering – Aqualogic. Databases haven’t really formed part of BEA’s background. The use of Xquery would have been more obvious.

Perhaps these vendors have concluded rightly that SQL is actually the right way of doing things in an event processing world. I don’t believe it is. It’s certainly a way, but it’s not the best. I believe it can confuse people as to what event processing is all about and can serve to inhibit adoption. SQL is certainly well understood, but by providing an SQL interface to event processing products, practitioners assume that an SQL way of thinking will be appropriate. It isn’t. By thinking of event processing as actually a real-time database you get stuck in a database-centric design pattern.

When John Bates and I were doing some of the academic research which resulted in the formation of Apama in 1999, we were looking at how to support effectively applications which were powered by high-volume streams of data – stock tick analysis, location-aware telco applications and others. We looked at using database technologies to support this, but had to rip the work up. Not only did these technologies not perform, we realised we were force fitting one paradigm into another. Taking a clean sheet of paper we came up with the beginnings of a much more elegant, performant architecture. It was data, not query driven. The use of SQL to be a language interface to this just didn’t seem to be appropriate.

It seems that others agree. I was at a conference at CITT in Germany recently where CEP formed a major topic of discussion. In particular we talked about some of the challenges of using SQL to build event processing applications underpinned by practical implementations of use cases using a variety of event processing technologies. What became apparent was that the SQL approaches appeared to hinder, not help, the developer. The baggage that SQL brought made it difficult for people to get their heads around the thinking required to implement event processing use cases. The resulting SQL was clunky and difficult to follow.

So, am I going to conclude by saying that SQL should be shunned? Well no, I’m not. As a vendor, Progress Software is all too well aware that its products exist only to help organisations solve their business problems. Partly this is allowing problems to be solved that could not be solved previously. Partly, this is also to enable productive development. Giving a choice of a development environment with which many technologists are familiar is important and SQL can provide some of this familiarity. We therefore are observing and listening closely to the opinion of the wider market and to our prospects and customers. SQL may be one of the ways in which organisations should be able to interact with an event processing system.

However I maintain that it is certainly not the best choice, nor should it be the only one.

BAM Myth #2: SAM = BAM

Some CIOs feel that they have tried and failed with BAM by aggregating business views their technical components or alerts. Unfortunately, software vendors aggravate this myth because they sell their old network system management (NSM) tools as “business activity monitoring.” The problem is, it’s not easy to put a system monitor on the IT infrastructure and gain business insight from technical activity. That’s not business activity monitoring; it’s system activity monitoring. It’s not BAM, it’s SAM.

Without tools that help apply business context to technical events, SAM tools are IT operations tools. SAM tools are important, but only show that computers are working, or anticipate hardware failures (unexpected volume of data, wrong data processed, concurrent events that together are causing a business loss).

But just because the hardware is working, how do you know that your business is running well? Without the language of business built on top of system monitoring, you’re not doing BAM. BAM development tools help business users express their business commitments in business terms, taking into account technical alerts, transactions and customer behavior. They help a business user express key performance indicators (KPIs) that express SLAs with customers, key business metrics to track, and quality indicators like availability, response time, and error rates.

Complex Event Processing (CEP) is the language of BAM. CEP helps the business users simply express questions such as: are we ready to take actions? Are my service levels met now and are they trending towards non compliance? What actions could I take now to change that trend? Will I meet my deadline?

CEP provides a common language between IT and the business user, and allows business departments and technology business processes to interact – BAM and SAM – working together to provide more agility and faster problem resolution.

Welcome BEA. Seriously (explained).

My last post "Welcome, BEA.  Seriously." has drawn both chuckles, and blank looks.  I realized that the blank looks were because the source of the "joke" is pretty old.  This post was modeled after the welcome letter / ad campaign from Apple, directed at IBM when IBM entered the personal computer race at the same time Apple launched the Macintosh.   Apple ran the ad, at left, in full-page newspaper glory.  Posting a spoof of this ad in a blog is not quite so bold, but it was fun.

We don't know much about BEA's CEP product yet - it's still in beta.  They cite algorithmic trading as a use case, yet we've never heard of them in this space, and as well documented in this blog, capital markets is mature in its adoption of CEP.  BEA talks about innovation in optimizing garbage collection and performance in Java, and we're interested to hear about their approach (Apama has had a CEP Java interface for some time now).  We're also interested to hear about how the app server approach will scale and be open to support today's heterogeneous IT landscape, something most of the pure-play CEP engines focus on.  Their entry also poses some interesting questions about standards, as we've discussed in the past here, and the role of Java in those standardization talks.

So, seriously, welcome to BEA, and we look forward to getting a little deeper into the new CEP product on the block in the coming months and years.

Welcome, BEA. Seriously.

Welcome to the most exciting software marketplace - complex event processing (CEP) - since application servers in the late 1990's, about 12 years ago.

And congratulations on your first CEP product.

Putting real programming power in the hands of the business users is already improving the way people imagine, compose, develop, back test, and deploy event-driven applications today.

CEP is fast becoming as fundamental a computing model as client / server.

When we were among the first to invent the first CEP engine in the late 90's we estimated that most applications in the world would eventually be developed this way, if only they understood the benefits.

CEP has already become an established mainstay in applications in the capital markets, fraud detection, and RFID-enabled supply chains.  Over the next decade, the growth of CEP will continue in logarithmic leaps.

We look forward to responsible competition in the massive effort to distribute this technology to the world.  And we appreciate your magnitude of commitment.

Because what we are doing is providing an innovative way of developing applications that can monitor, analyze, and act on flowing event data, as opposed to the traditional, static computing model that an application server typically supports.

Welcome to the task.