TIBCO has a very successful BPM product, iProcess, that is compliant with standards such as OMG BPMN and WFMC XPDL, has a powerful new AJAX-driven Forms capability, and is generally considered to be one of the leaders of the pack when it comes to current BPM technology. And as a reminder, current BPM technology involves mapping business processes to BPMN flow diagrams, which represents a form of “simple” event processing [*1], to coordinate manual and automated workflows involving human operators, automated services, and so forth.
Interestingly, some TIBCO BPM customers are beginning to exploit CEP techniques alongside BPM to assist in the modeling of complex processes, such as dynamic manufacturing processes. TIBCO iProcess Conductor, for example, can be used with TIBCO CEP technology to provide goal-driven event rules that help drive the dynamic specification of processes executed in iProcess. Another example is TIBCO partner Accenture, who use [*2] TIBCO BusinessEvents (BE) to model some of their customers’ dynamic business processes, decisions and exceptions. They utilize BE’s state models and rules to drive their iProcess (/or other BPM tool) workflows that are modeled in BPMN, with a subsequent considerable reduction in BPMN complexity and increase in maintainability. This approach is used in their solution for “Complex Change Request process management” and is described as having the following solution architecture principles [*3] :
- State models used for change-related concepts
- Continuously monitor all events related to the change process to infer
- State transitions
- Workflow events (start workflows, receive responses…)
- Back-office events (new parts, new process owners…)
- Create new monitoring concepts to measure process KPIs continuously
- De-couple meta-model (state & entity models) with workflow models
- Better support for dynamic changes to the change process
This approach, they find, provides the following benefits in change-request applications:
- Agile change process
- Dynamic business rules to determine process behavior
- Separation of concerns of the process meta-model and the approval workflows
- Brings visibility to the status of change processes
- Identify processes that take too long or that are stuck
- Reduce the overall implementation time (and cost).
Decoupling complex event and state processing from a BPM system is conceptually similar to decoupling business logic into a decision service (and indeed, the CEP tool in this case also fulfils the role of an event-driven decision engine). Clearly these are not requirements for all Business Processes / BPM applications, but might be of interest to those hitting complexity or sophistication problems with their BPMN models. In addition, BPM pundits who prefer an “everything in BPM(N)” approach rather than a component-based solution / best-of-breed architecture will obviously not like this [*4]. But then again, the customers using this approach seem to like it, and they are the ones that count.
Notes
[1] BPM deals with events that kick off processes, and BPM represents the processing of that event…
[2] Example customers are in electronics manufacturing and banking.
[3] Reproduced here by kind permission of the original author. The Accenture solution here also uses a unified user interface / dashboard.
[4] Bruce Silver comments on the “BPMS Suite” vs “BPM component” market dynamics in his blog mentioning iProcess Conductor from TUCON08. The contradiction here is that if you want to use a CEP / event-driven state and rule engine to drive your BPM, you won’t find an integrated solution from another major BPM vendor. But luckily you *can* (i.e. some customers do) use TIBCO components with non-TIBCO BPM vendors…
