Beth Gold-Bernstein:Welcome everyone and thanks for joining us. I hope you've found the sessions in the first virtual Event Processing conference informative and helpful. Once again, I'm Beth Gold-Bernstein, Chair of the Conference.

This session is a live panel discussion. You can submit your questions by clicking on the "Ask a Question" button. At the end of today, we will be giving away 5 copies of David Luckham's book, The Power of Events, an introduction to complex event processing and distributed enterprise systems. To win a copy of the book, ask a question. The books will be announced in the networking lounge before the end of the show today. I also want to remind you that to be eligible to win a GPS navigation system, you can visit all the booths. We will be announcing those winners at the end of day, as well. Also in the networking lounge, if you answer the question in the forum, we are giving away Starbucks gift cards, so, please visit that as well. Now, I'd like to introduce our panel today.

We have an esteemed panel featuring David Luckham, father of CEP and Professor Emeritus at Stanford University, Mani Chandy, Professor at CalTech and Rodney Morrison, Vice President of Products for SL Corporation. Welcome to you all.

Now Mani, can you please start the conversation off by giving us a definition of Event Driven Architecture? Is this something new?

Hear David Luckham Describe Event Processing (2:54) Rodney Morrison: Which Industries Are Adopting EP for Maximum Agility (4:24) K. Mani Chandy: How to Integrate Event Processing Into the Corporation (4:24) View a Full Replay of this Webinar -- Complete with Slides Find out more about our next ebizQ virtual conference: Process Management and the Bottom Line: Keynote presentation with Forrester's Ken Vollmer: The View From The Field – Is BPM Helping Companies Succeed? Keynote Presentation with Bruce Silver: Business-Empowered BPM Implementation: Good for Business... and IT Webinar with Dennis Byron and Global 360's Jim Sinur: How putting BPM at the top of the stack helps the bottom line Panel Discussion: BPM in the Enterprise with Aberdeen Group analyst Michael Dortch, BPMFocus CEO Derek Miers and Vitria CTO Dale Skeen

K. ManiChandy: Well, yes, and no. So, I should start off with what is an event. So an event is a significant change in the state of the enterprise or its environment. So with the environment and the enterprise, it's everything that impacts the enterprise and these days, environment is often the globe. So it includes the numeric information, textual information, images, everything that could impact the environment. So the event is any change in this environment or the enterprise that's significant and significance depends on what the enterprise is doing.

So, EDA is, in my view, the architecture for acquiring information that's relevant to the enterprise, sensing everything that's going on and detecting what is a significant state change of the event and then responding appropriately so that the whole cycle moves, detecting, analyzing and responding that is supported by EDA. There's this new, well no, in the sense that command and control systems by the military are EDA systems because they do that, they sense and respond to the environment, status systems are control have been around for a long time.

But what is new are two things: One is it has become ubiquitous for not just the military, it's everybody now. The local Southern California Edison where I live now has is building a EDA system and as it becomes ubiquitous, we see something else happening which is the development of horizontal EDA platforms which is, I think, a fairly recent phenomenon, in the last, say, 10 years. And these horizontal EDA platforms are now being used for to develop vertical applications, so that's my quick response to your questions.

BGB: OK, thank you Mani. Now, David, you're regarded as the father of complex event processing. Can you please explain what that is and how it relates to EDA?

David Luckham: You want me to explain why I'm the father?

BGB: No, no, please explain what complex event processing is and how it relates to Event Driven Architecture.

David Luckham: All right. Well, we have simple events which could be anything from a message, a temperature reading, something like that and then we have events that are composed of other events and I call them complex because they can be anything from a sequence of temperature readings to something like the first World War which was a very complex event, indeed, in fact, so complex that many books have been written about how it all happened and what it all was. In other words, we can't really pin down the functional relationship between the first World War and all the thing that is was composed out of all the other events that were its members. So, it'smore than a composite event, a sequence of temperature readings would be a composite event but a complex event is something that has many members. And, in fact, there's some doubt as to what the members are. Now, processing complex events is about how you deal with events in general, basic event, simple events and complex events. Processing events or processing complex events can in fact be very simple. An example of that would be filtering events based on say, their creation time.

Or the processing could be more complicated so now you need techniques for how to organize the processing of events in general, complex events most of the time and that's what complex event processing is about, it's about techniques for processing events of simple events and complex events.

BGB: Thank you. Now Rodney, can you give us some examples of how you've seen organizations using event processing and are there certain industries leading the way to adopting event processing?

Rodney Morrison: Well, I can, Beth and just move on from what Mani said earlier, this has really been going on for probably 20 years in the manufacturing process control, defense industry but where we're talking about real time events as far as information industries like finance, telecomm, supply chain and transportation have really led the industries. They've in the past decade, 15 years or so, have led to the standardization of such things as message oriented middleware and seem to get some processes that really do event driven processing.

So they're the likely leaders in the move toward gathering even more benefit from CEP, complex event processing and CEP applications can go from a wide spectrum even now and that's, you know, from one end of being very intense, highly specialized applications like algorithmic trading in the energy or finance markets or to applications that need to integrate well with a large number of IT services like supply chain applications. Those that are developing specialized or isolated high incident, low latency applications tend not to, at least now or initially be concerned with fitting into a proper SOA environment but those that need to integrate and play well with others think about it, you know, they obviously can gain some great benefits in agility by being able to integrate those even driven applications into an SOA framework.

And finance has the applications like trading, transaction cost analysis, order routing, market surveillance, fraud detection, risk management, they're really the drivers as far as the really innovative stuff going on in CEP but there are a lot of other use cases. In telecom, you might have some interesting things going on in service provisioning or fulfillment or service assurance. Supply chain and transportation are really doing some great things especially now with high fuel costs, you know, the airlines are really looking at how to keep costs down and they've done everything as far as making the planes more efficient and now they're looking at information and CEP to get the last dime out. The airlines can really be agile about how they're operations, how they're doing operations so for example, they can err on the side of low cost for the customers or load services and be agile and change that based on their business directives so like for baggage they can decide to hold the plane up or let you go. For scheduling, they might cancel your flight and put you on a later one because your flight is not as full. Even things like fueling, you know, costs are different for fuel in different cities so there's always a balance in figuring out do I fill up the aircraft here in this city but then it costs more to carry that to the next place because of the weight on the plane.

So, all of those things put together can be very interesting as far as transportation goes in gathering those events and optimizing them for business use.

One last thing that I wanted to go over is e-commerce and that is what has brought event processing to those industries that usually didn't worry about events before because the internet has made everything move much more rapidly especially now because they have real time information going around the enterprise. Just to give some examples, you know, the obvious ones are click stream tracking and customer experience tracking so for example like a travel site might be looking at the experience of someone coming and trying to buy airline tickets and they can gauge the customer experience by how long, perhaps, it took them to get the price for their ticket and did that affect whether they left their site or not and went to a competitor.

So, that's just a few, there's whole new ideas being birthed everyday and it's really an exciting field of interest to look at.

BGB: Now I'd like to take some questions from our audience and if you'd like to submit a question, please press the “Ask a Question” button. Now, Mani, you spoke about horizontal EDA systems technologies becoming available. Is CEP a horizontal EDA system?

MC: Well, when I said system, I really meant the specific platform that you would buy from a vendor. Then get that platform and then tailor it to your specific vertical application. The CEP is in some sense a discipline of computer science and it's used in building platforms but it's not in itself a platform, in my view.

BGB: OK. And David, would you say are there CEP platforms available or would you agree there?

DL: There certainly becoming available. There's several manufacturers out there that are wrapping CEP facilities if you'd like, you can think of a, in fact, you can think of a SOA which provides a CEP facility interface, you can do pattern matching, you can send stuff to the event engine, you can compose reactive rules with pattern triggers and so on. There are certainly manufacturers out there that are providing CEP facilities on top of the, if you want to call it platform, that they've provided in the past. Well, I won't mention any names but I can think of half a dozen so the answer would be “yes,” the industry is in the process of providing CEP platforms.

BGB: And Rodney, do you have any idea of how big this CEP market is right now? Can you give us any estimates on that? I don't know if we have an answer for that one.

RM: That's a good question. I don't have the answer to that. I do know that it is one of the biggest interests that I see around any sort of market areas. All the main vendors are looking at how they're going to support it so I feel that lot of businesses are considering it because they think it's the next step towards business optimization. And, in general, they need to be on top of that to be competitive.

BGB: OK, now in the opening keynote, Roy Schulte gave an example of how EDA may or may not involve human intervention. Do any of our panelists see applications of EDA that involve humans in the chain or is the greater application really for fully automated environments? Anyone want to take that?

MC: This is Mani. In my view, I've seen quite a few applications but almost none in which there is no human involved. Even in the military applications when there is a gun, for example, is fired or some sort of device is fired, to kill somebody is always done with a human being responsible for the final action so I think it is absolutely critical, I can't over emphasize this, to think about how humans as part of this, if you will, sense and respond system -- how EDA supports them, how these platforms and applications actually support the human being. I can't over emphasize that. Even if you're looking at trading, energy trading, commodity trading, fraud detection, in all these cases, I think it's really important to have a human being involved. When it comes to fraud detection is one case where you might want to have an application that informs, say a credit card user, that something inappropriate may be going on without having a human being first check that. But generally, I think human beings are critical.

DL: I agree with Mani that that is the case. You can think of your airliner that you get on and fly from A to B, the pilot's the human in the loop and he's getting his events from everywhere – his instruments, air traffic controllers and so on. But there are many examples of Event Driven Architectures where there is absolutely no human in it or whatever. The CPU on your computer is an Event Driven Architecture, believe me, and it's entirely event driven and quite without a human in the loop. It just depends what kind of architectures you're looking at; if you're looking at the sort of systems Mani was talking about, yup, you've got humans in the loop. If you're look at a standard Event Drive Architecture, the whole idea of Event Driven Architecture came from there aren't any humans in those loops.

BGB: Now, Mani, Roy Schulte spoke this morning about situational awareness and sense and respond in terms of how humans and animals naturally respond to events and I know you've also talked about track and trace capabilities for event driven systems, can you please take a moment to relate these capabilities to Event Driven Architecture technologies?

MC: Certainly, this is one of my pet views, here, is that all organisms that survive have to sense and respond to their environment. When an organism has to run away from a predator, it's got to move towards potential food sources and it's got to multiply and everything we do in the most fundamental sense requires both sensing and responding appropriately and what's changed, though is now the organism is not just a bacterium or even a human being but it's collections of human beings. It's organizations and organizations are sensing and responding to so many different things and sometimes even to cross-purposes, but I really think of EDA as supporting sense and respond and that's why it's so essential and so critical to the future of successful enterprises. It's almost Darwinian in that view and listening to Rodney and Rodney, I think gave a very thorough description of applications that use EDA, and I think one reason it's being used more widely or there's more concern about it are the consequences. The consequences of not responding appropriately have now become so much more severe that they were say 20 years ago that EDA has become so much more critical so just running through some of the examples that Rodney gave.

So if you look at fraud, you look at the front office and back office in a trading system and you want to detect fraud and if you don't do it, as we've seen in the last few months, severe consequences when bank systems almost going bankrupt as a consequence of not doing it correctly. Likewise for logistics and Rodney gave us a very good example of determining whether to send a plane on or not based on whether baggage was on the plane that did not appear to be related to a person, a passenger . Again, the consequences of doing the wrong thing are so severe. So I would just add to what Rodney was saying. Look at these applications and think about them in terms of sense and respond and see why it's so much more important to have EDA, to consider EDA today than it was 20 years ago, I'd say the consequences are so much more important now.

BGB: OK, now David in surveys that ebizQ has done, respondents seem very interested in the predictive capabilities CEP has to offer. How capable is CEP technology of predicting business events. How mature is the technology?

DL: Well, the sort answer is that it's getting better all the time. Predictions come out of data, in this case events generally want real time reaction and analysis. The analysis is another technology. CEP is about getting the events in the right form, to the right place to do the analysis and now your analysis for predictiveness could be based on experiential models, statistics of some sort and so on. Now CEP gives you techniques to channel the events, large numbers to the right predictors and to configure the predictors into event driven predictor networks perhaps using the sort of Bayesian network technology that's been pioneered in the recent past by people like Daphne Koller, in fact goes back to early analyses of medical diagnostics before the first World War so short answer, it's getting better all the time.

BGB: Now I'd like to clear up something that one of our attendees has asked. They got the impression that most implementations of CEP systems are one that people build themselves today because the market is still maturing. Now, is this true? Are people building their own CEP systems?

DL: Well, we have a recent development which is a website for building CEP applications so certainly it's now being encouraged and I think that's a very good thing and I agree that the market is still maturing. In fact, I've got quite a lot of flack from a lot of the vendors for questioning how much CEP is actually in their products at the moment.

BGB: OK. Now, Rodney, I'm going to throw you this question from the audience. What are the necessary components of a CEP system since we're talking about a roll your own or buying the components?

RM: Well, that's a very good and complex question that really sort of goes to what you're trying to accomplish there, what sort of sense and respond system are you trying to put together. It, you know, first of all, you need to figure out if you need CEP at all. Vendors will argue that you need high performance and complex event correlation. If you do, then you definitely need to look at buying that as a component. So, in other words, look at the various CEP offering that are out there.

The thing is, when you go and buy a CEP product then you've got to figure out how does that actually, you know, now I've detected an event with that product, how do I respond? Some of the products that you can get actually have sort of automated ways built in to respond back in to an event and others will partner with either a BAMsolution and that's where you've got somebody that can actually monitor the events coming out of it and have ways for people to drill down and do analysis on those events and the respond to them based on that analysis. Or they might also integrate with BPM products so that, for example, a event has been detected and now you have a business process management process going on or a human-oriented resolution of that event detection. So, those are the types of components that you have to look at to figure out how to put the entire solution together and that really depends on your business requirements.

BGB: All right. Now, Mani, event processing is really a different programming paradigm than the typical request/reply distributed solutions that programmers are more familiar with. What does an organization need to do to successfully integrate event processing into the organization?

MC: Well, that has many parts to it. You know, your question actually has 2 main parts. One is how it differs from standard request/reply and the other is what needs to be done to integrate. So the first part, the way computer programming was developed for many years was in terms of calling a procedure and having the procedure get the replies back. So the activity was initiated by the caller and when the caller needed information. This required the caller to know when to get information and where to get the information from and that was fine, provided you didn't need to monitor a great deal of what was going on.

Now, if you do need to monitor as we now know lots of sensors then if you use request/reply it essentially becomes a pulling mechanism. You keep pulling everything that may need information from, and that's the problem because you don't know how often to pull because there might be some pieces of information that are absolutely critical that just happened, but you don't know where it happened. So the idea of push gets away from this pulling and sort of basic information terms, it's knowing what's changed that's important and where it's happened and you as the consumer don't know was changed so you need an agent to help you do that. So that's where the “push” comes in. So that's the answer to the first part of your question about request/reply vs. event push, if you will.

The second part, identifying how to integrate event processing into the organization, again Rodney has given some very good examples of the way event processing is used and in my experience in working with customers, the first things to do are what customers do in any case which is identify the costs and benefits of the expected costs and benefits very, very clearly and, you know, the benefits aren't necessarily that you use CEP or the real-time enterprise or any of these buzzwords. The benefits are the specifics in your given application so I would ask the question, “what's going on now?”, “how's the application being used today?”, “how do you expect the application to change when you have the system implemented?” and “how much dollars does the change give the enterprise?” and then identifying the costs to see when does this investment pay off. The cost, in my experience, is typically not the cost of acquiring a platform, whatever the platform is. The cost is training users, making sure that the system is appropriate for the human being that's actually going to use it. Application integration is inevitable, there's always some substantial cost for application integration and then for these kinds of problems we have the issue of error. Error is inevitable and there's going to be false positives when the system says something important has happened and it really hasn't and there'll be some cases where there are false negatives where the system doesn't catch something that has happened.

Now David talked about prediction and when you predict, you've got to accept that sometimes information may be incorrect. So, dealing with all of these issues and thinking of the costs very concretely and clearly up front is I think what could make for successful integration and I have always, in my experience, started off with a pilot project just to demonstrate both the costs and the benefits so that the enterprise understands how that would work and to go from the pilot on to something bigger.

BGB: OK.

DL: Yeah, I thought that was very good, Mani. I would emphasize that we're heading towards a probabilistic view of event processing. For example, in fraud detection that you were talking about or in terrorist activity and homeland security applications you're going to get answers like “maybe we saw terrorist activity with probability X.”

BGB: OK. Now David when a complex event comes in and shows up on a dashboard to a consumer, does the consumer have knowledge that it was, what that complex event is composed of or do they need to know that? What is it they're looking at when they get that notification?

DL: Very good question. Most BAM products today should be able to give you a breakdown of the event that you're interested in if you were to request it and that's where event hierarchies come in -- in being able to retrace how a complex event was composed. And there are situations where you may not need to know that. For example, you're an airline scheduler, flight “X” arrives one hour late, may be you don't want to know, you just have to deal with it. But perhaps later on, the airline logistics want to retrace how that happened. So a good BAM application should, by and large, be able to give you some information about how the event was composed or caused it to happen. Whether BAM applications that you have in your office today would do that, is a different question.

BGB: Now, can someone on the panel talk about modeling of event driven integrated applications at the domain level and also at the implementation level, conceptual level and how important is it? Is there a new way to model these applications? Anyone want to take that? Rodney, are you seeing your customers model these applications in a new way?

RM: Yes, that's interesting but I don't think anyone has come up with the paradigm to do it yet.

BGB: OK

RM: And actually different CEP vendors lend towards whether you're trying to fit some sort of model together or whether you're talking about events just sort of as rules or even if you're thinking of them as a sort of a database so you're talking about rules as far as gathering, you know, dimensional data based on time so it depends on the approach you're coming at. A lot of people come at CEP with very specific business types of problems that they're trying to address and basically there's just trying to detect those things rather than trying to come from a high-level model perspective.

MC: This is Mani. I've seen three kinds of models that we use here. So for example, we're working on detecting a dirty bomber, somebody carrying nuclear material in let's say a backpack and the kinds of models first of all is a model, it is a data model and the data model is a fairly typical model of, you know, exactly how is an event represented. David talked about complex events so if you have a complex event how does that point to the center events that composed it. So that's the data model.

Then there's the so-called center model. The center model is actually modeling how the real world information gets mapped to an internal standard representation. So it's mapping from, say, analog information to the standard of presentation the enterprise is going to use for events. That's the events model.

Then, as David points out again, there's in these applications completely probabilistic. You're guessing that there is an adversary, there is a terrorist application. You don't know that for sure, so you're always predicting. So then there's the Predictor Response Model and that's, in that case it's a different kind of model from the Event Model, you're actually looking at simulating how the environment, how the enterprise is responding over time to this. So there's three kinds of models. At this point, it's not like UML by itself. The UML would be the data modelbut we need these other models are necessary for EDA but I think weren't really necessary for standard request/reply SOA.

BGB: OK, now, I'd like to turn now to how EDA relates to SOA. Rodney, do you view them as different but complementary architectures. This morning, Roy spoke about using EDA as part of SOA. Can you tell us how EDA can help SOA?

RM: How it can help… Well, I guess there's one way that I've seen EDA used in conjunction with SOA and maybe even one of the strong use cases of EDA across industries is for service management. So, many SOA middleware vendors are exposing metrics that can give you information like end-to-end process time or even individual process activity times within a service and those metrics can be then provided to a CEP engine to look for event that would help monitor and really control and manage those services.

So, you know, put together things like on certain events, for example, I can do dynamic provisioning so for example, maybe I have a service, it's getting maxed out, performance metrics are showing me that response time is slow so I want to give gold priority to a certain consumer, process their things first. Or, maybe even I want to scale out, based on those events, I want to make another service instance and try to do some load balancing of that service. So, one of the things I am seeing is that since there's so many metrics coming from a variety of different internal IT services, they really can benefit from CEP just at monitoring the service levels.

As for if they're different or complimentary, that's still a debate and maybe more for academicians or bloggers but I see it as a choice between business applications that are detect and respond or request and respond and there are definite requirements for both paradigms in the IT environment. So you need to look at how you can gain benefits from each of those types of applications from operating in an SOA framework.

BGB: Now, one of our attendees writes in saying that she is an old EDA architect now working as a consultant advising government programs on migration to net cetricity and SOA and her question is that now that EDA is getting new spotlight she hopes to introduce the notion into this huge government enterprise where SOA has already taken root as the key net centric approach. And she's seen various PubSub services and other things popping up where EDA elements are pushed under the umbrella of services and SOA and, you know, people know and need events but the only paradigm they understand right now is SOA.

So, looking into this, the question isshould she take the uphill battle and evangelize the event driven SOA as a combination of two architectural styles or should she give in and get on the path of expanding the definition of SOA and services to include EDA under it and call it event driven SOA? You know, what's the most pragmatic approach here? I'm going to push this out to both Mani and David. Mani, can you start the conversation here?

MC: Yes. So, it depends on how one defines SOA. SOA has had many definitions, even within Gartner there's been more than one definition. So, if the focus of SOA, if SOA means loosely coupled systems, subsystems with very clean interfaces, so that new systems can be coupled into the substrate, then EDA events fit within that framework because EDA is also loosely coupled with clean interfaces and is extensible.

If SOA specifically means request/reply or sometimes even specifically web services, then EDA can still be coupled but then there is a layering between the push and the pull parts. In all EDA systems there is going to be some parts that are pull and some parts that are push where events are pushed and some parts where information is pulled. So, in practice, I think you find both kinds of protocols in use so even within SOA, even, let's say purely web services, you could have an EDA layer on top of web services where the consumer of events makes a request to the producer of events saying I'd like to consume your events, gets a reply back so now there's a registry going on. Once an even is registered by the producer, the producer can use a web service call to push the event to the consumer.

So, you can have this layering. I think, perhaps in some ways, the more difficult problem is the degree of, shall I say “hype”, for both SOA and EDA. The hype is that once you get an SOA system in place, it's going to take care of everything and, of course, we find that there's a lot more to integration than request/reply and then it becomes partially a political issue rather than a purely technical one so I don't know what the best advice is but technically speaking, I see them as being complementary and I think you do need push and you do need pull and, of course, you always need the loose coupling.

BGB: David, do you have anything to add to that?

DL: I've written a number of articles on this. And one position that can be taken, of course, a caveat, and I think Mani touched on this in his answer there, that is, it's not very clear what people mean by SOA these days and that's rather unfortunate, but the whole SOA issues has gotten very fuzzy and clouded. But if you want to take what might be called the “religious approach” you could say the following – an Event Driven Architecture, that is an EDA, is a SOA in which all communication is by events and all services are implemented by reactive event processes, i.e. react to input events and produce output events. That would be the strong approach to saying that EDAs are SOAs with certain communication properties and certain ways of implementing services. Now, if you back off from that answer, then you get into a lot of other issues that are probably too many for this particular panel.

BGB: OK. A large subject, certainly and I am going to refer our audience to a number of resources we have here. Of course, we have David Luckham's book; we're going to give away five copies at the end of the day today and also Mani Chandy has written a number of articles that are available on the ebizQ site.

Now this slide is available for download if you want to look further into the resources and check them out later after this program. Also, we have just a very, very short time and so many more questions coming in. I'd like to tell our audience that for further questions on technologies, please visit the SL Corp. booth and if you don't see it popping up on your screen, then please turn off your popup blockers there. Also, please visit our networking lounge, you can ask your questions live there and, again, we're giving away Starbucks coupons for joining the chat there and also we have a number of questions here which we did not get to on technologies but coming up at the top of the hour, Charles Brett from Forrester will be presenting the Forrester Taxonomy for Event Processing where he will be talking about all the different technologies that are available. So, hope you'll join us for that as well. I would like to thank our distinguished panel today: David, Mani and Rodney. Thank you all and thank you to all of our attendees as well. Hope to see you back shortly.

Thank you, Beth. Thank you.