Automate Decisions

(This is a translated version of my German blog post you can find here: https://mi-nautics.com/entscheidungen-automatisieren/)

Intro

Technical systems are increasingly carrying out value-adding activities. So far, however, decisions have often been left to humans. The following article does NOT deal with the topic of ‘artificial intelligence’ but looks at it in a theoretically sound but shirt-sleeved manner in practical terms how ‘simple’ decisions can be automated without getting involved in the buzzword bingo. Rather, it is based on tried and tested OMG standards and provides the theoretical and methodical tools.

What are decisions?

As is so often the case, there are numerous definitions for ‘decisions’ and even a comprehensive theoretical approach, the ‘decision theory’, is available. But in the introduction, we promised a shirt-sleeved contribution and that’s how it should be. Nevertheless, we need a specification so that we talk about the same things in the following. So we define

A decision is a non-situational and deliberately chosen alternative based on known pre-selection criteria that cannot be influenced.

With this definition, we differentiate from decisions on opinion formation, on interpersonal relationships, spontaneously made decisions, as well as strategic, overarching decisions that would still allow several options for action in their operationalization. In this way, the decisions we deal with in this article can be characterized as data-based, repeatable and comprehensible. And this is a good prerequisite for automated decision making.

How do we decide?

In order to be able to automatically select alternative courses of action, some preliminary considerations are required.

Decision theorists speak of a process that spans several phases. In the following, we want to start with two phases. First, the preparation of decisions, second, the implementation of decisions.

What we sometimes do in seconds in everyday life is now divided into two essential blocks for automatic execution. A differentiation is made between what happens at run time (namely the decision-making process) and what happens at design time (namely the decision preparation).

The decision preparation contains much more complexity for the automation because the actual decision-making (with good preparation) is almost effortless.

So what needs to be done during the preparation?

1. Identify decision needs An analyst must identify the work areas in which decisions are made and of all possible decisions, he must analyze those that correspond to the above definition.

2. Collect criteria The analyst must collect all the criteria that must be taken into account when making the decision. ‘Hard facts’, i.e. clear, valid data, are crucial.

3. Collect alternative courses of action In the same way, the Analyst collects what are potential alternative courses of action that are even possible (allowed). Closed decisions, such as agreeing or rejecting, cover the full scope of all action alternatives. Open decisions, such as the choice of the means of transport for a business trip is difficult to fully grasp, especially since these can also occur in combinations. The analyst is asked here to collect the set of all alternative actions as completely as possible.

4. Determining the decision-making structure The analyst must identify the dependencies between the criteria and alternative courses of action. For example, when choosing the means of transport, are travel costs or the ecological footprint of higher value? This coordination often requires knowledge of internal company guidelines or regulatory requirements.

5. Collecting, evaluating and validating rules Recognizing the consequences of combining different decision criteria is a highly analytical task.

Only then will the information collected be used for:

6. Implement and validate decisions The determination of the alternative for action, i.e. the implementation of the decision, is based on these preparatory considerations. Of course, it must be tested whether the formulated rules always deliver the correct technical result. Possibly, adjustments are still required.

In the personal area, we are probably familiar with one or the other situation in which we try to prepare the most rational decision possible. Let’s think e.g. of buying a new car. We carefully gather criteria such as price, capacity, consumption, maintenance intervals, CO2 emissions, etc., in order not to sign the purchase contract for the super-affordable, ecologically superior car from the Far East that would comply, but to prefer a brand to which we have an emotional connection.

These decisions, which are not so rare in private settings, cannot be automated to your satisfaction. But decisions in which emotionality can / should / must be left out can certainly succeed. This requires hard facts, reliable data and values that must be collected.

How have we decided so far?

In organizations where resources are not infinite (i.e. in all), decisions must be made. However, how these decisions are made is not uniform. There are numerous ways to make decisions.

Directions

“We ask the boss” is heard more often in many patriarchal organizations. However, this is poorly scaling because the decision-maker becomes a bottleneck at some point (many companies fail in growth phases, but this is worth a separate blog post).

Larger companies have delegated decision-making powers these days, giving a little power to subordinate units (mostly managers). In such contexts, attempts are sometimes made to rationalize and justify decisions by using different methods of decision making. Examples include cost-benefit analysis, scoring models and decision trees.

For decisions that are repeated frequently, companies then issue regulations on how an individual should decide. Examples of this can be: accepting gifts, releasing orders, signing commercial correspondence, authorization to represent, and much more.

Subject-related, these regulations are often compiled in the word processor of choice, sometimes coordinated and stored on the file server. They are easy to read in their design, but they are described in textual terms and are not always free of interpretation. In well-organized companies, the new regulation is also made known to all employees. Not every company succeeds in suspending the old regulation and actually withdraws it. If some time has passed and the employee must look up the regulations briefly, finding them is not a success for everyone. Frequently there are inquiries á la “Can you please send me the purchasing regulations by email?”. And whoops, another digital copy of the document is roaming around the company without it being subject to document control.

In order not to have to consult a regulation every time when making decisions, some companies handed over to software in order to automatically make a correct (buzzword: compliant) decision.

Software

Automated decisions already exist today. These decisions are made by software applications. How these should be met was defined in the requirements recording, the programmer then implemented it and hopefully tested it well. Basically, there is not much to be said. However, developments in recent years have made it clear that decision-making is subject to regular adjustments in its general structure and in individual rules. And software developers do not like to adapt program code (especially if it is not their own). Exacerbated by software developers who have sometimes dropped out, it is no longer apparent how the details of the rule work, since they are now hidden and compiled in the source code (we prefer not to go into the need for good documentation and good practice here). With ‘historically grown’ applications, one occasionally hears that employees have no idea why an application reacts the way it does. Even employees who master expressions such as ‘if-then-else’, ‘switch-case’ etc., shy away, because ‘never touch a running system’. So adaptability is out of the question.

But of course, computer science has offered solutions for this in recent years. This is how technologies came into being that allow the outsourcing of ‘declarative rules’ and incorporate them into the program code using a technical interface. These technologies were sometimes called ‘expert systems’, ‘knowledge-based systems’ or finally ‘business rules management systems’ and fundamentally improved the situation. However, these technologies were not generally successful, because although they were supposed to be ‘business rules’, they were actually ‘technical rules’. Their functionality and their operation required a high level of technical understanding (in the end again a software developer) and the ability to implement business requirements in these ‘technical rules’. In addition, due to their granularity, as the number of rules increased, they became huge and complex. And so, in the event of necessary changes, you didn’t really want to do this afterwards, since side effects were again difficult to control. In addition, there were certainly a few architectural flaws that made a hard coupling to data necessary and the desired performance could not be achieved in the end.

Most recently, IT made a move on decision management. This further developed approach now promises to improve the shortcomings of rules management, to continue to represent and integrate outsourced decision-making logic and at the same time to bridge the gap between the departments and the technology. The comparatively new standard ‘Decision Model and Notation’, or DMN for short, shows its strengths here.

What is the Decision Model and Notation (DMN)

In the past one and a half decades, the Object Management Group (OMG) has created numerous modeling standards that claim to be usable both for technically capable and for non-technical target groups. These modeling standards include the ‘Business Process Model and Notation’, BPMN for short, which has developed into the defacto standard for modeling structured processes. The ‘Case Management Model and Notation’, or CMMN for short, for weakly structured processes (casework) also continues to develop successfully and complements the application scenarios in process management. However, the ‘Decision Model and Notation’ (DMN) has experienced the most dynamic development in recent years. These standards together are also known as the triple crown (the three crowns) of business process management.

The DMN is a common language for business users and ‘softworker’ to describe decision requirements and decision logic in a common vocabulary. The standard includes a visual representation on the one hand, and model-driven aspects on the other, which ensure a sufficiently logical description of the decision.

The means of the DMN allow a technical detailing that is precise and semantically clear enough so that the rule can be executed directly from the model without the need for technical adaptation or implementation. The DMN standard is preparing to become the de facto standard for decision modeling.

It can be seen that more and more software providers from the business rules and decision management segment are adopting this standard. The advantages are apparent:

1. It is a standard that is managed by OMG and not by a software manufacturer alone. OMG has decades of experience thanks to successful standards such as UML, SysML, BPMN and others. The DMN standard is already supported by several software manufacturers and thus already resolves dependencies on the manufacturer.

2. The decision-making process is based on a model that provides the common vocabulary for the business side and the IT side. Misunderstandings during the initial implementation are avoided and the later adaptation speed improves through the common vocabulary.

3. Despite the relatively young age of the DMN (first published in 2015), it was developed by experienced people from the business rules sector and the experience from the BPMN has also been incorporated. There are now modern, high-performance and lightweight decision engines on the market for automated decision execution.

Why should you use the DMN?

The DMN standard is certainly not yet as mature as the BPMN, but is very popular and is currently being actively developed. Nevertheless, the DMN is already in use in numerous organizations worldwide. Holding back is therefore not necessary, because the DMN provides great benefits:

• Easy readability for non-technicians
• Better control of (automated) decisions
• More flexible adjustments and easier impact analysis
• Greater availability of skilled workforce
• Better interaction with other technologies
• Good basis for (Attention! Buzzword :) Data Analytics and Artificial Intelligence
• Avoidance of manufacturer dependency (vendor lockin)
• Reduced implementation costs and shorter implementation times
• Consistent decisions across different channels

Where can the DMN be used?

The DMN can be used for all decisions that meet the following definition:

A decision is a non-situational and deliberately chosen alternative based on known pre-selection criteria that cannot be influenced.

What could this be specifically? A non-exhaustive — rather as a suggestive — list of use cases may give hints:

• Validation — Sufficient information is available to further process an operation. For example: Missing certain mandatory information for the later processing process
• Abuse — The combination of different evaluation criteria indicates a likelihood of abuse. For example: The criterion number of withdrawals per day and amount of withdrawals per transaction and contact point (ATM or stationary retailer or online retailer) allow suspicion of abuse.
• Rating — The evaluation of various criteria allows an assessment, such as: Who is the most important contact person for my customer
• Clearances — Approval is possible under the given conditions. For example: Are all test results with admissible values available to allow a drug for the next development phase.
• Risks — Allow the given criteria for risk assessment. For example: Age, state of health and occupation can provide information on risk classes with accident insurance
• Calculations — Calculation components that are dependent on certain criteria can be offset. For example: An existing domestic customer with good payment behavior gets a higher discounted price than a new customer abroad.
• Routing — The assignment of things can be based on various criteria. For example, a ship entering port may be piloted to a certain point of deletion depending on its cargo, length, width and draft.
• Personalization — The (presumed) affiliation of a person or group allows individual adjustment of services. For example, website content could be displayed according to personal preferences.

All of these types of decisions result in an alternative action that can provide relief for an organization and create the opportunity for scaling. In all cases, decision modeling can be done with DMN. The possibilities offered by this modeling language are described below.

What can I express with the DMN?

The expressiveness of the DMN offers everything that is needed to make the business and IT side ‘happy’. On the one hand, the rule description is visual enough, on the other hand, it offers everything that can be precisely described for the execution.

There are two main areas within the notation. On the one hand, we speak of requirements for decisions, which are expressed in a so-called decision requirements diagram (DRD). On the other hand, the individual decision rules are described (which ultimately describes the decision logic and may become a bit technical in the process).

Determine decision requirements with DRDs

The Decision Requirements Diagram (DRD) is a good tool to first determine the details of decisions (e.g. in a workshop). Decisions — which are sometimes considered to be complex — are modeled to identify the structure of the decision and the requirements for decisions.

The diagram below shows a simple example that includes all relevant symbols of a DRD.

The model reads as follows. There is a top-level decision “Maximum Discount” (the actual, relevant decision to determine a maximum discount), which in turn is based on input information. This in-depth information can either be hard facts (such as “Value”), or the result of upstream decisions “Strategic Account” and “Customer Type”. These upstream decisions are in turn fed by in-depth information “Region” or “Industry” as well as “Potential” and “Turnover”. In addition, the model was supplemented with knowledge sources “Internal Discount Policy” and “Internal CRM policy”. These sources of knowledge document where certain requirements for the rules come from and thus enable the rules to be understood. In addition, business knowledge “corporate classification” is referenced. This business knowledge can in turn be its own rule description, but described in another file.

Specification of decision logic

Based on the DRD, the defined detailed decisions, i.e. the rectangular boxes, can now be specified further. Now it is necessary to describe which options for action should be derived based on which input data. The easiest way to describe this is as an if-then relationship. To describe these if-then relationships, several specification options are available within the DMN. The DMN knows the specification of decision logics using decision tables, boxed expressions and is also open to other logic descriptions. In the following, however, we restrict ourselves to the decision tables, since this is certainly the most common logic description and can also be used most easily by non-developers.

The table above is subject to a certain structure, which we want to describe line by line below.

• Header: In the header, the evaluation methodology (hit policy) of the table (here “U”) is followed by input data and output data
• Second line: The data is specified more precisely in the second line. Labels are given for 1 to n input data. Furthermore, the names of the options for action (output) and the rule results 1 to n rule results are given. Possibly. these are supplemented by technical expressions such as variable names and, if necessary, sets of values to enable later execution.
• Third line: The third line contains data types that declare whether an input value contains, for example, a character (string), numerical values (integer) or others.
• Fourth and following line: Rules are described from the fourth line onwards. Here you can usually find a consecutive numbering of the rule and then concrete input data as well as the resulting options for action (in general, rule results)

IF (data1 =”A” AND data2 = 1) THEN output1 = „Red” AND output2 =”bold”

Decisions have of course also a name (“Decision1”) and a technical identifier (“Decision_example”).

The decision table is read as follows:

If the requirements data1 = “A” and data2 = 1, then the action option (control result) output1 = “red” and output2 = “bold” will be returned. Since the evaluation logic “U” (unique) was selected, only this one rule applies to the transferring requirements (input data).

By adding further input and output columns, a very comprehensive control logic can already be described with a decision table. Illustration 5 also shows that not only input data can be passed on to a decision, but also the results of up-stream decisions. This nested structure, which is visible at the DRD level, allows even the most complex decisions to be represented.

Other evaluation logic can also be selected in the DMN. So exist:

• U(nique) = Exactly one line must apply
• A(ny) = Any number of lines can apply, but must then return the same result
• F(irst) = The first goal that applies determines the outcome
• P(riority) = The line with the highest priority applies

In addition to these ‘single hit policies’, there are also ‘multiple hit policies’ which span an even wider scope of the decision table.

• R(rule) = List the results in the order of the table rows
• C(ollect) = List of all results in no order. Optionally, these results can be processed further: + (Sum), < (Minimum), > (Maximum), # (Number)
• O(utput order): List the results in order of priority

In order for the decision table to be finally executable, formal specifications are then required, for which the DMN has provided a language called FEEL. The so-called ‘Friendly Enough Expressen Language’ is strongly reminiscent of Excel because it contains operators such as>, <, = but also value ranges [0..10]. (Further information under https://docs.camunda.org/manual/7.12/reference/dmn11/feel/)

Now that the most complex rules have been modeled in DMN, we can save our rule description as an XML file. This data format is used by all decision engines.

If you would like to try out the created file on a decision engine, you can try out the camunda DMN simulator, for example (see adjacent box). The simulator uses a decision engine in the background. Excellent for testing and trying out. So-called decision services are usually implemented in operational real operation. This is usually web services that offer the execution of business rules. A DMN recommendation is to provide a decision service with all required input data when calling it up. The rules engine never procures data itself and does not call up other systems itself.

How will be decided from now on?

Directions

The DMN creates the basis for automated decision making, but not only. It may well be that the automation effort is not (yet) worthwhile. However, this would not be a reason not to use the DMN and to stick to the old description types (see Illustration 2) for regulations. Perhaps it is simply not yet clear when the automation will take place. Another aspect is to introduce a company-wide language for the formulation of rules. The common language already provides considerable advantages within communication even without automation.

So why not present the signature rules for procurement in the future as follows:

Anyone who already uses other OMG modeling standards such as the BPMN or CMMN will identify the DMN as a useful addition. Without going into details of these modeling languages, we still show two examples for clarification. The ‘connoisseur’ will find further documentation on this.

A rule task exists in BPMN, which calls for an externally implemented rule execution. This rule execution could have been implemented in DMN, for example. This would look like this in the model:

So-called sentries exist in the CMMN. These are input and output conditions that must be met. Whether this is fulfilled can be checked via DMN. In the model, this could look like this:

These examples should serve as a suggestion, but also make it clear that the DMN can be seamlessly integrated into the other OMG standards. It becomes clear why BPMN, CMMN and DMN are referred to as the ‘Triple Crown’ of the BPM.

What else needs to be considered?

Organisational issues

Regardless of whether decisions are made humanly or technically, i.e. automatically, it is helpful to think about the following questions.

The smaller the part of those who took responsibility for these questions, the closer one approaches decision management, in which decisions are planned, implemented, checked and readjusted. The following benefits result from this:

• Speed up decisions
• Greater transparency
• Organizationally anchored ensuring compliance
• Continuous improvement of decisions

Bernd Rücker has outlined a decision management control loop as an iterative approach to decision management:

Last but not least, this results in an advantage of the DMN, because the decision-making can now be managed by a central body that may not be burdened with further sovereignty or that has no conflicting objectives to clarify in this regard. For example, processes and decisions can now be given separate governance (responsibility allocation).

In addition, you can develop your own steering processes that ensure that all relevant stakeholders are involved in the creation, approval, publication, override, etc.

Jurisdiction

In order not to obscure a legal point of view through our amateurish formulations, we quote below the State Commissioner for Data Protection and Information Security North Rhine-Westphalia on the subject of scoring (skip the box if you are not German-speaking!):

The last sentence has it all. “In addition, companies that use automated individual decision-making processes are obliged to inform those affected about this fact.” To use automated decisions using scorings (which can definitely be implemented with the DMN), you better know the regulations of data protection law.

Conclusion

The article shows that the automation of decisions is no longer an unsolvable undertaking. DMN plays an important role in this since it is not only a good communication tool to bring about clarity and transparency but is also suitable for technically implementing (i.e. automating) decisions based on the model. So there is no longer a need to stick to paper-based rule descriptions. Implementation on DMN — whether for automation or not — is therefore worth considering.

However, the article also shows that real ‘decision management’ must not only be driven by technical perspectives. ‘Management’ also means that organizational considerations are necessary that enable planning, implementation, review and adaptation of the regulations. Last but not least, legal considerations are relevant for some decisions.

Sources:

• Trisotech (o.D.): https://www.trisotech.com/articles/from-business-rules-to-decision-management-using-dmn
• Rücker, Bernd (2016): in Jaxenter: https://jaxenter.de/der-brueckenschlag-warum-dmn-den-business-rules-engines-markt-aufmischt-37252
• Dittmann; Jorch (2016): https://www.sigs-datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht/artikel-titel/dmn-neuer-anlauf-fuer-business-rules-den-markt-zu-erobern.html
• OMG DMN: https://www.omg.org/spec/DMN/1.2/PDF
• Taylor (2019): http://www.decisionmanagementsolutions.com/core-principles-for-decision-management-success-in-insurance-claims-handling/
• LDSB NRW: https://www.ldi.nrw.de/mainmenu_Datenschutz/submenu_Datenschutzrecht/Inhalt/Scoring/Inhalt/Antworten_FAQ_Scoring/automatisierte_Einzelentscheidungen1.php

Fore more thoughts on BPM in German visit www.mi-nautics.com

Originally published at https://www.linkedin.com.