Every Once in a While the Tool Matters
Another good post from Anatoly on BPMN pitfalls. In this post, he discusses a problem of timing, with respect to BPMN messages between processes. The key example is illustrated by his diagram as follows:
A process A sends BPMN message to a process B. What if A sent the message before B has become ready to receive it, i.e. before a token arrived to B2?
- The message will be lost and B will wait for the next message, probably forever.
- Process engine will store the message sent and B will receive it when ready.
Interestingly, Anatoly says that some vendors follow convention #1, and some follow convention #2. The good news for IBM BPM customers is that IBM BPM allows for both conventions via configuration of the event listener. In some cases, the listener should be triggered only when an event occurs after arriving. But in other cases, the order of arrival is irrelevant. In tech circles we call this “the genius of the AND”. I can have both.
Sometimes there are subtleties of a tool that make it more productive than other tools. At a high level, these tools might look like commodities that all implement BPMN. But they all implement BPMN differently. Not all parts of BPMN are equally important to implementing a BPM program. Vendors that focused real development effort toward features that made customers and consultants more productive typically develop better answers to these grey areas over time.
Lombardi (and now IBM BPM) was one such firm. Many of the most important features were added because product management looked at what consultants and customers were doing in methodology and implementations and thought long and hard about how to have the software support the BPM development process. This is why you have the Coach Designer and Coach Views… and why there is a robust versioning system baked into the product.
It is also why we have nit-pick features like configuring the listening behavior in message events…