No other topic in the BPM arena has suffered from more misinformation, disinformation, and willful ignorance as the relationship between business process and business rules. These two disciplines are most often put forward as alternative approaches, rather than complementary aspects of managing the business. In reality, business process management (BPM) and business decision management (BDM) need to be used together. Unfortunately, each discipline has historically spoken only to its own concerns, with little interest in how it integrates with the other, in fact with little understanding of what the other is trying to do.
Today, both disciplines share the goal of empowering business by allowing models to be created and maintained by business analysts for the purpose of documentation, analysis, and governance. And both allow those business-oriented models ? if the organization so chooses ? to be transformed into technical models, executable on a runtime engine. In recent years, tremendous progress has been made within each domain toward standards and methodologies that enable a common modeling language to be shared by business and IT, i.e. roundtripping between the business and technical models. In the process domain, such a structured approach is exemplified by my book BPMN Method and Style. In the BDM domain, The Decision Model by Larry Goldberg and Barb von Halle applies a similar structured business-oriented methodology.
Neither book, however, gives sufficient consideration to the fact that in decision-intensive processes like lending or claims, process and decision modeling are separate large-scale activities performed concurrently, usually by independent teams. That can work well, but only if the methodologies on both the process and decision sides explicitly consider how those models will be integrated.
Even though both books are brand new, neither discusses this. That does not mean the books are incorrect. Each just describes a core foundation, a framework for modeling business processes or business decisions so they can be shared, analyzed, and maintained effectively. But creating process models and decision models that fit together ? in a way that serves both the analyst/architect concerns of documentation, analysis, and governance, and the developer?s concerns of executable implementation ? requires going a step further. Larry, Barb, and I are beginning to do that now.
Both BPMN Method and Style and The Decision Model properly give a lot of attention to the question of cardinality: What is one process, as opposed to multiple related processes? What is one decision, and how does it relate to its constituent business rules? Both frameworks impose some technical constraints on it, but beyond that, the scope of a single process or a single decision is a matter of judgment or art, what I call modeling style. Both a process and a decision, the top-level objects in each domain, are inherently compound entities, composed hierarchically out of reusable building blocks. In BPMN, those building blocks are called subprocesses; in the Decision Model, they are called rule families. A BPMN subprocess can call other subprocesses, and a Decision Model rule family can call other rule families.
Integrating BPMN and decision modeling ultimately comes down to properly representing decisions and their constituent rule families in the context of BPMN subprocesses and tasks. There is a way to do this, and we?ll cover it in Part 2.