« EDA - "Slow" Adoption or "Rapid" Adoption? | Main | AITE Group Report on CEP »

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.

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d83452154069e200d8346bc8b469e2

Listed below are links to weblogs that reference Is EDA, or SOA, Closer to the Business?:

» The value of events from Todd Biske: Outside the Box
Joe McKendrick quoted a previous blog entry of mine, but he prefaced my quotes with the statement that I was questioning the value of EDA to many businesses. One of things that any speaker/author has to always deal with is the chance tha... [Read More]

Comments

Todd Biske

Thanks for posting about some of the verticals that have adopted your products. Just as SOA gained momentum as case studies started to appear, EDA and CEP will do the same. Hopefully, some of your customers will agree to have their positive experiences with CEP published.

Dennis Howlett

Check out soafacts.com - it's a good riff on SOA. This is an interesting argument but the proof is in the eating so what we need to see are use cases that not only point up the benefits but also show how EDA can bring fast value. The cartoon you guys did (funny but not as funny as Greg the SOA Architect on YT) implies near instant results. Great. But how much work has to be done to get there. Quick wins have not been SOAs strong point. Perhaps EDA solutions of the kind you describe are the antidote?

Progress Apama

Yes, fair enough, Dennis. We'll definately follow up on this post and the issue of making EDA simple to deploy. That said, the simplicity of deployment is not a general attribute of EDA, it's a attribute of the event processing tool set that allows event driven applications to be created. Not all vendor approaches are equivalent. Naturally I can best cite our own tools. Specifically, Apama's Scenario Modeller and Dashboard studio are designed for business analysts (e.g., traders), not IT developers. Additionally, our graphical Eclipse environment is designed for IT users. By targeting specific tools at both ends of the spectrum, you achieve rapid EDA.

We'll follow up in some depth on how all of this works, but I think I'll leave it to one of our customers, and quote from a recent public press release from the head of equities trading at Finamex, an Apama customer, who said:

Carlos Ramirez Cervera, head of ETS, Finamex, comments: "As the Mexican market begins to take up algorithmic trading, buy-side clients are looking for flexible, customized services that will bring them an advantage. The comprehensive Apama platform and Event Modeler and Dashboard Studio rapid application development tools allow us to rapidly deploy innovative algorithms that meet our customers' individual needs in hours or days, rather than months or years that would be required with alternative approaches."

Let me assure you, people like Carlos don't put their name on this kind of public quote without a lot of thought. We'll follow up with more examples and details in future posts.

Jack van Hoof

I recognize a huge business potential of asynchronous, event oriented design. And I believe that EDA by its nature will be the paradigm to realize the ultimate alignment of business processes and the supporting IT-systems. I think that the ultimate layer between our real world events and artificial application constructs will be an EDA. And I recognize the possibilities offered by the current IT-technology evolutions to support this paradigm.

http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html

Bulk SMS

The most essential thing about your post is the introduction you have provided here. We do understand that it is a serious topic & having an insight into the subject matter is really enriching. You have provided an unbiased opinion which reflects your personality.

Francis

I appreciate your honest post here on . As hard as it is to believe, it is possible you overlooked the few things in question. It would appear it has become a little out of hand with a so much of information to manage about . As a experienced person of nearly 15 years, i must say i totally agree with you on .

Francis

I appreciate your honest post here on . As hard as it is to believe, it is possible you overlooked the few things in question. It would appear it has become a little out of hand with a so much of information to manage about . As a experienced person of nearly 15 years, i must say i totally agree with you on .

The comments to this entry are closed.

<-- end entry-individual -->