IBM WODM Decision Design

∗ Use business rule modeling tools in WODM to build complex decision services.

∗ Gather all of the necessary pieces of information to: ∗ Make the decision ∗ Decompose the overall decision process into a set or

organized subtasks. ∗ Define each subtasks a set of business rules.

Decision design during Service Lifecycle

∗ Action verbs, such as determine, check, calculate, evaluate, decide, and so on, that are applied to business objects typically indicate the potential for a decision point. ∗ Validate quote request data. ∗ Determine driver eligibility. ∗ Compute quote pricing.

Identify business decisions

∗ After the set of decision point is decided and before creating a rule project, firstly identify conceptual object model for representing decisional context information and capture the decision response while harvesting initial business rules.

Defining the domain of discourse for the rules

UML Class Diagram

∗ Conceptual object models accommodates two characteristics: ∗ Cover all the details needed to make

the decision ∗ while staying understandable to the

business users.

∗ After a first workable version of the conceptual model is available, it can be transformed into an execution Object Model(XOM).

∗ The XOM represents the model of the data that is passed to the decision when it is executed. ∗ The rules are applied to this model.

Tailoring the model for the business users

∗ A Business Object Model (BOM) is built on top of XOM.

∗ A BOM associating verbalizations with classes, attributes, and methods is intuitive for the business users.

Rule Designer

A BOM class structure

∗ Setup a common rule project without rules for making a sharable BOM. ∗ Other rule projects reference to this shared rule project. ∗ According to decision needs, the inheretant rule projects

can mask irrelevant information of parent rule project.

Sharing a common model across decisions

∗ After the BOMs is defined, the decision signature is established by defining the interface of the decision to the outside world. ∗ Define what data a decision need as input and what data a decision

returns as the output.

Establishing the decision signature

These type information are drawn from a

BOM.

∗ A complex decision is composed of multiple subtasks. ∗ Decompose decision into subtasks and organize the sequence/flow of the

subtasks. ∗ Each subtask is usually a group of rules.

∗ Eligibility decision performs a group of validations: driver’s age , driver’s perceived risk, and driver’s profile.

∗ Place the functional group

s of rules into a sequence using a rule flow.

Decomposing the decision and orchestrating the subtasks

A rule package

∗ The business rules are written to recognize a pattern in the context of information provided to the decision. ∗ A set of actions is triggered when the rule conditions are satisfied.

Authoring business rules by business users in Decision Server

Decision table encompasses multiple rules sharing a template of conditions and actions

Simple if-then-else rule expression

∗ Package up all decisions in a rule project and then deploy to Rule Execution Server.

∗ A common way to expose a decision to potential clients is through a decision web services.

Decision integration

Any questions ?