EbizQ is running a series of articles (first here and second here, curiously classified under “Social BPM“) on “dynamic BPM”, quoting luminaries such as Gartner’s Janelle Hill and Jim Sinur, and Forrester’s Clay Richardson.

In the simplest terms, [dynamic BPM] supports rapid “on the fly” process adjustments. “You can respond to emerging conditions and changing business needs, in some cases without any interruption to IT or without having IT get involved,” explains Jim Sinur…

Dynamic BPM is described as having various levels of complexity:

• rule/decision-based selection of processes / process paths - see (good old) decision management / rule technology
• dynamic configuration of parts of processes - usually a variation of the above, with decision rules determining what tasks to do and in which order
• goal-driven processes - selection of processes and process tasks is entirely based on some mechanism for addressing a route to a goal

So lets look at some of the examples mentioned:

• railroads using RFID sensors to monitor passing traincars (a.k.a. “sense and respond”)
• complex algorithms to determine where to deploy troops (normally requiring “situation awareness”)
• government document tracking (a.k.a. “track and trace”)
• pharmaceutical and fragrance design process involving ad hoc partner participation (i.e. “social BPM”)

For sure, CEP and event processing is at least a “major contributor” and in reality probably the solution for the “sense and respond” and “track and trace” application areas. And it helps with “situation awareness” in the real-time domain.

What is fascinating is that the term “dynamic BPM” seems to really mean “any type of process that is not associated with simple, fixed task orchestration” - in other words,  “non-BPM” technologies like CEP.  One perspective is that one of the main drivers for processes to be “dynamic” is the ability to respond to change - i.e. events. Indeed, the need is for many business processes to take account of there being larger quantities and higher rates of events that can be deemed important. Another is to use more sophisticated solutions to solve or optimise more complex problems - think of classical planning and scheduling algorithms and predictive analytics, for example.

Probably the “dynamic BPM complexity levels” described in the article can be mapped to the following, based on increasing levels of event-handling capability:

• pre-defined, late-selected process paths: subprocesses are pre-defined
• no-predetermined-path processes, where rules or more complex algorithms determine what tasks need to take place - sets of tasks are allocated based on conditions and events: tasks are predefined
• goal-oriented and semantic processes, where goal states are reached by the dynamic selection of tasks based on current events and situation: tasks may be constructed on-the-fly, and processes and plans changed according to the situation and events.

There are other viewpoints as well - for example, adaptive case management (for non-automated, changeable processes), currently the subject of an OMG standardisation effort. Related to things like goal-driven fulfillment technologies like TIBCO AF and AC. Perhaps we are returning to - dare I say it - knowledge-based processes ?

I leave the final words to a quote:

…according to Gartner Inc: “By 2013, dynamic BPM will be an imperative for companies seeking process efficiencies in increasingly chaotic environments.”

TIBCO has a virtual booth at the MWD Advisors Process Intelligence virtual event, covering TIBCO ActiveMatrix BPM Spotfire (which might also win the award for the longest product name) - which does visual and predictive analytics on your process information - and TIBCO BusinessEvents (i.e. CEP) - which does real-time event analytics, monitoring, and dynamic process control…

The MWDA webinar (in 2 parts) is quite interesting and worth a look: their model of Process Intelligence is layered in 3 parts:

• strategy level: goals, motivations, metrics
• process level: BPMN, CEP patterns, analytic models
• reaction level: decision rules and analytics

From a TIBCO perspective, ActiveMatrix BPM and ActiveMatrix BPM Spotfire cover the metrics, process models and analytics side, with BusinessEvents covering the real-time metrics, dynamic processes, CEP, event-based analytics and decisions. One interesting possibility is to use the BusinessEvents’ state models for strategic goal planning too.

Meanwhile, the Gartner guys are also pushing the “Business Process Improvement” button, releasing a report threatening doom and gloom for organisations who do not control their processes. They talk about:

• undetected but detectable process errors: this being the case for process monitoring and analytics, presumably. Either that or good old business analysis!
• “context awareness” to rejuvenate commodity processes: context being of course state, or what events tell you!

Note that the MWD event sponsors other than TIBCO (a CEP company) are Progress (also mentioning CEP capabilities) and SoftwareAG (again,  also mentioning CEP capabilities). So it could be an interesting year for BPM-CEP convergence?

I can’t say I’m a huge fan of the term “edBPM” as all managed business processes rely on events - it’s a bit like saying “flexible agile development”… However the goal is worthy enough, as it is to convey the use of event processing technology in automated business processes. For this reason I am also not a fan of the “Management” part in “edBPM” - pureplay BPM systems like TIBCO AMX BPM provide management of (human-oriented) business processes, whilst automated business processes have different, simpler, “management” needs. A more accurate term might be CEP-based Business Processing, using things like inference-driven business processes with integrated decisioning and business monitoring… but this begs the question “how is this different from complex event processing” with an emphasis on the “processing”, not merely the detection of “complex events”.

This week Rainer von Ammon hosted edBPM2010 as a workshop at the ServiceWave2010 conference, which had the theme of Ubiquitous CEP or U-CEP. This was attended by representatives from a variety of institutions, from a large European telco to a Chinese University. And the variety of interests around U-CEP was fascinating - brain systems, socio-economic organisations and the like - all of which seemed far more interesting than a computer scientist might initially imagine. The “discussion table” I attended focussed on CEP in manufacturing for which the STM use case is an excellent example, and for which the German University of Siegen team described their work with a specialist metal foundry (constructing, for example, aluminium engine blocks for exclusive executive cars). An interesting point here was the fact that German heavy industry was investing in CEP research to remain competitive in a global economy.

Last week was another angle for CEP-based Business Processing - the OMG standards body voted to extend the “Letter Of Interest” in, and hence allow new submitters for, the proposed CMPM (Case Management Process Modelling) standard. At the beginning of this standard TIBCO had presented its plan-based, rule-driven Advanced Fulfillment Framework (AFF, now TIBCO ActiveFulfillment and ActiveCatalog) as a response to an RFI on Dynamic Business Activity Modelling. The increasing current interest in case management and “Adaptive Case Management” is part of the same swell in interest in edBPM / CEP-based Business Processing.

Now, vendors are not really allowed to create pervasive technology acronyms (as competitors naturally insist on inventing competing terms). This is a job best left for the industry analysts (or possibly bodies like EPTS). So far I have not seen much interest from them in the term “edBPM”.  And “Complex Event based Business Processing” is probably too close to “CEP” - in more senses than just the words - so “CEBP” is probably not going to fly either. Other related / overlapping / equivalent terms to edBPM have included dynamic BPM and knowledge-driven process modelling, and probably a few others. We shall see what term or terms eventually “stick” for this concept - watch this space!

Thanks to Patrick Austerman from the TIBCO Netrics team for an interesting update on the Matching Engine and Machine Learning Engine. Currently this bipartite graph-based technology is used to identify matches to inputs, typically as a kind of search, in processes like book retailers (”identify a book”) and government (”identify a citizen”).

Clearly this could have huge ramifications for any BPM or CRM use case that involves identifying records and cases via form-filling - text matching to improve accuracy and speed in customer record look-ups. Imagine the effect on call center productivity if agents can quickly and accurately identify callers and cases? Indeed, Netrics’ use in TIBCO CIM (MDM) can be considered an example of this. Not surprisingly, Netrics’ heritage is interactive marketing where identifying and associating web users is of paramount importance.

Other relevant domains include analytics (for example alongside TIBCO Spotfire) and of course CEP (for text pattern detection). In the latter case the matching engine might be useful where there is any possiblity of inaccurate information in an event - consider a manually entered field, or barcode scanning error. When combined with rules to eliminate false positive matches, this could be very useful.

What the Matching Engine does is to learn text (and optionally numeric and date data) associations, regardless of locale, language, etc. But the Machine Learning Engine is another type of decision engine, used for where information is missing and cues must be taken from the absence of that information (in other words, many fields but sparse data). So far it is used in scoring applications.

Overall then we might expect Netrics “matching technologies” to become de rigeur in best-practice BPM solutions, with a strong possibility of some interesting applications in the CEP space… we’ll see if this pans out in 2011!

One of the drivers of success in the BPM world has been BPMN - the Business Process Modelling Notation - developed under BPMI before it got absorbed into OMG, and probably a bigger success than any other modelling standard - and now as BPMN 2.o (beta, at this time) slightly reconfigured in name as the Business Process Model And Notation. BPMN is used to provide a “process” perspective (versus, say, a data or an event perspective) of a system and shows the flow or orchestration of process tasks and activities. It is made up of (per the excellent bpme.de BPMN2 summary poster):

• 2 flow subtypes: sequence is the normal flow, with default and conditional conditional subtypes
• 7 task types: send, receive, user, manual, “business rule” (really decision), service, and script
• 6 activity markers: sub-process, loop, parallel, sequential, ad-hoc and compensation
• 7 gateways: exclusive, event-based, parallel, inclusive, exclusive event-based, parallel event-based, and complex
• 6 types of data: input, output, object, collection, store, and message
  and
• 63 types of event…

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate

… across 8 situations classified by location in a process:

• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving 58 63 event types defined [*1].

Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

So let us analyse these event types from an event processing perspective:

• Message and timer events: these are probably most familiar with to those with an event processing perspective, with a message relating to what we consider either a source or a derived event.
• Escalation: this is really a deferal to a different process (e.g. a supervisory process), and can be handled by some internal message in event processing.
• Conditional: this is “reacting to conditions becoming true” - in other words equivalent to a rule-firing (or event query) success. In a rule system this might be handled just by setting some fact or data, which in an inferencing rule system will use some internal event to signal to the rule engine that other rules may “fire” - however there is no need to explicitly model this behavior. I may also of course create an event (or in a query system, insert / update some event), which is again is not explicitly modelled as “conditional” per se…
• Link: some means of connecting models: this is more a “page break” than a business event!
• Error: I prefer the term “exception” here, which of course is a local context - an error event in one process is a normal event in an error-handling process, etc.
• Cancel: this is more a transaction-specific event: if dealing with transactions then some events may indeed be “cancel transaction X” requests, which may or may not be satisfiable, etc.
• Compensation: this is where some process route may require some compensatory process - for example in relation to a “cancel” event.
• Signal: signalling information across processes: this is might be used as a control event, such as in controlling a choreography.
• Multiple: one of a set of events is “caught” or provides the cue to continue the process.
• Parallel Multiple: all of a set of events is “caught” to continue the process.
• Untyped events are used for start and state changes. Typically, though, a state change is the main event we are interested in (in event processing)!
• Terminate event - process complete! From an event perspective this (process end) might never happen of course…

The extra detail might be explained by the fact that in BPMN you are detailing *how* to implement a process, and the “event symbol” is providing you with some specific context for that event. In event processing languages, you usually describing “what* is to be processed, and where all events contribute to some situation or context. It will be interesting to see how these 58 symbols work out in practice, as a hindrance or a help for process designers…

Note:

*1: the table of events above, from the BPMN2 poster from bpmb.de, has 63 event symbols, and is slightly re-organised from the equivalent table in the BPMN2 beta specification (Table 10.93 pp 269-270, in 10-06-04.pdf). Interestingly the specification document also includes a table to detail the event symbols (Table 12.23 ppp 405-411, in 10-06-04.pdf) but this shows only 58 symbols! Let’s just say “lots of event types” in BPMN2 then…