In my last posting I discussed the presence of three major kinds of information: procedural, declarative, and structural. The first one is indisputably crucial for building process centric applications using business process management (BPM) suites. In this article, I will go into more detail with respect to the declarative aspects and explain how to connect declarative facts to the process models or case templates.
There are several formal languages to specify declarative information. In the area of artificial intelligence (AI), expert systems are based on facts declared by so called clauses together with deductions. When building BPM applications, it is best-practice to use business rule management (BRM) systems – either seamlessly integrated in the BPM suite or as a separate part of it. As we will see later, there are several different notations for defining business rules like decision trees, decision tables, or hard-coded rules. Their expressiveness also depends on the vendor-specific capabilities.
So, what are the benefits of using business rules? In every case, it is advantageous to integrate BRM systems in the overall enterprise architecture:
- Separation of Concerns: Business rules are by far more suitable for the expression of declarative aspects than process models. Mostly, the use of procedural notations leads to spaghetti code.
- Re-Usability: By defining the rules in a central place, they can not only be integrated in many business processes but also accessed by several applications and systems.
- Maintainability: In many cases, BRM systems bring along sophisticated mechanisms for grouping rules and structuring them into rule sets. This helps to reduce complexity and improve maintainability.
- Flexibility: Business rules can easily be adapted to changing business needs leading to more flexible systems and a better Business IT alignment.
- Wide-angle scope: The scope of BRM is not only confined to BPM suites. It is rather possible to make use of it in the context of custom developed software or package based solutions.
To go into more detail – business rules are important for the implementation of processes in many respects. In the literature, they often are classified into four categories depending on their focus:
- Derivation rules: they are used for the computation of values based on input data. For example, master data management (MDM) systems could use the rule << 5C = 3A + 2B >> for the assignment of C whenever the values of A and B are changing.
- Integrity rules: they check the consistency of values in the context of other data. The same rule << 5C = 3A + 2B >> could be used to check whether A, B, and C are consistent.
- Reaction rules: they are the basis of decisions that must be taken in the control flow (e.g. gateways in business processes resting upon the result of a rule).
- Deontic rules: they describe organizational facts like responsibilities, relationships and so on. As a sample, workflow management systems could assign tasks to individual users based on availability, rates, or skill sets.
The integration of business rules into process models is not standardized. It heavily depends on the capabilities of the underlying BPM, BRM, ACM systems. As a consequence, it is important to consider the requirements when choosing these tools. Even if the BPM suite supplies the widespread Business Process Model And Notation (BPMN) Version 2.0, there are several possible ways for the connection of business rules as shown in the following exemplary process model.
The BPMN 2.0 standard contains a purpose-build notation element that allows the explicit link to business rules – the so called “rule task” (Task 2). It can be used to compute values in the underlying data set (derivation rule) or to check constraints and throw an event (integrity rule). Moreover, its result can be used in subsequent gateways for making decisions (reaction rule). Explicit rule tasks are system-independent and can be used in heterogeneous IT landscapes. At this, the relations between processes and rules become obvious. On the other hand, models are inflated by a lot of activities.
If supported by vendor-specific add-ons of the BPM suite it is also possible to connect business rules to BPMN 2.0 models implicitly. In this case, deontic rules are directly assigned to pools or lanes, derivation rules to data elements, reaction rules to gateways, and integrity rules to boundary events (activities or sub-processes). As a drawback, the relationships to business rules are not visible in the process models itself. Finally, it should be mentioned that other modeling languages have different capabilities with respect to business rule integration. More often than not, powerful BPM suites bring along their own notations combined with more or less sophisticated business rule mechanisms.
Apart from business processes, BRM may also be valuable in the context of adaptive case management (ACM). For example, the following ACM tasks could be depend on business rules:
- Derivation rules: generate new parts or options of a case based on some pre-conditions.
- Integrity rules: check if two parts of the case are compatible to each other.
- Reaction rules: automatically change the status of a case or some parts of it.
- Deontic rules: assign the specific rights of the users in the context of a case.
Unfortunately, there is no standardization for the integration of ACM and BRM. Only a handful of commercial BPM suites offer convenient solutions. Perhaps, future ACM notations will cover these aspects in an appropriate way.
At the end of my posting, I will give a short overview of languages and notations for business rules. Most BRM systems offer proprietary implementations. The most basic possibility consists of the textual representation in form of natural language or structured clauses.
Whenever all conditions are fulfilled, the corresponding conduction is valid. So, it is possible to deduce new facts by applying mechanism like the so-called forward-chaining or backward-chaining. There are some graphical notations that enhance the understandability of rule sets. Decision trees arrange the conditions as an ordered tree with the conductions as its leaves whereas decision tables group rules with related conductions to tables by ordering their conditions as columns.
Some specifications in the context of business rules are promising standardization efforts albeit they are not commonly used yet. The Semantics of Business Vocabulary and Business Rules (SBVR) deals with the fundamentals including definition for related terms and a representation that refers to the RuleSpeak® language as a formal notation. Hereby, the Business Rule Manifesto describes the preferred approach. The Object Management Group (OMG) initiated a Request for Proposal called Decision Model and Notation (DMN) to standardize the underlying meta-model and the interchange format based on SBVR and the Production Rule Representation (PRR).
To sum up, business rules are widely used to express declarative aspects in respect of business process implementations. They can be described by means of several standardized or vendor-specific language. As long as it is supported by the tools, they can also be connected to business processes or even adaptive case templates. In my opinion, most BPM projects could benefit from using business rules in addition to pure process models.
I am very interested to hear your experiences and comments concerning the benefits of business rules.