Decision Management (ODM, ADS)

Posts in the series:

1. Benefits of Decision Modeling
2. What is a decision model and what is DMN
3. Decision Modeling: Decision Requirements [this post]
4. Decision Modeling: Decision Logic
5. Decision Modeling: Finding and modeling decisions
6. Decision Modeling: Input Data and Knowledge Sources
7. Building decision tables from decision models
8. ML, AI and other forms of Data Analysis and Advanced Analytics

--

The most important piece of a decision model is the set of Decision Requirements Diagrams that define it. Each Decision Requirements Diagram is a visual representation of a network of elements. The core of a decision requirements diagram is a simple palette of three shapes and two lines. This simplicity is one of its strengths, allowing even very complex solutions to be described in a way that is easy to learn.

The three shapes are Decisions, Input Data and Knowledge Sources:

• Decisions are the basic building block, each representing a decision (or sub-decision) that must be made. It is often helpful, as we will see, to think of each decision as a question to be answered and a matching set of possible or allowed answers.
• Input Data objects represent data passed to the decision-making from outside. This is generally raw data about a customer or company or transaction that must be processed into order to make the decision. Input Data can be as simple as a single field, as complex as a large XML document. These two shapes are linked into a network using one of the two lines – Information Requirements.
• Knowledge Source objects are exactly what they sound like– sources of knowledge from which the decision model’s details can be derived. Think of these as complex annotations – ways of documenting sources and policies, analytic conclusions or human experts and linking them to the decisions they influence.

The two lines that matter are Information Requirements and Authority Requirements:

• Information Requirements are the core of decision modeling. An Information Requirement is a solid arrow always points to a decision and shows you that the decision at the pointy end REQUIRES information at the blunt end – either information represented by Input Data or information produced by making another decision. It’s not enough that information is available, it must be required – it must make a difference to how the decision is made. You must have at least one circumstance in which the value of that required information changes the outcome of the decision.
• Authority requirements link Knowledge Sources into the model using dashed lines with round heads. The most common use is to show which Decision(s) are influenced by which Knowledge Sources so that, for example, you can see which decisions include rules derived from a particular policy document. Many other relationships can be shown too including how different policies relate to each other, how a particular ML model was developed or how to decide a policy might need to be updated.

Besides these core shapes, you can add annotations – a sticky note if you like – and groups to lightly associate a set of objects on the diagram. Annotations can be free-floating or linked to an object or group.

Note: there are two other shapes (Business Knowledge Models and Decision Services) and one other line (a Knowledge Requirement), but these do not matter when defining requirements as they only play a role in execution. I’ll cover them later.

So how does this come together in a diagram? Well, here’s an example from one of our demo projects (based on a real one):

In this diagram we see that we are deciding how complex a claim is (Claim Complexity decision) and that deciding this requires us to decide how complex the treatment is, how complex the claim history is and how complex the diagnosis is. We can see that treatment complexity is based on the maximum severity and total number of treatment codes on the claim (both calculated from the list of codes associated with the claim). The simplified history complexity decision only uses the number of claims related to this one in the last 12 months while the diagnosis complexity is based on the number of diagnosis codes, how many are consider catastrophic and any comorbidity complications from pairs of codes. So far only three knowledge sources – the surgical and diagnosis complexity references and the expertise of the claims team – have been identified.

With a simple, one page picture we’ve outlined exactly how this decision is going to be made. Excellent.

Real problems, of course, have a lot more pieces to them and so you’d expect to see lots more decisions, input data and knowledge sources – all linked together into what we call a requirements network. DMN treats all these requirements – the whole network - as parts of a single whole: a Decision Requirement Graph. Having all the objects in a model be part of the same graph is important for several reasons:

• It allows you to reuse decisions, input data and knowledge sources so each is represented once and once only, eliminating duplication and confusion.
• It tracks all the places something is used, enabling strong impact analysis – if several decisions use the same piece of input data, the input data “knows” this and the impact of changing it is clear.
• It lets you link your decision logic, your rules, to an underlying structure helping to keep them consistent, simple, and normalized.

This graph can get large for significant models, so DMN does not require that every piece of a graph be shown on any specific diagram. You can build many diagrams and each diagram is a view on the underlying graph or model. No diagram needs to be complete, but all diagrams in the same model must be consistent. They cannot contradict each other because they must share the set of underlying objects. DMN even has a notation – a set of ellipses… like the ones on Claims Complexity above - to show that an object on a diagram has links, requirements, that are not displayed on the current diagram.

The other layer in a decision model is the decision logic layer and I’ll cover that in the next post.

If you want more detail, you can get a text book on the approach (written by me and Jan Purchase): Real-World Decision Modeling with DMN 2nd Edition. If you or your company need help with decision modeling, drop me a line james@decisionmanagementsolutions.com and we can schedule a quick call to discuss. And if you’re excited about decision modeling and keen to do more, why not join DecisionAutomation.Org and participate?

#IBMOperationalDecisionManager#OperationalDecisionManager(ODM)#AutomationDecisionServices(ADS)#DecisionManagerOpenEdition#DMN#IBMChampions#decisionmgt#DecisionAutomation