Is CEP a Service or a Process?

Followers of TIBCO will know that we divide the software world into 3 interoperating software stacks: BPM (iProcess and its associated components), SOA (covering ActiveMatrix service management, BusinessWorks orchestration, Adapters, and ESB / middleware like EMS and RV), and Business Optimization (pretty much everything else). So Business Optimization [*1] includes:

• visualization services, such as General Interface (AJAX) and PortalBuilder, for sophisticated user interfaces that enable businesses to interact better with their systems – optimizing the user experience
• business intelligence services, such as Spotfire, for analyzing and understanding data relationships in order to make better decisions (and, of course, identifying decisions to be automated in decision services, etc) – optimizing awareness via viewing data patterns
• complex event processing services (or agents), namely BusinessEvents, providing (distributed) event pattern identification, state modeling, business and decision rules, backed up by a high performance (distributed) cache – optimizing the responsiveness to business events
• master data management (MDM) services, via Collaborative Information Manager, for controlling the critical data used in other services and processes – optimizing the management of master data.

One frequent (theoretical) question is: is CEP, as provided by tools like BusinessEvents, a process that is comparable to iProcess and BPM, or a service that really represents an EDA flavor in something like the Active Matrix stack? Lets look at the evidence for and against:

The case for SOA:

1. BusinessEvents can deploy under ActiveMatrix BusinessWorks, either as a conventional EDA CEP component being fed events (asynchronously) under the control of BW, or as a decision service (common-or-garden rule engine) for complex (synchronous) declarative business rules.
2. BusinessEvents provides an event processing service in composite applications – events are processed and returned as “high level information” events for other services to utilize as required, either synchronously or asynchronously (or, er, both).
3. Event-driven business rules (can) provide the business logic for many services.
4. Event processing is intrinsically a service to a variety of applications and processes in an IT system [maybe this is the same as 2, except the owner may be a business process rather than an IT service].

The case for BPM:

1. Complex event processing is just a different, non-workflow, continuous type of event processing that is simply an extension (conceptually) of the simple BPMN-driven event processing in normal business processes.
2. Business processes involve processing business events – although BPM is traditionally associated with a control flow that is “handling” some event, there is no reason why a business process cannot be doing continuous, complex, event processing (although this may be modeled differently e.g. via a state model and rules). [Maybe this is the same as 1]
3. CEP processes could be “managed” just as other processes are: controlled releases, simulation of performance, multiple roles / actors involved in handling the event(s), deployment to BPEL, …
4. Event processing is intrinsically a process carried out for a business, either generating events for other processes or consuming events generated from other processes (or both).

The conclusion? Perhaps the classification of CEP depends on the particular CEP application: it could be a business process OR an IT service OR both. More likely the latter, although if you view business processes as *just* those that carried out by (or capable of being carried out by) human workers, then clearly CEP won’t often apply; likewise, if you view SOA services as just synchronous services, then CEP won’t apply there either. For sure, BusinessEvents is used alongside both the TIBCO SOA and BPM stacks (and other vendors, of course), with no ill effect on either!