Jan Purchase of LuxMagi, a business rules and decision management specialist, has an excellent blog series on the benefits of a decisions-first approach to business rule analysis and business rules management system (BRMS) implementation.
In How DMN Allows Business Rules to Scale, Jan describes the well known problem with current rules-first approaches that “rush to detail” – the rapidly increasing complexity:
“Experience has shown that sets of business rules, even those administered using Business Rule Management Systems (BRMS), become very hard to manage and understand once they reach a certain level of size and complexity. Although small, very tightly focused rule sets can be effective for simple business domains, large rule sets are challenging to create and even harder to maintain. Small rule sets that become large over time (scale up) present the most difficulty. They are at risk of collapsing under the weight of their own growing complexity or becoming the sole preserve of a small number of ‘gurus’ and ‘high priests’ who alone understand them—defeating a key objective of business rules.”
Decision modeling addresses these issues. Jan writes.
“Decision Modeling is a technique for representing business decisions in a precise, standardized format that:
Focuses on decision requirements first: development focuses first on what business decisions need to be made, their context within a business process and what they require to work effectively. This focus on requirement, and not rule implementation, allows gaps and issues to be discovered early before effort is invested.
Documents dependencies diagrammatically: the dependencies of decisions (high level rules) on sub-decisions (subordinate business rules), input data and knowledge sources are illustrated in a graphical view (The Decision Requirements Diagram, DRD, an example of which follows)—making it easy to see how rules rely on each other and to determine the consequences of any change;
Supports a precise representation of business logic: The Decision Logic Level of a Decision Model describes the business logic of a decision in a variety of precise, business oriented ways. Many of which have representations defined by the decision modeling standard (including Decision Tables, text and analytic models). However, for any decision this logic definition can be replaced with a BRMS artifact that implements that decision. This means every decision rectangle in a DRD can refer to a rule artifact in a BRMS.
Succinctly defines business services: sets of cooperating decisions can be deployed together in a decision service. Decision models can represent these in terms of their interface, the rules they encapsulate and the data dependencies they have including the outcome of other decisions.”
In Ruleflows Consider Harmful, he adds:
“There is a common misconception among business rule authors that a ruleflow is necessary to capture the execution sequence of a rule set and provides the best overarching view of business rules. In the vast majority of cases decision models are a better means of achieving the same goals because they represent a more essential and meaningful relationship between rules in a rule set. Rule sets can be improved and maintenance issues avoided by using decision models instead. The use of ruleflows should be confined to optimization and sidelined in BRMS.”
In Who Models Business Decisions?, Jan describes the broad use cases for decision modeling:
“Business Analysts. The most common group of users, BAs are often tasked with producing precise and transparent representations of locally defined or externally regulated business decisions. An increasing number prefer to use a standard notation, like DMN, rather than an ad-hoc one.
Process Designers. Many business process modelers see the benefit of decoupling the structure and logic of business decisions from the sequence of business processes. Many are drawn by the natural interface between BPMN and DMN.
Subject Matter Experts. In practice SMEs use decision modeling less than I would hope. This seems to be because business experts are less comfortable or familiar with precise representations of business decisions. They tend to view precision as a matter for implementors—a sentiment with which I heartily disagree.
Business Rules or Code Developers. To my surprise, many developers are drawn to the way in which decision models manage complexity and are keen to share the responsibility of maintaining a decision model, especially when it exhibits direct traceability with existing implementation artifacts (i.e., business rules or code).
Data Architects/Scientists. Increasingly we observe this community using decision modeling, specifically the requirements level of DMN, to provide a context for analytical models.
Business/Application Architects. Architects sometimes use decision modeling to define the interface of a collection of decision services, understand their stakeholder value and prioritize their implementation.
Project Managers. This is a rarity admittedly, but I come across two PMs who have co-developed and promoted decision models as resources to train new team members and to facilitate independent review of decision services prior to committing development resources.”
Jan’s detailed posts are an excellent resource for practical knowledge from an experienced practitioner. To learn even more, Jan is writing a book with Decision Management Solutions CEO James Taylor, Real-World Decision Modeling with DMN, due out later this spring. Join our newsletter for updates on the book release. LuxMagi is a Decision Management Solutions partner.