We were recently discussing the “value proposition” of CEP systems in organisations. By my count there are 2 main value propositions:
- application – what is the value to the business application
and - technology – what is the value of the technology (over other IT technologies)
To some extent these are intertwined, but are really for different audiences (business and IT):
Application value: this covers the opportunity cost of finding or predicting complex events, reduced latency, and the IT benefits’ side effects
- Runtime value – cost of latency in terms of processing events (such as mentioned in this case study)
- Runtime value – cost of latency in terms of speed of maintenance / change (such as in this case study)
- Opportunity value – the benefits of detecting and exploiting complex events (such as in this case study)
Technology value: cost of architecting and developing a J2EE / DB / BRE system vs CEP (with a simpler backing store)
- Code value – minimising SQL spaghetti and Java spaghetti versus declarative rules (see the numbers in this case study)
- Model driven – classes, events, states, rules vs stitching non-event-driven UML together (or not using models) – in other words, speed of development (such as in this case study)
- Integration benefits – no need to hook J2EE to DB and BRE – concentrate on business logic
- Lower costs of providing Fault Tolerence / High Availability with a single distributed scalable platform that includes object storage.
However, this sort of list does not really do justice to most of the CEP applications we see – these tend to be those that would be cost prohibitive without a CEP approach. In effect, the above are “icing on the cake” for most customers.
See also this previous post on the value proposition of COTS CEP systems …
