A Critical Time for Business Rules 2004 Barbara von Halle Knowledge Partners Inc. 227 Route 206...

A Critical Time for Business Rules

2004

Barbara von Halle

Knowledge Partners Inc.

227 Route 206

Flanders, NJ 07836

973-252-0033

[email protected]

July 14, 2004

Knowledge Partners, Inc. 2004 2

Recognized for offering state-of-the-art and practical BR Methodology

Leaders in providing services for full life cycle BR projectsSelected by Fair Isaac to co-develop the BR plug-in for

IBM/Rational RUP ™Founding partner of LIG (ASG/Rochade, Fair Isaac/Blaze,

KPI from legacy code to BRE)Author of:

“Business Rules Applied: Building Better Systems Using the Business Rules Approach” (finalist for SD Magazine Jolt Award)

Provider of RMM Workbench™ (built on Popkin’s SA)

Who is Knowledge Partners Inc (KPI)?


Understand BR Concepts Today What are BRs? What is a BR Approach? Why now? What are organizations doing today? What will they be doing tomorrow?

Review Important Steps in a BR Approach Remove confusions about Rule Repository and

Management See the View from Here

Objectives are


Business Rules represent the intellectual decision-making aspect of your organization

They are the collection of your organization’s business policies, constraints, computations, reasoning capability and the proper management of those to business directions Business integrity or value system through rules of engagement

Business compliance through interpretation of legalities

Business differentiation (spark)

PoliciesAnd rules

How about examples of business rules?


Business people express business rules in a business-oriented manner

Rule 1: A Platinum customer is every customer whose credit rating is A

Rule 2: We grant Platinum customers a special insurance premium discount $100 if the amount of their home equity loan is greater than $200,000

Seems simple enough, then what…•Each possibly “owned” by different organizations•Each possibly guiding behavior in different processes•Each possibly changing independently of each other


IT staff translate business rules into a technical representation

public class Customer {private string creditRating;private int insuranceDiscount;private Order currentOrder;...public int checkIfPlatinum( void) {

if (creditRating = “A”) {return true;

} else {return false;

}}...

}

public class Application {private Customer customers[];private Customer platinumCustomers[];...

public void checkOrder() {for (int i = 0; i < numCustomers; i++) {Customer aCustomer = customers[ i];if (aCustomer. checkIfPlatinum()) {

numPlatinumCustomers++;platinumCustomers[ numPlatinumCustomers]

= aCustomer;if (aCustomer. getCurrentOrder(). getAmount()

> 200000) aCustomer. insuranceDiscount (100);

}}

}}

So, a business rules approach aims to enable the business people to know that the right rules are guidingthe business in all the right places, but...


There are various ways to express rules, depending on audience

Original Business Conversation or Statement or requirement

Natural Language Business Expression

Business Rules in Templates

Programmed

Business Rule

Discovery AnalysisDesign and

Implementation

Example: BRE Engine

Example: Driver must be of appropriate agewhere appropriateage varies by state.

Example: A valid driver in NJ must be at least 17 years old or

If a person’s age is less than 17 and the person lives in NJ, then the person is an invalid driver.

Example: If driver.state-of-residence-code = “NJ” and driver.age >= 17 then driver.appropriate-age-flag = “yes”

RamblingOr

“as they say it”


Rules Mature as You Express Them

Original Business

Conversation

NaturalLanguageBusiness

Expression

Business Rules

In Templates

Programmed Business

Rules

•May not be relevant•May not be atomic•May not be declarative•May not be precise•May not be complete•May not be reliable•May not be authentic•May not be new•May not be consistent

•Relevant•Atomic•Declarative•May not be precise•May not be complete•Reliable•May not be authentic•May not be new•May not be consistent

•Relevant•Atomic•Declarative•Precise•Complete•Reliable•Authentic•New/unique•Consistent

•Executable•(may be procedural)

And rules form a new kind of model.


Business Rules Approach Definition:

A formal way of managing (and possibly automating) an organization’s business rules so that the business behaves and evolves as its leaders intend.

Business Rules Applied (page 3)

Now, let’s understand what a Business Rules Approach is.

So, a BR approach is about the business first, technology second.


There are four ways to measure whether an organization is truly adopting a BR approach

Separate the rules so…the business knows where to find them, can apply them consistently

Trace rules so… the business knows where the rules come from (policies), why they exist (objectives) and where they are utilized (procedures, automation)

Externalize rules so… the business audience knows what they are and can challenge them

Position rules for change so… the business can evolve at its own pace

This is why we call it STEP ™


Major corporations are quickly investing in a BR approach now for business reasons..the top 10 are:

1 - Preservation of Business Integrity and Compliance 2 - Business Rate of Change, Mergers/Acquisitions 3 - The Growth of BPM 4 - The Need to Know 5 - The Need for Consistency 6 - A New Generation of DWH Environments 7 - A Recognized Gap in SDLC 8 - A Need for Shorter Development Iterations 9 - Proliferation of BR Projects and BR Engines 10- Risk Aversion

And there are risks to think of.


Most organizations are realizing the risks of not investing in a BR approach

L Lost rules

I Incorrect rules

A Actually embarrassing rules (inconsistent)

B Bought (purchased) rules

I Independent of meaning (meaningless) rules

L Legally compromising rules

I Impact unknown rules

T Tough to change rules

Y elusivelY expensive rules

So, what are organizations doing do about it?

Compliance problems looming?


The reality today is that the full benefits are not being reached

•Business people are not truly driving BR Development Projects, the projects tend to focus mostly on the technical aspects;

•Business users are still not writing the Business Rules in a simple business language traceable to automated systems or business processes

•Business Rules fail to be reusable from one project to the next, creating more business inconsistencies

•Business users do not recognize their Business Rules even if the rules are implemented in a Business Rules Engine: in fact the rules are just as “hidden” as if they were written in conventional code and, worse, proliferated even faster

•No one is paying enough attention to the rules behind non-automated processes because technical people are not focused on these rules, thus they are given a lower priority. This only magnifies the demand for it..we

need a roadmap to follow.


KPI’s Business Rule Maturity Model™

Change is driven by business analysts. Ability to predict business impact of change is still low.

BRs are separated through structured BR templates, BR analysis/design techniques, and BR technology.

Business analysts define and change the business form of the rules.

Cost of change is lower. Ability to predict business impact of change is still low.

BRs are not buried. They exist in a separate rule repository and management tool, maybe separate automation technology.

Business analysts know and challenge the rules. I/T traces rules to systems.

Copyright Knowledge Partners Inc. 2003

Level 0 - Level 1 - Level 2 - UNAWARE AD HOC REPEATABLE

Cost of change is high. Ability to predict business impact of change is low.

BRs are buried in code, documents, and peoples’ heads.

There is talk about harvesting BRs from people or docs and mining BRs from code.

Business ValueBusiness Value

Technical StateTechnical State

Business ControlBusiness Control

MINIMUM MAXIMUM

IMMATURE MATURE

MINIMUM MAXIMUM


KPI’s Business Rule Maturity Model™

Ability to predict business impact of change becomes available.

BRs in the rule repository and management tool are associated with business metrics, traceable to business value.

Business analysts can test BRs against ODS and DWHs and dbs

Business people can easily assess business impact (revenue, staffing, customer base) because BRs are in place (ODS, DWH).

Cost of BR change and testing is even lower. Ability to predict business impact of change is better.

BRs are separated as a standard practice through a rule repository and management tool.

Business analysts generate and test automated BRs.

Ability to predict business impact of change and protect business integrity is common place.

BR governance is integrated into business processes.

Copyright Knowledge Partners Inc. 2003

Level 3 - Level 4 - Level 5 – DEFINED MEASURABLE CONTINUOUSLY

IMPROVED

The Agile, LearningOrganization

is born and sustained.

Business ValueBusiness Value

Technical StateTechnical State

Business ControlBusiness Control

MINIMUM MAXIMUM

IMMATURE MATURE

MINIMUM MAXIMUM


Understand BR Concepts Today Review Important Steps in a BR Approach

What are the critical steps Rule classes Decisions Rule motivations Rule families Role of business people

Remove confusions about Rule Repository and Management

The View from Here

Objectives for today are


Step 1: Confirm Project Scope• Objectives wrt BR approach (*)• KPI Rule Classes (*)• Business Concept, Business Process, Rule Classes (*)

Step 2: Document Processes to Decision Level• Use case narrative• Use case steps• Decisions as anchor points for rules (*)• Decisions related to rule classes (*)

Step 3: Start Business Glossary• Business terms (*)• Object Model• Logical Data Model

Step 4: Discover Rules• Natural language rules (*)

Step 5 Formalize Rules in Template Form• Technology-independent templates (*)(?)• Technology-specific templates

Step 6: Analyze Rules• Reports from rule repository (*)• Rule analysis tool (*)(?)• BRE

KPI’s STEP™ Deliverables with Use Cases

(*) are potentialnew deliverables


What is new in scoping?

Business Background and Project Goals *** how do BR help ***? Project Scope - High Level Process Models

Process decomposition 2 levels Process flow Use case model

Proposed Project Increments Project Plan Assumptions Project Roles Stakeholders Preliminary Business Rule Management Workflow

Appendices: 1 – Rule Classes and Business Processes to Rule Class Matrix 2 – Glossary 3 – Rule Sources

There is a new concept here: rule classes


Rule Classes turn out to be the critical ingredient for rule management, planning, and estimating

Definition: A high level grouping of candidate or actual rules about one business concept with a specific kind of logic processing where such grouping assists in understanding eventual business rules (scoping)

Business concept – business term of type business object (customer) or qualified business object (preferred customer)

Business Concept: Car Renter

Rule Class Name

Rule Class Description

Dominant Rule Classification

Complexity/ Volume of Rules

Potential Sources for Rules

Rule Steward(if known)

General Validation Rules

Constraint Simple Customer Service

Customer Service

Driver Risk Assessment Rules

Inference Complex Risk System Risk Manager

Financial Risk Assessment Rules

Inference, computation

Complex External Service

CFO

Very important:•Volatility/change characteristics of each rule class/rule family•Should business people be able to change rules in a specific rule class/rule family


You can use rule classes during scoping to:

Estimate project based on Number of rule classes Complexity of each

Logic complexity, dependencies Political complexity

Number of estimated rules in each 10s, 1000s, 10000s

Source(s) for each Available Known Documents, people, code

Geographical locations for source(s) Political sensitivity of each

Drive SOA Once you have your scope defined, you model your process and/or model your use cases, but what is different?


Without a BR Approach, use cases often contain hidden rules

1. Some rules are here.2. Some rules may be missing.3. Some rules apply to more than one

use case, in which case they may be inconsistently captured.

4. Some rules may need to change and changing them in all relevant use cases may be impractical.

So, can we do better?

Name: ATM withdrawal

Description: Actor wants to withdraw money from account

Actors:• Customer• Customer representative

Use Case Relationships

Pre-Conditions

Basic Flow1. Actor presents ATM card2. Validate customer: is customer in our db, does PIN match3. Determine if sufficient funds: compare amount requested to total amount

in customer account 4. Deduct amount from account5. Distribute money6. Distribute receipt

Post ConditionsAlternate FlowsNotes


With a BR approach, rules are now separated

1. Notice that there is now a reference to rule families.

2. The rules themselves are not here.3. The rule families can now be referenced by

multiple use cases.4. Rules within a rule family can now be changed

independently of use case changes.5. Documenting use cases can happen

independently of documenting rules.

Name: ATM withdrawal

Description: Actor wants to withdraw money from account

Actors:• Customer• Customer representative

Use Case Relationships

Pre-Conditions

Basic Flow1. Actor presents ATM card2. Validate customer:

Decision: Execute Rule Family ‘Valid Customer’3. Determine if sufficient funds:

Decision: Execute Rule Family ‘Sufficient Funds’4. Deduct amount from account5. Distribute money6. Distribute receipt

Post ConditionsAlternate FlowsNotes

Let’s take a look at an example.


Service Car Rental Request [UC 84]

Description: This use-case determines the validity of a request to rent a car, assigns appropriate car and prices to the request, and returns the best terms for the rental request.

Basic Flow[UC 84-1] Actor interacts with rental request web page[UC-84-2] System validates the rental request <<decision: Is renter known?>> <<decision: Can a reservation be accepted from this renter?>><<decision: other…>>[UC 84-3] System assigns car to reservation request<<decision: xxxx>> [UC 84-4] System calculates cost of rental for this renter for this car<<decision yyyy>> [UC 84-5] System presents rental terms to actor[UC 84-6] Actor accepts terms of the rental[UC 84-7] System establishes reservation in databaseAlternative Flows

Renter is unknownReservation cannot be accepted from the renterAn appropriate car will not be availableRenter does not accept terms of the rental

Let’s take one decision,and investigate the businessmotivations for it.


Decision: Can a reservation be accepted from this renter?

Business Motivations: To better predict car availability To avoid illegal drivers To minimize financial risk

You will want to correlate the decision to important business considerations, such as:


Write use case steps only for basic flow Then, identify those steps as DECISIONS where rules

can execute Then, harvest rules behind DECISIONS Alternate flows relate to decision-steps and represent

undesirable results from rule execution Motivations behind each decision will assist later in

rounding out the rules

Productivity gains initial use cases are shorter, parallel rule harvesting can occur

You can use decisions and business motivations during use case writing to provide rigor:

But, how can rules drive SOA?


You can use rule classes to drive SOAPhase Process Rules Data Application

Architecture

Enterprise High-level activity diagram for each business domain in the enterprise domain model

High-level Rule classes cross- referenced to the business domains

Enterprise Data Model Enterprise object model

(with methods for rule classes)

High Level Reqts

High-level activity diagram

Use case model

High-level Rule classes

(scoped from enterprise rule classes)

Project data model

(scoped from enterprise data model)

Detailed Reqts

Detailed activity model

Use case specifications

(use case steps, decisions for rule-anchor point)

Rule families (templated rules, natural language rules, related to enterprise rule classes)

Logical data model (fully normalized, keys, relationships, attributes)

Analysis class model

(contains classes in addition to those that relate to logical data model such as control classes, fully attributed, associations) (possibly: methods for rule families) (optional!!!!)

Design System use cases Executable rule packages (sets/flows for targeted technology)

Physical database Design class model

(interface classes, methods for packages)

Sequence diagram


But, most important, what do you need to decide WRT the role of business people?

Who is to be authoring the rules for the business audience (business or technical people?)

Who is to be reading the rules for the business audience (business or technical people?)

How rigorous vs how free-form is appropriate for these audiences?

Who will be putting rules into production (business or technical people?)

What language or techniques/tools are needed for this to occur?

These need to be answered so methodology,deliverables, and software requirements can surface.


You can analyze rules for logical quality before ever automating them

Rule Family: Default Probability

Conclusion

Mortgage Holder

Outside Credit Rating

Loan Holder

Credit Card Balance?

Education Loan

Balance?

Internal Credit

Rating?

Internal Analyst

Opinion?

Default Probability

Y HN X HN not X Y <= 0 MN not X Y > 0 > 0 HN not X Y > 0 <= 0 A -C HN not X Y > 0 <= 0 not A-C MN not X N > 0 LN not X N <= 0 <= 0 LN not X N <= 0 > 0 D-F HN not X N <= 0 > 0 not D-F L

H HM ML L

IF AND AND AND AND AND AND

THEN

What can we do with this?


There are many ways to analyze rules

1: Analyze rule families for completeness, inconsistencies, etc2: Resolve problems found with business people3: Then, analyze resulting rule families with business motivation for

completeness 4: Then, also analyze resulting rule families with business motivations

for consistency with goals5: Finally, measure the “performance” of the rules overtime against

business objectives to see if the rules are truly “working” for the business

6: Finally, create rule family dependencies, rule pattern dependencies, rule dependencies for proper execution

7. Extra credit: imagine various future events, create rule families ahead of time, analyze them for logical sense, simulate them for anticipated business impact


Understand BR Concepts Today Review Important Steps in a BR Approach Remove confusions about Rule Repository and

Management Source vs implementation rule repository Rule life cycle (before the BRE!) Options in rule repsitories Enterprise vs project repositories

The View from Here



There is a lot of confusion today and this is important!!!!

Project 1

Project 2

Project 3

Enterprise Rule

Repository

Source Rule Repository

Implementation Rules

Repository

Procedural Code

~~~~~~~~~~~~~

~~~~~~~~~~~~~

~~~~~~~~~~~~~

~~~~~~~~~~~~~

Manage source rules for business people to know and challenge, with a pointer to implementation

Manage executable versions of rules in separate (BRE) technology for IT and/or business people to change the rules as implemented

Implementation Rule Repository


Rule Life Cycle(the business side prior to the automation side)

Analyzed RuleAnalyzed Rule

Validated RuleValidated Rule Approved RuleApproved Rule

•Natural language •Business motivation context•Process context•Information context

•Formal language•Grouped into meaningful rule collections•Consolidated to a minimal cohesive set

•Business agreement•Confirmed against business objectives

Rule Under ReviewRule Under Review

Obsolete RuleObsolete Rule

Rule Source

Rule Source

Discovered RuleDiscovered Rule


Today, most organizations are extending existing software for rule repository

MS/Word, MS/Excel Home-grown db (MS/Access, other) Extended CASE Tools Niche products BREs front-ends Requirements Tools KPI’s Workbench

Each has major shortcomings


TR Analyst

Modify Glossary forFormal Terms

TR Analyst

FormalizeBusiness Rules

BR Analyst & TR Analyst

AnalyzeBusiness Rules

BR Analyst & Business

ValidateBusiness Rules for

the Business

TR Analyst

Create or ModifyModel of FormalTerms and Facts

BR Analyst

Perform QualityAnalysis on

Business Rules

BR Designer/Developer

Design andGenerate Code for

Business Rules

Rule AnalysisRule Analysis

Rule AutomationRule Automation

BP Modeler/BR Analyst

Document Process Model to

the Decision Level

BR Analyst & Business

Harvest BusinessRules to Support

Each Decision

BR (Glossary) Analyst

Create or ModifyGlossary of

Business Terms

BR Fact Modeler/BR Analyst

Create or ModifyModel(s) of

BusinessTerms and Facts

Rule HarvestingRule Harvesting

Business Rule Workflow Steps(Based on KPI’s STEP™ Methodology)

TechnicalOriented

BusinessOriented

Copyright Knowledge Partners Inc 2003

BR Architect/BR Analyst

Scope theBusiness Process


•Requirement•Use Case•Domain•Rule Class

•Rule Family•Rule

•Rule Source•Rule Implementation•Implementation







Organizations are asking for enterprise vs project level rule repositories

•Domain

•Rule Class

•Rule Family

•Rule

•Rule Source

•Rule Implementation

•Implementation

Extract re-usable Rule Classes, etc. from Enterprise Repository at start of project

Promote newly found or updated Rule Classes, etc. to Enterprise Repository at end of project

Project 1

Project 2

Project 3

Enterprise Rule Repository

More business and technicalsophistication regarding BRs is coming.


Understand BR Concepts Today Review Important Steps in a BR Approach Remove confusions about Rule Repository and

Management See the View from Here

Level 0 Level 1 Level 2 Level 3 Level 4 Level 5



Right now, things are changing fast…they are going in this direction..first stop for most is level 2

0

5

3

2

1

4

1. Scope2. Process

Model3. Discovery

N/L Rules4. Business

Glossary

5. Formalize (terms, facts, rules)

6a. Analyze Manually

6b. Analyze Automatically

7. Test

8. Simulate

9. “Arm” yourself for Futures

(Gartner rule warehouse

packages)

Nothing


Thank You

0 1 2

3 4 5

KPI RMM ™ Model

A Critical Time for Business Rules 2004 Barbara von Halle Knowledge Partners Inc. 227 Route 206...

Documents

Transcript of A Critical Time for Business Rules 2004 Barbara von Halle Knowledge Partners Inc. 227 Route 206...