« CEP - Some Applications within Capital Markets | Main | SQL Standards - an impedance mismatch with reality »

Friday, September 05, 2008

Acronym irrelevance

Posted by Giles Nelson

There’s been lots of discussion very recently (and lots of discussion about the discussion) about how CEP is related to other software acronyms and what constitutes a CEP use case or not. See here and here.


This kind of debate depresses me in two different ways. Firstly it displays symptoms of a more general software malaise – the wish to group and pigeon hole things into software classes which then confuse people who are not in the in-crowd. Once a name is agreed upon, let’s say Complex Event Processing, it then gets reduced to an acronym - CEP (excuse the pedantry but this is actually an initialism, not an acronym but that's enough of that). People feel a little sense of achievement. “We’ve made it – we’ve got a TLA!”. Debates then rage about how CEP relates to BRMS, BAM, ESB, BPM, ESP, BEP, EDA and EAI. Dreadful stuff, but, yes I know, we’re all guilty of it at times; it does give others the impression that the IT industry has its head up its own back passage.


The second reason this debate depresses me is that I really don’t understand this constant wish to class things as problems which fit into the "CEP class" or not (just see all the nonsense, albeit amusing, around routers of various types voiced by Messrs Bass and Palmer). Software is ultimately a productivity tool and what end-users really want to know is whether a product will help them achieve something they would be unable to do so by other means. End-users are using and considering using event processing products for a whole variety of purposes – trading, order routing, travel information dissemination, exception management in long-lived IT processes, detection of aberrant conditions in groups of pressure sensors, detection of fraud at retail point-of-sale terminals… the list could go on. People who have a problem to solve might think that event processing technology could help them. It is their responsibility, together with a vendor who may hope to sell something to them, to determine whether a product would help them or not. Were people doing event processing before off-the-shelf products came along? Yes. Do you need a CEP product to do event processing? No. Does everything you do with a CEP product have to involve complex, multiple streams of perhaps temporally related information existing in some distributed computing data cloud? No, of course it bloody doesn’t. I note that Opher Etzion seems similarly turned off by this type of debate.


And before I go I’m quite aware that I’ve used the CEP initialism eight times in this posting. I think I can be excused - this is a Complex Event Processing blog after all.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452154069e200e554e61a208833

Listed below are links to weblogs that reference Acronym irrelevance:

Comments

Mark Palmer

Giles I think you threw the baby out with the bath water - there was a good underlying that was going on about SOR that got overshadowed by the acryonymn stuff. Here's my take on this:

http://streambase.typepad.com/streambase_stream_process/2008/09/getting-back-to-use-cases-and-patterns-for-cep.html

And returning to the baby:

http://streambase.typepad.com/streambase_stream_process/2008/09/on-cep-and-smart-order-routing-sor.html

The comments to this entry are closed.

<-- end entry-individual -->