Monday, March 29, 2010

Dynamic BPM

There appears to be a new buzz in BPM lately (at least in a lot of blogs I'm following). Whether you call it dynamic BPM [1], adaptive case management [2] or unstructured, agile or adhoc processes, they all seem to point to a similar problem: the fact that traditional workflow management systems seem to have difficulties in supporting the kind of flexibility that is required nowadays in more complex settings or rapidly changing environments.

Gartner [1] suggests that dynamic BPM will become more and more important. Defining your application logic will require a combination of processes, rules and event processing, and I couldn't agree more.

One thing that confuses me though, is that some people seem to position this adaptive case management as a new, separate form of BPM [2]. While I agree that you might need new concepts or a new approach to model, execute and manage these more flexible processes, I don't think they should be considered as completely different. In practice, it is usually better to build on top of solid foundations (in this case traditional BPM) rather than to completely reinvent the wheel. Imho, there don't seem to be any technical reasons why it would not be possible to extend a traditional process engine to be able to support both approaches.

And you definitely don't want to end up with two or three different BPM products [3], just because you have a combination of traditional and non-lineair processes. [Hell, I think you don't even want to end up with 3 different solutions for supporting processes, rules and events (one process engine, one rules engine and one CEP engine that you then need to integrate), but that another discussion.] Especially since I think these are not two completely different kinds of processes, but more like the two extremes of a wide spectrum of processes, where some have a stronger focus on control flow while others are more data-based.

I can only say that we are extremely happy to see that other people are now also seeing the advantage and even the necessity of combining processes, rules and events. Now it's only a matter of time before someone invents a new name for BPM + BRM + CEP [4]

I'll try to do a more technical blog in the next few weeks, and give some concrete examples how Drools [Flow] can be used to create this kind of adaptive processes, using a combination of (what we call) process fragments, rules and event processing.



  1. Very interesting post, I'm defining (architecture, components, flows, metadata, etc.) a system that will support the processing of a huge amount of events received through interfaces like plain tcp, WS, JMS.
    Processes are building blocks that could be part of workflows.
    I'm thinking about the integration of Drools (w/ Flow) and Apache Service Mix, any suggestion? Rob

  2. The Drools engine is capable of event processing (Fusion) and executing processes (Flow). To integrate it into your application, pipelines will allow you to stream events (as input) from different sources to the engine. The engine can then process these events and start / signal processes whenever necessary.

    To integrate with external services (as output), take a look at work items, they will allow you to declaratively specify what needs to happen in your processes / rules, where you can then link that to a specific implementation (e.g. using ServiceMix) at runtime.

  3. Let me see if I understood this ACM (for lack of a better name) thing: you pick a context, a set of data, or whatever (a "case", that has a "current state"), think on it or execute some rules on it, and then pick a "next state" from a list of known possible states.

    The system records the path you (and the rest of the users that work on the case) follow in a similar manner as a BPM system records execution. Only that there's no process definition, but in some way, you make it up as you go or as you need.

    It could be an interesting tool for process exploration and discovery...


  4. Hi Kris - interesting post. For further thoughts on this browse .

    Also note the European academics are starting to use the term "event driven BPM" or edBPM - although of course all business processes are event driven, this term is meant convey "event-focused".


  5. I'm looking forward to your technical post. Most of the collateral I've read about ACM since seeing this blog doesn't really say much concrete.

  6. One thing that should be noted is the importance of service orientation - this quote from the Vosibilities blog ( ) explains:
    "Workflow, human interaction, reports, event processing — all need to be incorporated in a service-based architecture if we’re ever to get to better business (i.e. BPM) and IT (i.e. infrastructure) alignment. In other words, BPM itself needs to be service-oriented."

  7. Interesting post - basically confirms what we've been doing for years...

    Gartner, welcome to the present ;)