From identification to executable logic of operational decisions Methodological approach with DMN Johannes Stöhr, Signavio GmbH A White Paper February 2017, 2nd Edition
Table of Contents 1. Why Business Decision Management? 3 2. Short Introduction to Decision Model and Notation 3 2.1 DMN and BPMN 3 2.2 DMN Elements 4 3. Methodological Approach with DMN 5 3.1 Identifying Operational Decisions 6 3.2 Describing Decision Requirements 8 3.3 Deconstructing and Refining Requirements 9 3.4 Specifying Decision Logic 11 4. Outsourcing Logic From BPMN to DMN 13 4.1 What is Logic and What are Results? 14 4.2 Gateways become Input Data 14 4.3 Conditions become Rules 15 5. Summary and Outlook 16 6. Contact 16 Methodological Approach with DMN Signavio GmbH, February 2017 Page 2 of 16
1. Why Business Decision Management? Operational Decisions in Focus Business rules and business processes are inextricably linked. In almost every organization, decisions are made daily as part of operational processes, decisions which in turn often determine the further development of these processes. In principle, operational decisions are characterized by the fact that they appear in high numbers and usually have to be made within short timeframes. To answer questions such as Can a request be granted? or How much of a discount can I offer to a customer? in a consistent and quick manner, unambiguous and comprehensible descriptions of company regulations are essential. The challenge today for companies is found not only in the description of regulations surrounding decision making, but more so in the consideration of what foundations form the current basis of a decision. As a result of market dynamics, market conditions are continuously changing. International competition, higher customer requirements and ever shorter product life cycles necessitate constant adaptation to business regulations. Furthermore, legal requirements and guidelines have an influence on businesses, which in turn can have a direct effect on operational processes and decisions. Those who do not comply with legal requirements must expect sanctions. These dependencies demand flexible business processes and transparent decision processes as new laws can necessitate additional activities and adjustments of business regulations at any time. Agility and structural flexibility have thus become key economic factors, because the more agile a company is in its reactions to changes, the more successful it is vis-a-vis its competitors. In the face of these challenges, the management of business regulations and optimization of decisions has, over the last few years, been established as a discipline in its own right under the term Business Decision Management (BDM). 2. Short Introduction to Decision Model and Notation With the aim of decoupling and separately adapting future business regulations and business decisions, the Object Management Group (OMG) adopted the Industry Standard DMN 1.0. This standard makes it possible for professional users to describe requirements and decision rules in simple terms and at the same time offers IT experts a sufficient understanding of the implementation of executable systems, which allows for the automation of the decision logic described. 2.1 DMN and BPMN DMN comes from the same place as the widely used BPMN standard and therefore offers the benefit of developing decision models independently from business processes as well as for the seamless integration of available process models. Operational decisions can therefore be presented in a transparent and comprehensible format as part of business processes. With the help of decision models, questions such as What information do I need to reach a decision? or What legal sources will have an influence on which decisions? are answered. Through the hierarchical structure of DMN diagrams, dependencies between decisions are made visual and consequences transparent. The following diagram shows the interaction between BPMN and DMN. Methodological Approach with DMN Signavio GmbH, February 2017 Page 3 of 16
Figure 1: Modeling Aspects of BPMN and DMN 2.2 DMN Elements In contrast to the extensive BPMN notation, the DMN standard is made up of only three essential elements, which are shown in figure 2. The core element hereby presents the decision. While input data objects (inputs) provide the basic information for decisions, the applicable business regulations are described in the decision element on the basis of the necessary input data (input objects). > > Contains the logic needed to determine the results > > Can be broken down into further partial decisions > > The result can become an input for other decisions > > Reusable for other decisions > > Makes information for decisions available > > Has a defined data type (text, numeric value, etc.) > > Reusable for many other decisions > > Represents the legitimization of a decision > > Example, legal requirements, a person or something similar Figure 2: Overview of the Core DMN Elements Methodological Approach with DMN Signavio GmbH, February 2017 Page 4 of 16
As shown in figure 3, simple as well as complex DMN models can be created with the help of these few elements. Figure 3: Example DMN Diagram 3. Methodological Approach with DMN To get from the identification to the logic specification of operational decisions in a structured way, a process model like the one in figure 4 can be helpful. The extent of knowledge available about important decisions in operative processes is crucial at this point. You may already know the operative decisions within the business process for which the logic should be described, and now only need the foundational information for it. In this case you can start with the description of the demands and skip the first phase, as you are already aware of the relevant decisions. However, in case you are unclear about when important decisions must be made within your operational processes, you should start at the beginning of the process model with the step identify decision and go through the respective phases in the correct order. Ultimately, at the end of the process model, you will have decisions that can be automated by systems in their described logic. Methodological Approach with DMN Signavio GmbH, February 2017 Page 5 of 16
Operational decision available Identify and describe decision Describe requirements Specify logic No further deconstruction required Deconstruct and refine Figure 4: Methodological Approach Model 3.1 Identifying Operational Decisions Knowledge of an operational decision is a prerequisite for being able to describe requirements and logic. This aspect seems self-evident, however many companies are unaware of the nature and number of their operational decisions. These decisions are not always as obvious as check request or determine service. On the contrary, all of the activities within a business process can be viewed as decisions in which, following predetermined rules and on the basis of predetermined basic information, a result for the continuing progression of the process can be determined. There are various approaches to identify decisions in the operative process. Consideration of Specifications and Guidelines Important rules and decisions can be deduced from a more thorough consideration of internal or external specifications. Hereby it is important to question the specifications to find further test criteria. For example, the internal specification, the postage fee is omitted for premium customers leads directly to further decisions that, if applicable, must be determined beforehand. > > When is a customer a premium customer? To answer this question, the criteria must be checked in an upstream (i.e. earlier) decision, either manually or automatically. > > What constitutes an order? This question leads to a decision, which is usually based on available information about an order, for example, checking whether order details are complete or the validity of submitted details. Even this decision should be made beforehand, as the postage fee can ultimately only be applied to a complete and valid order. By working through in this step by step way, decisions and above all, their dependencies can be identified. In particular, if phrases such as that was established years ago are familiar to your organization, then this method is a good way to check traditional guidelines from a current standpoint. Methodological Approach with DMN Signavio GmbH, February 2017 Page 6 of 16
Searching for Keywords In the process world, there are certain words that are characteristic of decision-making activities. With the analysis of operative activities, you can search for specific words such as check, calculate, compare, confirm, define, determine, and similar terms. If one of these key terms comes up in the description of an activity, there is most likely a decision to be made. For each of these decision-making activities, exactly what is being checked, compared or calculated can be scrutinized to ensure the necessary decision-making foundations are met, and hence to deduce some feasible rules. Analysis of Application Systems Another approach for identifying decisions represents the examination of operational applications from the IT side. Admittedly, due to technological advancements, monolithic systems such as mainframes and terminals have become extinct in the contemporary business world. However some decision-making rules remain in the source code of various applications and are being implemented there in non-transparent and uncontrolled ways. If these business rules have been buried in code, then this code must be frequently adapted. Long revision histories or frequent adaptations in the IT are therefore a good indicator for hidden operational decisions within IT applications. If the source code has grown old in conjunction with business regulations, another indicator for decisions often takes the form of countless notes and post-its. Price and offer notices or specific instructions for customers can give an indication that operational decisions are being made by employees outside of the intended applications. The operational decision has been identified - what now? As the identified decisions are an integral part of operational business processes, they should also at least be described as an activity in the BPM process model. This shows the true combined strength of BPMN and DMN. Activities, behind which business rules and checks are hidden, can be given the attribute task type and the selection business rule and can be marked as decision-making activities. Figure 5, below, demonstrates this through the example of an ordering process with the activity determine discount, in which business rules are applied to determine the size of the discount. With one click of the icon in the top left corner of the activity, a DMN model can now be linked. Methodological Approach with DMN Signavio GmbH, February 2017 Page 7 of 16
Figure 5: BPMN Order Process with Marked Decision Activities A DMN decision diagram can now be created for the decision-making activity that has been identified. The main decision is always at the top and the results of this are required directly for the ongoing progress of the process. This decision should, if possible, be given the same name as the corresponding BPMN activity to ensure it can be easily found and for clarity. 3.2 Describing Decision Requirements Decisions are always made on the basis of information. This may be based on existing facts or on the results of other decisions. In a business context, facts are understood to be certain pieces of information within the operational process that do not need to be firstly determined by the logic from other information. Facts can be easily retrieved, such as for example, a particular type of goods or a fixed storage capacity. If a decision requires particular pieces of information, which still have to be determined through the evaluation of other information, a secondary subordinate decision must firstly determine and supply these results. For example, in the following diagram, to successfully determine whether a discount should be applied, the status of the customer must first be confirmed through other information. However, the amount of products as well as the value of the order are directly available and do not require any further subordinate decision pathways. Methodological Approach with DMN Signavio GmbH, February 2017 Page 8 of 16
Figure 6: Main and Partial Decisions with Requirements Described Restriction of Decisions Knowledge Sources In practice, decisions are often limited by certain specifications within their results. Regulations can come from particular contracts or can arise from the terms and conditions. Legal requirements are often influential sources for decisions especially in strongly regulated industries, such as banks or insurance companies. In all cases, these influences on decision making can be presented graphically thanks to DMN with the help of the knowledge source object. In the figure above, the business rule all VIP customers get a 20% discount could be an internal requirement from the sales director and can therefore also be depicted as a decision. Thus it is easily recognizable which sources have a direct influence on which particular decisions. As clearly illustrated in the basic diagram above, the decisions have not yet been specified with executable rules, however interdependencies and decision-making foundations are already recognizable. For this reason, this DMN standard diagram can also be described as a decision requirements diagram, or DRD for short. 3.3 Deconstructing and Refining Requirements Up to this point, we have identified operational decisions and the business processes that belong to them. After all basic information in the previous phase has been depicted with requirements, a decision can have a multitude of inputs, as shown in Figure 7. All these inputs must be considered in line with the various company regulations within the decision, which can quickly result in an unmanageable variety of decision rules. For professional users, it is important that in practice, these rules remain comprehensible so that inconsistencies can be discovered and rules can be quickly changed if necessary. Methodological Approach with DMN Signavio GmbH, February 2017 Page 9 of 16
Figure 7: Negative Example of an Individual Big Decision Divide and Rule Separating Decisions To avoid such big decisions, the bulk of information must be divided into secondary or sub-decisions. The question then arises about how these decisions should be divided up. There is no specification in DMN standard, however certain factors can be helpful in practice and can serve as a guide. > > Reusability: The result of the secondary decision can be used in other DMN diagrams as well as in completely different contexts. > > Complexity: When there are more than 6 inputs, the logic of the decision becomes very complex. To simplify this, the decision can be split into two or more sub-decisions, see figure 8. > > Influential Specification: If different specifications can be applied to a decision, splitting the decision up into smaller pieces can be helpful to make clear which parts have the most influence. Through encapsulating individual sections of the decision-making process, the logic can be kept comprehensible and structured for the professional user. If we apply this principle to our discount example, a substantial and transparent representation arises. Methodological Approach with DMN Signavio GmbH, February 2017 Page 10 of 16
Figure 8: Positive Example of a Divided Quantity of Information 3.4 Specifying Decision Logic At the heart of every decision is the logic with which it is made. It firstly makes replication possible and feasible, whether it be for a person or system, and allows the outcome of the decision to remain consistent when based on the same evidence. The logic is mostly depicted in the form of business rules within a decision table. There are indeed other forms of logical depiction (analytical models, descriptions of terms, and many more) however our focus in this whitepaper is on decision tables, as they are the most commonly used format for professional users. A decision table always contains a collection of rules. They describe which information (inputs) must be considered as conditions to produce a particular result (output). Let s have a look at our discount example to see how this works. Figure 9: Decision Tables to Determine a Discount Methodological Approach with DMN Signavio GmbH, February 2017 Page 11 of 16
Comprehensiveness of Decision Tables In order to determine a result for every use case, there must be a business rule for each case. Failing this, the decision table will be incomplete, which can cause issues in the process in particular with automated execution. Ultimately, computers cannot ask colleagues how certain cases are usually handled. Therefore, special attention should be given to the fact that for all input values; for example, for every possible customer status, rules are available on how results are determined. Unambiguous Decision Tables To successfully reach a decision, it is not enough to simply define a rule for every possible use case. These rules cannot be allowed to overlap or even worse, to contradict each other. In a negative case, several rules will apply to certain situations, which can also possibly lead to a variety of outcomes. This decision table is therefore not unambiguous and can lead to problems. Figure 10: Ambiguous Decision Table Unambiguous Decision Tables with Unique Hit To achieve unambiguous decision tables, it can be specified that for every use case, only one rule may apply. This specification is called unique hit and is the standard setting for DMN decision tables. In this case our decision table would look like this: Figure 11: Unambiguous Decision Table with Unique Hit Methodological Approach with DMN Signavio GmbH, February 2017 Page 12 of 16
Unambiguous Decision Tables with First Hit Let us imagine that we want to consciously allow for such rule overlaps. Why? Well, maybe we want to check whether or not customers comply with certain specifications and maybe we only want to apply a general rule in the case of noncompliance. For this procedure, the evaluation classification of the decision table can be converted so that the first rule that is hit is the one that is used and the rest are ignored. From this, a variety of rules can develop, namely from specific to general. Failing that, the general rule is automatically carried out and the specific rules overridden. This type of process is called first hit, which can be recognized by the small f in the decision table. Our decision table can therefore look the same as figure 12 and would be just as unambiguous. Figure 12: Unambiguous Decision Table with First Hit However, the first hit rule should be used with caution, as due to the general catch all rule in row 5, this table is always unambiguous. Therefore mistakes such as missing rules are easier to overlook. It can however strongly reduce the necessary number of rules, therefore making decision tables more manageable. 4. Outsourcing Logic From BPMN to DMN In many companies, the decision logic is depicted together with the logic of business processes in BPMN process models, as shown in figure 13. Through this embedding, considerable disadvantages can develop for the process model. > > The process model must be constantly updated with every change in company regulations. > > The process model becomes more complex and difficult to understand with every rule. > > In some circumstances, the decisions, along with their logic, are needed in other process models. However, as it is not possible to reuse them in this embedded form, they must be modeled again. If you come across problems of this kind, you will find this chapter about the transferal of decision logic to DMN very helpful. For this there are three very simple necessary steps. Methodological Approach with DMN Signavio GmbH, February 2017 Page 13 of 16
Figure 13: BPM Process Model for Determining Discount 4.1 What is Logic and What are Results? Firstly identify, as shown in figure 13, which elements in the process model belong to the decision logic and which represent the actual result. In most cases, the results of a decision are described with activities. ATTENTION: Upstream results are mostly results of sub-decisions which are still required for further logic. 4.2 Gateways become Input Data It is a reasonable assumption that gateways always represent decisions. Indeed, from the perspective of DMN they can be treated as pieces of information that are required to determine the result. Thus they become input data for decisions. Figure 14: Exclusive Gateways become Input Data Methodological Approach with DMN Signavio GmbH, February 2017 Page 14 of 16
4.3 Conditions become Rules To reach a certain result activity, a particular combination of process paths must be followed. As each of these paths presents a condition, the necessary combination of paths can be described as a rule in a decision table. Figure 15: Conditions become Business Rules With the help of these steps, it is possible to outsource decision logic from BPMN into DMN models. This not only allows for reusability with other business process models, it also simultaneously reduces their complexity. Yet what does our final DMN diagram look like after we have completed all the outsourcing steps? Simple, like this: Figure 16: DMN Diagram to Determine a Discount Methodological Approach with DMN Signavio GmbH, February 2017 Page 15 of 16
Summary and Outlook The creation of decision diagrams, which on the one hand describe all the necessary requirements and on the other hand offer an executable decision logic, opens up new possibilities for companies. Due to its proximity to the BPMN standard, DMN models can be easily integrated with existing BPMN process models. This not only means greater transparency for operational decisions but also simultaneously provides the opportunity for flexible adaptation to requirements and rules. Simultaneously, BPMN models can be made easier through their decision components and can be reduced in terms of their business substance, namely the actual process of operative activity. The possibilities of technical implementation of DMN diagrams are varied. Thus the logic depicted can be exported directly into decision tables as executable code and imported for automatic application in rule engines. The context in which the rules of the system are applied depends on the technical environment which the rule engine is in. If it is part of a Workflow Management System (WMS), this system could assign certain tasks to various users and demand information inputs. Only when all necessary information has been made available by the user, can an automated decision be made on the basis of imported DMN rules from the system. Through the transparent rule description with the help of DMN and its easy transferal into executable systems, the future creation, management and adaptation of rules as well as of decision requirement descriptions can be assigned to the field of responsibilities of the relevant department. This way, the IT department is relieved of excess work and can focus on its core functions, such as the management of executable systems. Contact Publisher Signavio GmbH Worldwide business transformation! Germany info@signavio.com www.signavio.com Find all addresses & telephone numbers at: signavio.com/contact