Don’t miss the great post about his and Ilog’s take on rule and decision management methodologies by James Taylor today (available here).
Here’s the bottom line:
- Focus on what the system does or decides.
- Focus on the actions taken during a business process and the decisions that govern them and the deductions that they rely on.
- In priority order, focus on actions, then decisions, then deductions.
- Don’t expect to automate every nuance of an evolving business process on day one – iterate.
- Iteratively elaborate and refine the conditions and exceptions under which
- actions show be taken,
- decisions are appropriate, and
- deductions hold true
- Iteratively elaborate and refine the conditions and exceptions under which
Another way of summing this up is:
Try not to use the word “then” in your rules!
Do check out the Ilog methodology as well as the one I developed for Haley that is available here. The key thing that we addressed at Haley was the ability to incrementally refine the conditions under which an action or decision or deduction is appropriate. Unfortunately, even though I applaud these methodologies, the inability of most BRMS tools to nest conditions or directly support exceptions limits their ability to support an effective methodology. That is, a methodology that supports iterative development and dynamic businesses with incremental refinement of applicability.
I agree with many who have said, in various ways, that business change is not as much in the model or process as in how and when decisions are made or actions are taken. The decisions and actions themselves share stability with the model and process. It is the conditions and exceptions that are more volatile.
Methodologies and tools need to facilitate evolution of conditions and actions, including their connection, combination, and nesting. That’s where the change is. That’s where learning is most active, where iteration is unavoidable, and where iterative refinement needs to be most effective.
FYI, I also left some comments about about object-model centricity and the need for explanation not just traceability on James’ blog. Don’t miss his post.