Back to www.openrules.com
 

THE DECISION MODEL

A LIVE PRIMER

             Copyright 2009 Knowledge Partners International, LLC.

(Portions of this document are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, 2009 Auerbach Publications/Taylor & Francis, LLC. Reprinted with permission of the Publisher.)

8 Calais Road

Mendham, NJ 07945

Phone: +1 973 543 1339

Fax +1 973 543 7037
www.kpiusa.com


OpenRules, Inc. with permission of Knowledge Partners International, LLC. modified the original PDF document by replacing Rule Families with executable Excel-based OpenRules tables. This document is accompanied by a basic OpenRules rule project "DecisionModelPrimer" that may be downloaded from here. A reader may execute different a decision model while reading this primer, make changes in the rule families and test data, and may immediately analyze the results of executing rules. If you want to use The Decision Model you have to make sure that you are in compliance with its Patent Policy.

www.openrules.com

Table of Contents

Introduction

Decision Model Fundamentals

What Is Business Logic: Business Logic Fundamentals

The Structure of Condition and Conclusion Assertions

What Is a Fact and a Fact Type?

What Is an Operator?

The Structure of Business Logic as Conditions and Conclusions

What Is An Atomic Business Logic Statement?

Why Are Atomic Business Logic Statements Important?

Grouping business Logic Statements into Rule Families

Rule Family Structural Features

What Is a Rule Pattern?

Representing Rule Families in OpenRules

Executing Rule Families

The Agility of the Rule Family

Where Do The Fact Values Come From (Input)?

The Decision Model from the Top Down

What Is a Business Decision?

What Is the Difference Between a Business Decision and a Conclusion?

Business Decision Scope

The Decision Model has Principles, and is Normalized

Conclusion

Introduction   ►top

The Decision Model is a way of representing business logic that is platform and technology independent. It models logic based on the inherent structure of that logic, eliminating style and other subjective preferences, ensuring a consistent and stable representation. This is a brief introduction to the Decision Model that will enable you to read and understand Decision Models, perhaps even develop them yourself.

For details about the Decision Model, we refer you to the book from which these concepts and ideas (and many of the tables and diagrams) are drawn, “The Decision Model: A Business Logic Framework Linking Business and Technology” (von Halle & Goldberg) 2009 Auerbach Publications/Taylor & Francis, LLC. Reprinted with permission of the Publisher.

Business logic is often popularly referred to as “business rules”, but we are sure that by the time you have completed this guide you will feel comfortable with our preference for the term “business logic”.

OpenRules v.6 allows business analysts to represent the Decision Model directly in Excel, and to execute and test it without any coding. Then resulting Decision Model can be easily integrated in any Java-based or .NET environment. For more information see www.openrules.com.

Decision Model Fundamentals    ►top

The simplicity and elegance of the Decision Model can be best learned by building the model from the ground up. This typically is not the way you might create a Decision Model in real life, but for illustrative purposes, this approach provides an excellent perspective and understanding of the model.

What Is Business Logic: Business Logic Fundamentals     ►top

First, let us define the term “business logic”; Business logic is the means by which the business derives conclusions from facts. So, building from that definition, we may say that a “business logic statement” is an expression of conditions that evaluate facts leading to a conclusion of a new fact. We can illustrate this by the simple diagrammatic representation of a business logic statement in Figure 1.

Figure 1 A Diagram of a Simple Business Logic Statement

This diagram faithfully follows our definition: we see that the condition statement contains a fact, which we evaluate for truth: it leads to the conclusion statement that we infer to be true if the condition statement is true. Thus we are lead to a conclusion of a new fact. A simpler way of diagramming Figure 1 may be found in Figure2.

Figure 2 Simpler Diagram of a Simple Business Logic Statement

This diagram is really the same as the one in Figure 1, but it simply indicates that the business logic statement is independent of the grammar we may use to express it – so we could use the “when…then” form, we could use the “if..then” form, or we could state it in other declarative forms such as “The ….shall..” and so on. We say that the condition is an assertion, and when this condition assertion is true, then the conclusion assertion may be inferred to be true. We may simplify the diagrammatic representation of the business logic statement even further, to its simplest form, as represented in Figure 3 in which the arrow represents the concept of “implies” or “infers” or “concludes.”

Figure 3 Simplest form of Diagrammatic Representation of the Business Logic Statement

This diagram is the simplest clearest representation of a business logic statement, and captures its declarative essence. But enough with the diagrams! We need an example to make these concepts concrete. Let’s construct a real business logic statement.

Figure 4 An Example of a Business Logic Statement

In Figure 4 we have a good example of a simple business logic statement. This statement tells us that the business wants to conclude that a person who has a poor employment history is highly likely to default on a loan. Our condition assertion is “A person has a poor employment history”, and when this assertion – or fact – is true, then we know that the assertion “A person is highly likely to default on a loan” is also true. We could express this business logic statement in a natural language statement as “When (or if) a person has a poor employment history, then that person is highly likely to default on a loan.” (The logic in the natural language statement and the diagram are exactly the same).

The Structure of Condition and Conclusion Assertions    ►top

Each assertion is composed of:

  • Facts

  • Fact Types

  • Operators

What Is a Fact and a Fact Type?     ►top

Table 1 Examples of Fact Types

We say that a fact (or, more accurately, a fact value) is a piece of information (i.e., a piece of data within a context). Take the example:

        “The Person has five years at his current employer.”

The piece of information is the value “five” (fact value) in the context of years at current employer for the person. So the fact value in this statement is “five.” Simple enough. What about the rest of the statement? All the information that gives context to the value of “five” – “Person’s number of years at his current employer” – is what we call the “fact type”.

The following phrases are important to remember:

  • Fact type is a general classification of a fact, not the piece of information itself.

  • Business concept is the noun, a thing that is the subject of the fact type.

  • Fact type domain is the range or set of valid values that make business sense for a given fact type.

Table 1 contains some examples of fact types. Fact types play an important role in building the condition and conclusion assertions that make up business logic statements.

OpenRules v.6 has a predefined concept of the Glossary that describes Fact types and related Business concepts and their attributes in a simple Excel table that may look like this one:

Glossary glossary        
Fact Type Business Concept Business Concept Attribute        
Person Employment History

Person

employmentHistory   Good Average Poor
Person Likelihood of Defaulting on a Loan likelihoodOfDefaulting   High Medium Low
Person Mortgage Situation mortgageSituation   Good Average Poor
Person Miscellaneous Loans Assessment miscLoansAssessment   High Medium Low
Person Outside Credit Score outsideCreditScore   Range 0 999
Person Years at Current Employer yearsAtCurrentEmployer        
Person Number of Jobs in Past Five Years numberOfJobsInPastFiveYears        
Vehicle Insured Value

Vehicle

insuredValue        
Policy Renewal Method

Policy

renewalMethod        

This table allows a user to map facts with actual business objects that could be defined in Excel tables, in Java, in XML, or in database tables. For example, we may define directly in Excel table a new data type "Person":

Datatype Person
String fullName
String SSN
String employmentHistory
String mortgageSituation
String  miscLoansAssessment
boolean additionalDebtResearchNeeded
String 

likelihoodOfDefaulting

OpenRules Table: Datatype "Person"

This table formally defines a business concept Person (called "Datatype" in OpenRules). The first column defines type of attributes and the second column defines their names. The attributes may have different types String, int, double, boolean, or Date that are standard Java types.

Now we even may create concrete examples of borrowers with the type Person using a simple OpenRules Data table:

Data Person borrowers
Full Name SSN Employment History LikelihoodOf Defaulting Mortgage Situation Misc Loans Assessment Additional Debt Research Needed
Peter N. Johnson 111-22-3333 Good ? Average High No
Mary K. Brown 444-55-6666 Poor ? Average Low

Yes

OpenRules Table: Data "borrowers"

We will use these people ("borrowers") to test our business rules below.

What Is an Operator?     ►top

An operator, (or more correctly a logical operator) is a symbol – i.e. a word – that connects two assertions and applies a test of truth, through the application of symbolic logic, between the two assertions.

  • Conventional symbols, i.e. logic operators, are ones such as:

    – “Is”, “Is Not”, “Is Less Than”, and so on.

  • There are many others. Most of them are boolean, as we would use in programming, but they can by any logical operator.

The Structure of Business Logic as Conditions and Conclusions    ►top

Now that we better understand the components of assertions, we are ready to delve deeper into the nature of a business logic statement.  We begin by understanding the definition of condition and conclusion:

  • A Condition is an assertion of a specific Fact of a given Fact Type that is to be tested for truth in the Business Logic Statement

  • A Conclusion is an assertion of a specific Fact of a given Fact Type that is true if the Condition assertions of the Business Logic Statement are true

Condition assertions and conclusion assertions have identical structures:

     

  • Operands are frequently a fact value (from the pool of fact values in the fact type domain), but may be a Formula or a Fact Type.

So, take the assertion:

     

We can model it as:

Table 2 has some examples of assertions exemplifying their structure.  It is interesting to see that any of these examples could be either a condition or a conclusion assertion in a business logic statement.

Table 2 Examples Showing the Structure of Assertions

Notice how the operand can be a fact value, a fact type, or a formula. Looking at the operands in Table 2, we see:

  • Fact values are: average, 700, blue, preferred, etc.

  • Fact Types are: person likelihood of defaulting on a loan, policy effective date, and two months of seasonal sales, etc.

  • Formula is [weight (kg) / [height (m)]2

What Is An Atomic Business Logic Statement?     ►top

In the Decision Model, it is critical that business logic statements be atomic.

What is the meaning of the word “atomic” and why is it important?

Well, first the meaning: Atomic means “indivisible”. The word comes from the Greek root “atomos”, first proposed by the ancient Greek philosopher Democritus, who believed that all material in the earth was composed of tiny, irreducible fractions of matter. In our context, “atomic” is used to signify simply a business logic statement that cannot be decomposed (into smaller business logic statements) without losing its meaning. Similarly the concept of atomic may be applied to fact types; an atomic fact type is one that cannot be decomposed (into other fact types) without losing its meaning. Thus we use atomic to denote the irreducible form of a fact type and of a business logic statement.

Why Are Atomic Business Logic Statements Important?     ►top

Reducing business logic to its atomic form is important because doing so delivers only one representation of the business logic and also eliminates ambiguity of meaning: the latter ensures that the accuracy of the logic can be analyzed for precision, completeness, and consistency and is represented in its most manageable form.

So, we say an atomic business logic statement consists of zero to many conditions leading to a conclusion about a single fact type where:

– Each condition is an atomic logical expression about an atomic fact type.

– Conditions are ANDed together, never ORed.

 

Figure 5 Diagram of an Atomic Business Logic Statement

Figure 5 is a diagram of an atomic business logic statement. It has three conditions, joined by ANDs, leading to a single conclusion.  If you examine it closely, you will see that each fact type in the conditions and conclusion are atomic.

If we have definitions for the fact types, the business logic statement is clear, unambiguous and cannot be broken into smaller statements. It may be written out in longer, natural language statements using a grammar that is convenient to the user (or using a grammar standard such as Semantic Vocabulary for business Rules (SVBR) as published by the Object Management Group (OMG)). As examples, here are a few possible natural language expressions of the business logic statement:

  • If/when a person’s employment history is poor and the person’s mortgage situation is poor and the person’s miscellaneous loans assessment is high then (we judge) the person’s likelihood of defaulting on a loan is high.
  • A person with poor employment history and poor mortgage situation and high miscellaneous loans assessment has a high likelihood of defaulting on a loan.
  • A person has a high likelihood of defaulting on a loan if all of the following are true:

    • Person’s employment history is poor.

    • Person’s mortgage situation is poor.
    • Person’s miscellaneous loans assessment is high.

While these may be useful expressions of the business logic for everyday use, the use of natural language may introduce ambiguities, and render the statements non‐atomic. (It is possible to apply a very rigorous grammar to avoid this, but that would mean all business people would have to train in the grammar to write it). Also, it becomes challenging to group the natural language forms of the logic statement in a way that they can be analyzed for logical integrity and completeness. Let’s look at how the Decision Model groups the business logic behind the natural language forms.

Grouping Business Logic Statements into Rule Families      ►top

It is clear from the example in Figure 5 that there are likely to be more business logic statements that conclude a person’s likelihood of default beyond the statement in the diagram.

We need only look to the domain of the fact type Person likelihood of Defaulting on a Loan to understand that there are conditions that lead to a conclusion where the person’s likelihood of defaulting has a conclusion other than high. (Table 1 illustrates a domain for the conclusion fact type, showing values high, medium and low. We should look for conditions that will result in all these values).

Figure 6 illustrates a grouping of three business logic statements with the conclusion fact type Person Likelihood of Defaulting on a Loan.  This appears, on the face of it, a fairly convenient grouping.  However, you can imagine that the logic leading to some conclusion fact types can run into many, sometimes tens, and possibly hundreds of business logic statements. That being the case, figure 6 may not be the most convenient representation for this grouping of business logic statements.

Figure 6 Grouping Business Logic Statements

 

 

  Conditions Conclusion
Rule Pattern Person Employment History Person Mortgage Situation Person Miscellaneous Loans Assessment Person Likelihood of Defaulting on a Loan
1 Is Poor Is Poor Is High Is High
2 Is Good         Is Low
1 Is Poor Is Poor Is Low Is

Medium

Table 3 Grouping Business Logic Statements in Rule Families

Now look at Table 3: here is that same grouping of business logic statements in a single tabular form. This is a more efficient representation of the business logic statements than that in Figure 6. In fact, when this grouping of business logic statements complies with certain principles that bring rigor to the form, this is called a Rule Family, the primary structure of the Decision Model.

One unique advantage of the Rule Family is that it groups atomic business logic statements only by their conclusion fact type. This is possible because we have defined an atomic business rule statement to consist of a single conclusion fact type.

Rule Family Structural Features      ►top

Figure 7 illustrates the structural features of the Rule Family: it is a two-dimensional structure with rows and columns: the header of the columns is condition facts types (called condition columns) and the conclusion fact type (called the conclusion column). Each row is a business logic statement. Our practice is to place the conditions in the left columns, and the single conclusion on the right, although in fact, from a logical point of view, this sequence is irrelevant, and the columns could occur in any order. Also irrelevant is the sequence of the rows: no logic statement has any precedence, and remains logically correct in whatever order they are in. The condition columns are considered to be ANDed, never ORed. (If you are presented with logic statements that have ORs in them, it simply means that they are not atomic, and need to be broken into multiple, separate atomic statements).

Figure 7 Features of the Rule Family

The name of a Rule Family is simply its conclusion fact type. So, the name of the Rule Family in Table 3 and Figure 7 is "PersonLikelihoodOfDefaultingOnLoan".

What Is a Rule Pattern?       ►top

One feature that should be pointed out in Table 3 (and in Figure 7) is the Rule Pattern. A Rule Pattern is a set of Rule Family rows with a common set of populated condition cells. We give each separate Rule Pattern a unique number or name. So you can see that Rule Pattern 1 in Table 3 (and Figure 7) refers to rows that have all three condition columns populated, while Rule Pattern 2 refers to rows that are populated only in the column headed by Person Employment History. The Rule Pattern is an important element in the Decision Model, and is used in validating compliance to many of the principles that bring integrity and normalization to the logic.

Representing Rule Families in OpenRules       ►top

OpenRules uses Excel tables to represent Rule Families - see the Excel file "Rules.xls".  OpenRules usually uses the keywords "DecisionTable" or "DT", but the keyword "RuleFamily" was added to correspond to the Decision Model terminology. For example, the above Rule Family may be presented as follows:

RuleFamily PersonLikelihoodOfDefaultingOnLoan
Condition Condition Condition Conclusion
Rule Pattern Person Employment History Person Mortgage Situation Person Miscellaneous Loans Assessment Person Likelihood of Defaulting on a Loan
1 Is Poor Is Poor Is High Is High
2 Is Good         Is Low
1 Is Poor Is Poor Is Low Is Medium
3             Is Undefined

Here the first (black) row describes the Rule Family:

  • "RuleFamily" - the keyword that is used to differentiate rule families from other OpenRules tables
  • "PersonLikelihoodOfDefaultingOnLoan" - the name of the Rule Family

The logic of this Rule Family can be explained by this statement:

       IF (Condition-1 AND Condition-2 AND Condition-3)  THEN Conclusion

If condition cells have no data then this condition is considered as being satisfied.

Note that this table has one additional row (the last one) that has no conditions and will be applied when all conditions in the above rules (rows) fail - in this case the result will be "Undefined". 

If we apply this rule family to the Peter N. Johnson who is a borrower defined in our test data above, we may expect that return value will be "Low" because this Person has "Good" employment history.

Executing Rule Families       ►top

Now we may specify our simple Decision Model in Excel using the following OpenRules table:

DecisionModel DetermineLikelihoodOfDefaultingOnLoan
Decisions Execute Rule Families
Define Person Likelihood Of Defaulting On Loan := PersonLikelihoodOfDefaultingOnLoan()

This decision model has only one decision ("Define Person Likelihood Of Defaulting On Loan") to make using only one Rule Family ("PersonLikelihoodOfDefaultingOnLoan").

OpenRules is capable to execute this decision model without any additional coding. We only should specify that the object "Peter N. Johnson" from the data array "borrowers" will be used as a test. It can be done directly in Excel by mapping business concepts from the above glossary with concrete objects like borrowers[0]:

DecisionObject decisionObjects
Business Concept Business Object
Person :=  borrowers[0]

Now you may execute this Decision Model by a simple double-click on the file "run.bat" supplied in your "DecisionModelPrimer" project.  It will produce the following results:


Define Person Likelihood Of Defaulting On Loan

Conclusion: Person Likelihood of Defaulting on a Loan is Low

To test how this model works in other situations, you may change any attributes of the object "Peter N. Johnson". For example, open the file "Data.xls" and change the table "borrowers" as follows:

Data Person borrowers
Full Name SSN Employment History Mortgage Situation Misc Loans Assessment Additional Debt Research Needed LikelihoodOf Defaulting
Peter N. Johnson 111-22-3333 Poor Poor Low No ?

If you run the same rule family again, you will receive the following results:


Define Person Likelihood Of Defaulting On Loan

Conclusion: Person Likelihood of Defaulting on a Loan is Medium

Thus, business people without any support from IT may quickly setup a decision model with related rule families, define test data, and execute the model to test for expected outcome.

The Agility of the Rule Family       ►top

Apart from its high level of logical integrity, the Rule Family enables us to express business logic in a form and manner that can easily be read and understood by all stakeholders – business, management and IT. People today are readily familiar with decision tables, and are easily able to read them. Of course, the Rule Family is not a “mere” decision table. It is a decision table on steroids! By this, we mean it is governed by principles which give it rigor, and which you will learn about as go along.

Rule Families are also easy to modify. The ability to easily modify business logic is a key capability to making an enterprise more competitive. In Table "PersonLikelihoodOfDefaultingOnLoan", the first row tells us (as we noted above) that:

  • A person has a high likelihood of defaulting on a loan if all of the following are true:

    – Person’s employment history is poor

    – Person’s mortgage situation is poor

    – Person’s miscellaneous loans assessment is high.

Now assume that in talking to a Subject Matter Expert (SME), we are told that there has been a revision in thinking, and when a person’s employment history is poor, and the person’s mortgage situation is poor, then even when a person’s miscellaneous loans assessment is medium (and not high, as in the Table 3), we should conclude the person has a high likelihood of defaulting on a loan. How do we change the Rule Family? Simple – we change the cell in row one, under the header Person Miscellaneous Loan Assessment to Medium, and we are done. Since no new Java snippets are needed, the SME can make the change and test it without any involvement on the part of IT.

This is illustrated in the first row of Table 4, which is the evolving Rule Family, Person Likelihood of Defaulting on a Loan.

On the other hand, if the SME came to us and said they wished to add a new condition to the logic, in this case an outside credit rating, how would we change Table 3? We need simply to add a new column, with the appropriate heading, in this case the fact type “Person Outside Credit Rating”. Once the column is added, the SME can go row by row and decide what, if any, operator and fact value to add to each cell in order to reach the conclusion in that row.

We can also add extra rows to provide for a new business logic statement that the addition of a condition column may introduce: for example, the SME may say “regardless of any other circumstance, if the outside credit rating is less than 650 we regard the person as highly likely to default on a loan”. This will mean a new row as illustrated in Table 4; it will also mean that we have to ask questions about the impact of the new condition on the other rows. If you review the impact of the outside credit score on the other rows, you will realize that we will have to ensure a condition that the score is equal to or greater than 650 whenever we conclude a Person Likelihood of Defaulting on a Loan is medium or better. So we have to modify the rows appropriately. See if you can understand how the Rule Family helped us figure out the correct logic to implement the change in the Rule Family in Table 4. Also note the impact of the changes to the Rule Patterns.

RuleFamily PersonLikelihoodOfDefaultingOnLoan
Condition Condition Condition Condition Conclusion
Rule Pattern Person Employment History Person Mortgage Situation Person Miscellaneous Loans Assessment Person Outside Credit Score Person Likelihood of Defaulting on a Loan
1 Is Poor Is Poor Is Medium     Is High
2 Is Good         >= 650 Is Low
3 Is Poor Is Poor Is Low >= 650 Is Medium
4             < 650 Is High

5

 

 

 

 

 

 

 

 

Is

Undefined

            Table 4 Agility in the Rule Family: Modifying Columns and Rows

The proper changes may be found in the worksheet "LikelihoodOfDefaultingOnLoan-2" in the file Rules.xls.  Before we can test these rules, we have to make sure that our Datatype "Person" contains the new term "outsideCreditScore":

Datatype Person
String fullName
String SSN
String employmentHistory
String mortgageSituation
String  miscLoansAssessment
boolean additionalDebtResearchNeeded
String  likelihoodOfDefaulting
int outsideCreditScore

We also may initialize our test-borrowers with some Outside Credit Score values:

Data Person borrowers
Full Name SSN Employment History Mortgage Situation Misc Loans Assessment Additional Debt Research Needed Outside Credit Score LikelihoodOf Defaulting
Peter N. Johnson 111-22-3333 Poor Poor Low No 650 ?

These changes are made in the file "Data.xls".  We also should make sure that our Glossary include the fact "Person Outside Credit Score" - see above.

Now we are ready to execute the modified Decision Model again. If you double-click on "run.bat" you will receive the following results:


Define Person Likelihood Of Defaulting On Loan

Conclusion: Person Likelihood of Defaulting on a Loan is Medium

If we change the Outside Credit Score from 650 to 640,  the rule with the pattern 4 will be executed and we will receive the following results:


Define Person Likelihood Of Defaulting On Loan

Conclusion: Person Likelihood of Defaulting on a Loan is High

 

Where Do The Fact Values Come From (Input)?       ►top

In reviewing Table 4, the question arises: where do we get the input for the information in the cells? For example, how do we know that a particular person’s employment history is good, medium or poor? If the information is readily available – say from a web site, user input, or from a data base (that is, the data is persistently stored somewhere), then it is clear how we get the input (fact values). In the above examples we assumed that the fact values come from the Excel file "Data.xls".

But what if the information on whether a person’s employment history is good is based on additional business logic? The person’s employment history logic can’t be in this Rule Family, since this Rule Family has only one conclusion fact type, which is not a conclusion fact type about a person’s employment history.

So, it follows that, if there is business logic that leads to a conclusion of a person’s employment history, then that business logic should be structured into its own Rule Family. And, regardless of the business logic, we already know that such a Rule Family will have one, and only one conclusion fact type, person employment history, the same fact type as the condition fact type in the Rule Family in Table 4. So there emerges an inferential dependency between the two Rule Families, where the Rule Family for Person Likelihood of Defaulting on a Loan is dependent upon the supporting Rule Family for Person Employment History. This is illustrated in Figure 8.

The conclusion fact type of the supporting Rule Family becomes the condition fact type of the related column in the dependent Rule Family. We refer to the supporting Rule family’s conclusion value as interim knowledge, since it only exists at the time the Rule Family logic is executed.

Figure 8 Supporting and Dependent Rule Families

We may add two more terms to the Datatype "Person":

Datatype Person  
String fullName  
... ...  
int yearsAtCurrentEmployer Range 0 50
int numberOfJobsInPastFiveYears Range 0 20

We will also modify our test data:

Data Person borrowers
Full Name SSN Employment History Mortgage Situation Misc Loans Assessment Additional Debt Research Needed Outside Credit Score Years At Current Employer Number Of Jobs In Past Five Years Likelihood Of Defaulting
Peter N. Johnson 111-22-3333 ? Poor Low No 650 3 4 ?
Mary K. Brown 444-55-6666 ? Average Low Yes 520 1 5 ?

Now we may define a new Rule Family "PersonEmploymentHistory" in OpenRules as follows:

RuleFamily PersonEmploymentHistory
Condition Condition Conclusion
Person Years at Current Employer Person Number of Jobs in Past Five Years Person Employment History
> 2 <= 4 Is Good
>= 1 <= 5 Is Average
        Is Poor

We actually have two related decisions:

  1. Define Person Employment History
  2. Define Person Likelihood Of Defaulting On Loan

The following table describes these decisions and associates with them the related rule families (see the Excel file "Main.xls"):

DecisionModel DetermineLikelihoodOfDefaultingOnLoan
Decisions Execute Rule Families
Define Person Employment History :=  PersonEmploymentHistory()
Define Person Likelihood Of Defaulting On Loan := PersonLikelihoodOfDefaultingOnLoan()

If you again double-click on "run.bat" you will receive the following results:


Define Person Employment History

Conclusion: Person Employment History is Good

Define Person Likelihood Of Defaulting On Loan

Conclusion: Person Likelihood of Defaulting on a Loan is High

The reader may examine and execute some more complex Rule Families that are provided in the OpenRules sample project "Loan1". Open the Excel file "Loan1.xls" to look at the proper rules and data.

The Decision Model from the Top Down        ►top

At this point you should have an understanding of how a Rule Family is structured, and how we create dependencies among Rule Families.

When looking at Figure 8, it is clear  that there are other condition columns in the Rule Family for Person Likelihood of Defaulting on a loan that may depend on Rule Families other than that for Person Employment History. Both fact types – person mortgage situation and person likelihood of defaulting on a loan – may be dependent on other Rule Families. It would soon become difficult to illustrate Rule Families and their dependencies, particularly for Rule Families with a large number of rows, and a large number of dependencies.

To define a decision model from the top down, OpenRules allows you to use multiple tables similar to the above. For example, a top-level decision that defines a main fact may may be defined through several sub-decisions about related facts:

DecisionModel DecisionMain
Decisions Execute
Define Fact 1 :=  RuleFamilyFact1()
Define Fact 2 :=  RuleFamilyFact21()
Define Fact 2 :=  RuleFamilyFact22()
Define Fact 3 :=  DecisionFact3()
Define Fact 4 :=  RuleFamilyFact4()

Here to Define Fact 2 is necessary to execute two rule families. Some decisions like "Define Fact 3" may require their own separate decision models such as described in the following table:

DecisionModel DecisionFact3
Decisions Execute
Define Fact 3.1 :=  RuleFamilyFact31()
Define Fact 3.2 :=  RuleFamilyFact32()
Define Fact 3.3 :=  RuleFamilyFact33()

These tables can be kept in different files and can be considered as building blocks for your decision  models. This top-down approach allows you to represent your decision logic with the Rule Families and their dependencies in an intuitive, easy to understand way. 

Constructing a single Decision Model, we have to come to a determination about its scope: how do we decide which Rule Families belong in this model?  Do we put all the Rule Families in our project, in our department, in our business unit, in our enterprise, into a single Decision Model? Or is there some way to create a scope for the Decision Model that is meaningful and more manageable?

The Decision Model achieves this by relying on the structure of the logic itself, while at the same time giving weight to business expediency. To grasp this, we have to understand the term “business decision”.

What Is a Business Decision?        ►top

We define a business decision in both logical and business terms:

  • A business decision is a conclusion that a business arrives at through business logic and which the business is interested in managing.

We see that the definition of business decision only differentiates it from a business logic statement (which after all, arrives at a conclusion through business logic) by the qualification that it is at the granularity at which the business is interested in managing. Look at the examples of Business Decisions in Table 5. Each of these Business Decisions is about an issue that is important in an organization’s operations, and on which management wishes to focus. Hopefully there are business metrics that would be tracked to ensure that each decision – most presumably automated, but some possibly manual – yield the results that are consistent with the organization’s plans and objectives. For example, the results of business decisions (probably to be made within automated business processes) may decide the profitability or another measure of success.

What Is the Difference Between a Business Decision and a Conclusion?        ►top

In Table 5 the only thing that distinguishes the business decision from its related fact type is the “decision word” in front of the fact type (we underlined the decision word just in case you didn’t notice!). So a business decision, like a Rule Family, is a conclusion about a single fact type. In fact, it relies for its logic on a Rule Family that has a conclusion fact type of the business decision fact type. We call this Rule Family the Decision Rule Family.

Table 5 Examples of Business Decisions

Adapted from: The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

Business Decision Scope       ►top

A business decision is also the scope of the Decision Model, because it is a meaningful group of logic, from a business perspective, for the business to manage. So the Decision Model begins with the business decision, followed by the Decision Rule Family, its supporting Rule Families and their supporting Rule Families, and the model is complete when with there are no further supporting Rule Families.

The Decision Model has Principles, and is Normalized       ►top

There are 15 principles that are applied to the Rule Families to ensure rigor in the model. These are broken into three groups:

  • Structural Principles – Leading to structural simplicity. These principles define the two dimensional structure of the Rule Family.

  • Declarative Principles – Ensuring the declarative structure. These principles define the declarative technology‐independent nature of the structure, ensuring that it is free of any sequential or implementation constraints.

  • Integrity Principles – Encouraging optimal logical integrity. It is essential that the business logic in the Decision Model has business and logical integrity. This means that the business purpose has been understood and aligned, and that there are no logic errors, conflicts, or duplication.

One of the most important concepts introduced by the 15 principles is that of normalization, which means decomposing structures into more desirable structures that have greater levels of integrity – in the context of the Decision Model, this means logical integrity. The Decision Model introduces three levels of normalization –

  • First normal form – enables the business logic to be represented and interpreted in one and only one way

  • Second normal form – eliminates redundancies in the business logic statements

  • Third normal form – ensures there is no hidden logic within business logic statements.

A Decision Model compliant with these normal forms delivers that logic with maximum integrity and manageability.

Conclusion

The introduction of the Decision Model, a technology independent model of business logic, has opened up new opportunities for significant improvement in management and information technology (IT) practices. The ability to relate management objectives directly to business decisions and to manage those business decisions against performance over time has created a new discipline of Decision Management (DM) (sometimes called Business Decision Management (BDM) or Enterprise Decision Management (EDM)). This new discipline promises dramatic opportunities for increased business agility.

For IT, the Decision Model provides the missing link – a model of business logic. This is the one remaining aspect of business application systems for which IT does not yet have a universally accepted model. Consequently, until now, business and systems analysts bury the business logic in various models such as process models, use cases, activity models; or they list what they consider to be the business rules in catalogs of rule statements using various proprietary (or just random) methods of expression and grouping. The result is that no two models agree, leaving the designers, and ultimately the developers of systems to make their own determination of the correct logic. This results in wasted costs and higher error rates, failures in projects, and application systems that are sub‐optimum and lack agility.

The Decision Model promises to improve a wide range of IT and business practices, including business planning, decision support, Business Process Management (BPM), Business Architecture (BA), Enterprise Architecture (EA), Business Requirements, Business Analysis, Service‐oriented Architecture (SOA), System Testing, and development methodologies both classical and Agile. The Decision Model, and its impact these practices is the subject of a book to be published in late October of 2009 called “The Decision Model: A Business Logic Framework Linking Business and Technology” (von Halle and Goldberg 2009). Certain Diagrams in this document, and example Rule Families are drawn from the book and are copyright 2009 Auerbach Publications/Taylor & Francis, LLC. Reprinted with permission of the Publisher.

The book may be found at www.TheDecisionModel.com.

OpenRules, being a popular open source Business Rules Management System, provides an ideal implementation platform for the Decision Model keeping business analysts in charge without necessity to learn any rule language or proprietary rule management environments. Read more about OpenRules at www.openrules.com.

 

Back to www.openrules.com

 

 

Bookmark  |digg |del.icio.us |furl |spurl |blinklist |reddit |yahoo |blinkbits |blogmarks |de.lirio.us |smarking |
Divider