Main | March 2007 »

February 2007

Wednesday, February 28, 2007

Is EDA, or SOA, Closer to the Business?

Posted by Progress Apama

It's hard to keep track of this conversation on EDA and SOA!  Todd Biske's comments on The Uptake of CEP, Joe McKendrick on ZDNet on "Is EDA the 'new' SOA," and Joe again on "Making SOA More Eventful" all raise some provocative viewpoints.   All very bullish on event processing,  but at the heart of the debate is the question of will EDA be harder or easier for the business to understand, and therefore justify spending for.

A comment Todd struck at the heart of that issue.  He said:

"My opinion is that EDA is a bigger stretch than SOA, because it doesn't relate as directly to how the business thinks, therefore, it will take longer for them to understand the benefits and invest in it."

From my perspective (full disclosure:  I'm the general manager of the Progress Apama event processing business, and also was involved in leading IONA's enterprise service bus product called Artix), event driven applications, and therefore event driven architecture, are much more closely aligned with the business than SOA.

Why?  The most advanced event processing platforms have been designed for business users, business analysts, AND IT.  The dashboards are used by all levels of an organization, from the CEO to business line leaders to IT.  The development tools are used by domain experts, not professional developers.  This bring event processing, and EDA, directly in the front line of the business.

There's little debate that Apama is the leading event processing vendor right now.  Yet we haven't been very vocal about EDA, because we tend to build applications with business users and IT, driven by the business.  Many of the top firms in the capital markets, including Deutsche Bank, ABN, JP Morgan, Finamex, the Korean Stock Exchange, and smaller buy side firms like HG Trading and Aspect Capital, all use EDA for their trading operations, and those are just the ones that are public about it.  But beyond capital markets we have telecom customers, military, casinos, fraud detection, compliance, logistics, and manufacturing applications.  A case in point outside of finance is BGN, a Holland-based bookseller, has deployed Apama to automate their supply chain and retail operations.  Very event driven.  Very close to the business.  We had the CEO of BGN in Boston last month presenting to over 50 of the top industry analysts, talking about the EDA and how it impacts his business.  And the managing director of HG trading. 

These people aren't "close" to the business - they ARE the business.

IT is an important partner, but the reality is that 100% of our projects have direct involvement, sponsorship, and, indeed, participation, by the business side. Specifically, as you'll see with the CEP development tools featured in Progress Apama, we support all three key contributors: business users (dashboards, used by, for example, line of business heads or head of trading desk of operations manager), business analysts (e.g., trading strategists, fraud experts), and IT (Eclipse environment for low-level coding). Business and business analysts think and develop the Apama-based systems in terms of business logic; IT thinks in terms of EDA. It's a powerful model that bridges IT all the way to the business.

SOA tools, by contrast, tend to be designed exclusively for IT architects and developers who are deep in the heart of the IT infrastructure. That's certainly the way it was for us with Artix, and it's very much the design center for Sonic Software's ESB, which is well known as the first and leading ESB (full disclosure:  Sonic is a sister division of ours at Progress Software).  That's not bad, it just that SOA tends to be a technology that optimizes and integrates IT assets. I think this is actually why the Forrester numbers are so misleading, because there still is a ton of work left to go before SOA even scratches at the fullness of its vision and hype.

So, coming from the personal perspective of building both EDA and SOA tools, I know for a fact that EDA environments are designed to be much closer to the business user.

Tuesday, February 27, 2007

EDA - "Slow" Adoption or "Rapid" Adoption?

Posted by Progress Apama

I don't understand how industry observers and analysts get away with claims like "EDA adoption will be slow" without substantiating what slow means, such as this article by Todd Biske.  Not that wild growth rate projections are useful either, but it seems that if you're say something will happen "slowly" or "quickly," that there should be some numbers associated with that claim that can be used to judge or measure.  First of all, it would be interesting to cite how many applications are actually service oriented today.  Aberdeen recently issued a report that said that 9 of 10 (90%!) of companies are using SOA.  These numbers seem specious, having been at IONA for years in CORBA, one of the first SOA companies, my guess is that Aberdeen asked, for example, Citigroup if they are using SOA.  If they said yes, they counted Citigroup, one of the biggest firms in the world, as having "adopted" SOA.  Anyone have a good idea of this?

But this blog is about EDA and complex event processing, not SOA.  I wonder what folks think "slow" and "rapid" adoption actually means?  SOA adoption started over 10 years ago, so would EDA be successful if it reached 1% adoption?  10%?  20%?  50%?   And who measures?  Hopefully not Aberdeen, who lost credibility to claim that SOA adoption is 90%.  And since event driven architecture and CEP is quite new, what kind of time duration is appropriate?  What would constitute “rapid” adoption?

It seems that a market growing at over 100% a year, with heavy adoption in financial services, like CEP, isn't something to call a "slow" moving market.   Clearly the percentage of applications using it is still low, but isn't that why it's such an exciting, new market?

Is EDA the "new" SOA?

Posted by Progress Apama

This article (Is EDA the ‘new’ SOA? by ZDNet's Joe McKendrick) was published this week, and is a response to the article EDA + CEP:  A New Physics of Computing by Rich Seeley, which was the result of a discussion with Rich, John and I. 

The idea that complex event processing is a new physics of computing is a concept we have discussed for years with Apama.  The fundamental idea was captured by Rich when quoted John Bates:

Where in the traditional system the "data is static and the queries are dynamic," he said. "In event-based systems it's different. The rules that you're using to monitor the data and take action are fairly static, and it's the data that's dynamic. The data is continuously changing. So you have to structure your software to take into account that paradigm shift."

The article, and the idea behind it, seems to have touched a nerve about suggesting that EDA is "the next big thing."  True this is bold claim, and one that needs to be considered carefully.  But the fact is that CEP is a fundamentally different computing model, as John describes above.  It has a unique technical capability to identify patterns of events, and apply temporal, or spatial, constraints to streaming data, at tremendous scale and low latency.  No other technology has this capability, and it's why CEP is generating so much excitement.

And CEP's adoption in some classes of applications, like algorithmic trading, illustrates that CEP has proven it has a major role to play in enterprise IT architecture.  We're not making these claims based on pipe dreams and "what if" scenarios - CEP is proven:  ABN Amro, JP Morgan, Deutsche Bank, HG Trading, Koscom (Korean Stock Exchange), Finamex (In Mexico) all have been public about their application of CEP to algorithmic trading, and, when that many large firms are public about their use of a particular type of software, you know that it's just the tip of the iceberg.   Even Microsoft has selected Apama as part of their MiFID solution suite, illustrating yet another use case for the technology.

As for IT architecture, the distinction between EDA and SOA is still fuzzy.  SOA is designed to support an event-driven interaction between services, but says nothing about how to process those events - that's what CEP does.  As a case in point, algorithmic trading systems are event driven.  Many of algo trading applications don't use SOA;  some do.   Therefore CEP is agnostic to the presence of SOA, although, if it's in place, great. 

Does that mean EDA will "replace" SOA?  Certainly not. 

Does it mean EDA and SOA are complementary?  Yes. 

Does it mean that EDA is an "advanced" form of SOA?  I don't think so.

As for the size of this market, we'll leave declarations of "the next big thing" to the analysts that can do some sizing and crystal-ball gazing.  They are starting to talk that way, which is flattering.  But for now, the job at hand is to continue to identify and solve real problems with CEP that are difficult to solve without CEP, and then educate the market about those applications, which is one reason we're starting to blog.  The big issue is how many applications out there really NEED CEP, and how many are just fine using traditional database oriented approaches.  From our perspective, there are a ton of applications using Apama for CEP, and, if our growth rate continue, the market will be very big.  If the market becomes big, than we're happy.  If it doesn't become big, we're still having fun.  Stay tuned.

Algorithmic Trading Cartoon: "Dr. Whitebox to the Rescue"

Posted by Progress Apama

WhiteboxTime for some CEP fun today.  This cartoon: "Dr. Whitebox to the Rescue"  tells the complex event processing / CEP and business activity monitoring (BAM) story in a hopefully humorous way.  The hero in the cartoon is none other than Doctor "Whitebox" Bates, who is the superhero alter ego of Apama's founder and CTO, Dr. John Bates.  Hope you find this fun, we had fun making it.

Monday, February 26, 2007

The 10 Imperatives of Algorithmic Trading

Posted by Leanne Brown

This week Australian Finance & Capital Markets magazine has published an article written by Dr John Bates Founder and Vice President, and Mark Palmer, General Manager and Vice President, Apama Products, Progress Software.

The article, The 10 Imperatives of Next-Generation Algorithmic Trading, explores how algorithmic trading has moved beyond the ‘early adopter’ phase and addresses how innovative firms are identifying ways to get ahead of their competition by utilizing algorithmic trading.  The authors go on to outline the ten imperatives of today’s algorithmic trading market.

Download the article now

Saturday, February 24, 2007

Article on CEP in Manufacturing

Posted by Progress Apama

ApamaGood article in Manufacturing Computer Solutions by Brian Tinham, who I met this week in London. 

This was his take on things: Progress Apama, part of application infrastructure and database developer Progress Software, says its high end event correlation software has a significant role to play in bigger ticket manufacturing.

Its systems, which sample any form of data and can show event patterns and correlations at any level, have seen adoption in the financial services sector, but are now ready for use in production.

Bloor on Event Processing Moving Forward

Posted by Progress Apama

Bloor_researchPhilip Howard wrote this week on event processing market:  "Event processing moving forward." He has an update on the CEP language standardization process (in our opinion its pretty accurate), and discusses IBM, Oracle, and Microsoft and their potential entry in the market.

Friday, February 23, 2007

Kaskad Goes Live at Boston Stock Exchange

Posted by Progress Apama

Kaskad announced that their CESP product, Korrelera, has gone live at the Boston Stock Exchange (BSE).  This is good news for the event processing industry, an important use case, and, of course, a strong public endorsement for Kaskad, who launched their company in 2005.  The BSE system is a full exchange surveillance system for the BSE, and also monitors RegNMS monitoring system, which of course, is the analogous regulation in the U.S. to MiFID in Europe. 

Compliance in the capital markets is an important use of CEP; we have seen a lot of deployments in as well;  we announced our MiFID relationship with Microsoft last month.  No detail was revealed in the Kaskad press release, but we see CEP commonly applied to best price execution ("BestEX").  BestEx is an important piece of the regulation which mandates that firms demonstrate that they provided the best price available to clients for trade execution. 

Congratulations to Candyce Edelen, the president of Kaskad, who attended the CEP conference last year, and Colin Clark, their CTO, on this customer win and public endorsement. 

Thursday, February 22, 2007

TIBCO and Apama featured at GMAC in Japan

Posted by Progress Apama

This news was forwarded to me from our good friend Tim Bass at TIBCO, and reflects continued global interest in CEP, this time in Japan.  Tim will be speaking at GMAC in Japan next week - it's the GMAC Japan International Banking & Securities System Forum.   It's wonderful to see Tim featured here, talking about customer interaction management and fraud detection.  If you're in Japan definitely check him out he is a great spokesperson for the industry in general.   That said, you might be torn, because, as you can see, the Apama session about complex event processing (CEP) in Algorithmic trading is running in a parallel track, and there are only 2!   Whichever session you attend, go learn more about event processing!

CEP / Progress Apama Expands in Australia

Posted by Progress Apama

The global commercial expansion of complex event processing - CEP (in the case of Apama), continues.  Today's news from Progress is that we have expanded operations in Australia, naming a new country manager.  As you can see in that release, Apama is a major element of the Australian product portfolio; which is a significant statement considering that Progress is a $400M+ company, and Apama, still small relative to much of the rest of the corporation, is rapidly growing.  The past year we experience rapid global growth, including  OZ, and this is just one more reflection of that growth of Apama, and event processing.