Decision Management (ODM, ADS)

Modeling operational decisions

Often operational decisions are made in the code of enterprise applications, which makes it difficult to access and modify them. When the policies that govern the operational decisions are expressed in code, updating them is not only costly but it also requires specific IT expertise. Even the smallest tweak (changing a minimum credit score from 600 to 620, say) can take months to come online. And by that time things might have changed again.

Decision modeling can help you loosen this Gordian knot, and maybe slice right through it. It is a straightforward and code-free way to express—and refine—your operational decisions through a structured, visual representation of a decision. Using this approach, business experts and IT specialists alike can model operational decisions by specifying:

• the information you use to make decisions
• how to make the final decision with that information—the decision logic

With decision modeling you have a direct, hands-on way to describe operational decisions in a form that can be used right away by your enterprise applications, replacing the traditional code-based implementation. That is, you regain control over the decision logic, and when that logic goes live.

Imagine you want your online shop to apply a discount to customers. The underlying application applies the discount—the operational decision—according to the decision logic that that you define in your decision model. If you want to add extra discounts for a new promotional campaign, you just edit the related discount decision, and as soon as you’ve deployed your updates the application applies discounts in line with the new campaign.

Decomposing decisions

Basically, modeling a decision involves breaking it up into a series of smaller decisions.

If our online shop offers discounts depending on things like the number of items in the basket, the total undiscounted price, the customer’s loyalty, the time of the day, and so on, each of these factors can be used to make simple decisions that all together make the overall discount decision. The customer loyalty discount—5% off for Bronze members, 10% off for Silver, and so on—is a smaller decision that contributes to the result of the final decision, which takes all the factors into account.

Decomposing a decision into smaller elements isolates its building blocks and shows how they relate to each other. It makes it easier to understand the logic at stake, define it in a straightforward way, and adjust it when things change. It’s also an opportunity to avoid reinventing the wheel. Chances are that the smaller decisions can be aligned with policies already documented within your organization; the discounts for customers in the loyalty program is probably already defined in the loyalty program’s charter.

As you break up a decision you reach a point where you need information to inform your decision. The customer’s membership of the loyalty program is not a smaller sub-decision, it’s information—input data—you need to make the decision. Input data can come from an external system, such as a client database. 

Representing decisions graphically

The standard way to represent a decision model is as a decision model diagram, which lays out the decision points, called nodes, and the dependencies between them. It also shows the input data used in making the decision. The diagram below shows a simple discount decision.

From top to bottom:

• The overall discount depends on the status discount and the volume discount.
  
  
• The status discount depends on the customer status, and the volume discount depends on the quantity of items. The customer status and the quantity are what you need to know to make a discount decision.

The diagram is high-level and doesn’t give actual values for its elements. It shows how the decision is made of simpler decisions and the data you need to make the decision.

Notice that each node has a type that tells us what kind of result we’ll get from the node. For example, the discount sub-decisions, status discount and volume discount, give a number -- a percentage (such as 12% or 0.12). The input data is also typed: quantity is an integer (a whole number), and customer status comes from a list of the possible loyalty statuses (for example Bronze, Silver or Gold).

Each decision node gives a value that nodes further up the diagram can use. In our discount example, the final discount node specifies how to use the numbers from the status discount and the volume discount to compute the final discount.

Defining the decision logic

Once the high-level diagram is in place you can start to define how each node arrives at its result.  Generally, you have two ways to do this: decision tables and business rules.

Decision Tables

Decision tables link conditions with the resulting actions. In the discount example, we could define the logic for the status discount node like this:

The Customer status column gives the condition, and the Status discount column gives the corresponding result for the node. If customer status is bronze, there is no status discount, if it’s silver the status discount is 5%, and so on.

We can use a decision table for the volume discount node too, but here the condition is based on ranges of values:

If quantity is between 0 and 1500, no discount is applied, for quantities between 1,500 and 3,000, the volume discount is 5%, and so on.

In general, decision tables are best when you can list the all the cases and their corresponding values. And you can create more sophisticated decision tables by grouping multiple conditions and actions.

Business rules

When you can’t list all the possible cases, or your policies are more complex, you use business rules.

In a nutshell, a business rule is a policy statement written in “an almost natural language”. It describes how to get the result of a node using the available data, which might include the results of other nodes.

In our example, the final Discount decision is where you bring together the status and volume discounts. One way to it would be to just add them:

But your policy might be to offer the highest of the two discounts, so you could write it like this:

Of course, there are many ways to combine the discounts to get the final discount. Business rules give you the flexibility to express the logic of your decision just how you want.

Decision modeling at your finger tips

Part of IBM Cloud Pak for Automation, Automation Decision Services gives a fully-fledged decision modeling environment for business experts, to help them take control of the decision-making process. Designing decisions, defining the driving business logic, and validating them is just a few steps and clicks away.

With decision modeling in Automation Decision Services, you have a powerful and easy-to-use tool to:

• Visually represent the structure of an operational decision, its parts, and their dependencies. This is where, you break down your operational decision into more manageable intermediate decisions.
• Define the underlying business data model—the kinds of things involved in making the decision. In our discount example the client, the client status, the product, and the quantity are types of business data. They aren’t automatically available, because they are specific to the business domain.
• Author the rules used to arrive at the decision.

And of course, once that’s done Automation Decision Services includes features for you to validate your decisions right away and standard DevOps tooling to deploy them into executable decision services for production and automation.

Want to see more?