BRForum - the CEP angle (2) - Intelligent Processes

Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News BRForum - the CEP angle (2) - Intelligent Processes
# 1  
Old 10-26-2007
BRForum - the CEP angle (2) - Intelligent Processes

Fri, 26 Oct 2007 13:38:27 +0000
At Business Rules Forum this week, Stephen Hendrick from IDC presented a keynote on IDC’s opinion of where “business rules” fit in the grand scheme - namely something called Intelligent Process Automation (although maybe they should consider the last term to be Architecture). This merges Event Processing, BPM, BR and BI (where BI is a collective term for analytics and other optimization techniques). This makes lots of sense, although of course you cannot guarantee the result as “intelligent”. You can certainly use CEP, for example, to drive processes (including inputs to conventional BPM) and execute rules (for rule-driven CEP anyway - if not you can always invoke a separate BRE as a service) as well as benefit from BI (to find the event patterns of interest, or to build self-tuning rulesets, etc).
I thought it would be interesting to score Stephen’s presentation (purely from a CEP perspective, of course!):
1. MAYBE = “You can’t have decisions without processes”: well a CEP process is a-kind-of-process, but we’re giving the benefit of the doubt to Stephen here as I’m sure he meant “you can’t have decisions without BPM”. And as far as we know, no one is (yet) claiming that CEP belongs in the BPM space, and for sure CEP systems can make decisions!
2. CORRECT = “There are 2 clear leaders in BPM, IBM and TIBCO”. Well, I can’t argue there. I note that Sandy in her blog mentions that Steve also mentioned Adobe as a leader, so its possibly my brain politely filtered that part out. And my colleagues in the BPM group at TIBCO will probably argue there is only 1 leader anyway (not to mention that IDC IPA = TIBCO BPM+, but that’s a separate discussion…).
3. MAYBE = “Event loops are standard in Object Oriented systems”. This is only true for OO-GUI systems, which from my time trying to get to grips with GUI development tools I learnt the hard way. Most OO systems outside of GUIs though have nothing to do with event loops, and event loops are not that much to do with modern Event Processing paradigms in any case.
4. MAYBE = “Processes are connected by queues”. Message queueing is certainly a favorite at IBM and Microsoft, but is only 1 of many middleware techniques - for example TIBCO are better known for pub-sub middleware techniques! But the main point to consider (which is absolutely correct to mention) that event processing (and intelligent processes) really really benefits from having an event bus do the delivery for you…
5. CORRECT = “CEP is a great way to handle a BPM or BRMS” - at process and rule execution time, this is exactly right. Chris blogged on Dynamic BPM just a few days ago, which is an example of CEP-driven BPM. And for executing rules, you can certainly call your rule engine of choice from TIBCO BusinessEvents, but you will probably find the rules run faster overall inside the CEP engine itself!
6. CORRECT (KIND OF) = “Processes connect to Events”. Normally you drive BPM with event-transactions (like a customer-complaint workflow - there is a driving event and then update events like “Customer call completed”). But certainly you don’t feed a BPM system with the raw events you might feed a CEP system.
7. CORRECT (BIG TIME) = “Linking decisioning to events is a much better approach”. Well, that’s my opinion too…
So far, Steve gets a good score. Lets look at some of the challenges in deliverying Intelligent Processes:
8. CORRECT = “The more integrated the better [for IPA components]”. Well, er, what can I say here? The TIBCO family includes (C)EP, BPM, BRE (via the CEP engine), and BI.
9. MAYBE = “Events… need analytics to identify patterns”. Actually, if you are looking for new classes of patterns, then something like a highly visual reporting tool to look at the raw events might be good…
10. MAYBE = “BRMS… need to move to continuous decisioning”. Actually I am being unfair to Steve here - he is correct, but the continuous decisioning part can easily be done as part of the event processing stack, until you need decisions in the BPM part anyway.
Steve then concluded with some estimates of market growth for 2006-2011 of 44% for BPM, 9.2% for analytics, and 18.5% for BRMS. I didn’t spot the figure for Event Processing (maybe there wasn’t one). And the concluding statements were that IPA is an integration challenge and can handle complex decisioning - at TIBCO we think we’ve probably solved both these more than most.

Login or Register to Ask a Question

Previous Thread | Next Thread

3 More Discussions You Might Find Interesting

1. HP-UX

Multicore from a different angle

Everyone seemed to be a little stumped by the multicore question I asked earlier this week, so I decided I'd try a different angle. Turns out that on a multicore system HP-UX reports every core as a seperate processor. All the usual commands (ioscan, top, etc.) report two processors for every... (7 Replies)
Discussion started by: Midcain
7 Replies

2. Post Here to Contact Site Administrators and Moderators

angle brackets should be escaped automatically

I think that HTML code within posts should be turned off -- the vB Code can provide all the features we need. Then, you should modify the program to automatically escape any angle brackets, so that < gets translated to < and > gets translated to > I see a lot of people garble their posts... (4 Replies)
Discussion started by: PxT
4 Replies

3. Post Here to Contact Site Administrators and Moderators

Angle brackets

From the Apache thread in the Adanced forum: Thats because your browser interprets anything within angle brackets to be an HTML tag. You need to quote these brackets if you want them to appear correctly. The proper quotes are: &amp;lt; for < and &amp;gt; for > So, for example, you would have... (1 Reply)
Discussion started by: PxT
1 Replies
Login or Register to Ask a Question