openskills.info
Course catalog
Business Rules and Decision Modeling logoCourse Preview

Business Rules and Decision Modeling

Business rules and decision modeling is the practice of writing down the policies an organization uses to make repeatable operational decisions, such as eligibility, pricing, or routing, in a precise and testable form. Decision Model and Notation (DMN), an OMG standard, supplies diagrams, decision tables, and an expression language so the same model can be reviewed by business experts and executed by software.

itEngineering leadership and delivery management

Don't Panic: Business Rules and Decision Modeling

Somewhere in every organization, a policy decides who qualifies, what things cost, and which team gets the awkward case. Those policies are business rules, and they tend to end up buried in application code, where only developers can read them and every change waits for a release. Decision modeling is the practice of digging them back out and giving each decision a name, a list of inputs, visible logic, and a defined answer.

The standard that makes this shareable is DMN, short for Decision Model and Notation, from the Object Management Group, the same people who brought you BPMN. It works at two levels. The top level is a diagram of which decisions exist and what each depends on. The bottom level is the actual logic, spelled out precisely enough for a machine to run.

The diagram has a small cast. A decision is a rectangle. Input data, the facts arriving from outside, is an oval. Reusable logic, called a business knowledge model, is a rectangle with two corners clipped off, as though someone took scissors to it. A knowledge source, meaning the regulation or policy owner who gets the final say, has one wavy edge. Follow the lines from a knowledge source and you find every decision a policy change will touch, which is the kind of question nobody can answer from a pile of code.

Most of the logic lives in a decision table. Each row is a rule, each input column holds a test such as < 18 or [600..750], and a dash means "this input does not matter here". The table is best understood as a map from every possible input to an answer, and nearly all the real work is inspecting that map for holes.

The holes are where it gets interesting. When no rule matches, the table does not complain. It returns null, and a caller that ignores null makes a wrong decision with total confidence. When several rules match, a single letter called the hit policy decides the outcome. Unique, the default, forbids overlaps outright. Priority lets an exception beat a general rule. First takes whichever matching row comes earliest, which means shuffling rows changes answers, and the standard itself frowns on it.

The surprise for most newcomers is that the notation is the smaller half. The hard half is getting two experts to agree whether "orders over 100" includes 100, because every boundary in a table forces a choice the written policy may never have made.

There is an older way to run rules, too. Engines such as Drools fire when-then rules over facts in working memory, and one rule can change a fact that sets off another. That is expressive, and also how rule bases become puzzles. DMN decision services are stateless: same inputs, same outputs, every time.

Start with the Slides for the overall map, then keep the Cheatsheet open for hit policies and table syntax. The Field Notes cover what goes wrong in practice, and the Exercise has you build a shipping-fee table and break it on purpose.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources