A Business Rules-Based Approachto Information Systems Development

Dr. Paul DorseyDulcian, Inc.

www.dulcian.com

NYOUG – December 12, 2002

Agenda

Part I: Overview & Background of BusinessRules

DefinitionsHistoryAdvantages/Disadvantages of approach

Part II: Quest to Create a Rules-BasedDevelopment Environment

Implementing business-rule based systems

It’s all about business rules

In the last 5 years, business rules have emerged at thecenter of the application development process.There are now entire conferences and publicationsdedicated to business rules:

Business Rules Forum

ODTUG Business Rules Symposium

BR Community

Lots of business rules papers at every conference.

Business Rules

New, cool buzzword?Same old stuff in a new package?

Hype?Remember CASE, artificial intelligence…etc.

Real paradigm shift?Completely revolutionize database industry

Answer: Maybe all three

What are business rules?

A new word for requirements ??Almost…Refocus from “requirements” to “rules”

Figuring out the business rules is what whatgood analysts have always done.Business Rules include all businessrequirements

A precisely articulated requirementthat is both machine readable & user readable.

History of theLeading Designers (1)

1980-1990 Denormalization“There is no way to get good performance out of arelational database that is normalized. Good,skilled denormalization is the key.”

1990-1995 Normalization is OK“Now that the database is fast enough, we cannormalize to make our systems easier to build.”

History of theLeading Designers (2)

1995-2000 Generic Data Models“We can decrease the size of our databases bymodeling some quantity of our systems as data userule tables.”

2001-Present Business Rules-Based Systems“Put as many rules as possible into a repository andgenerate as much of the system as possible.”

Flawed Communication inthe System Design Process

There is nocommon point ofcommunication

between Users andIT Professionals.

USERSIT PROFESSIONALS

SYSTEM

uses and reverse

engineers requirements

build

communicate requirements

BUSINESS RULES

Communication using abusiness rule approach

The Rule Repository is thecommon point ofcommunication betweenUsers and IT Professionals.

USERS

SYSTEM

GEN

ERA

TES

USE

VALID

ATE R

ULES

ENTER

RU

LES

RULEREPOSITORY

IT PROFESSIONALS

The REAL Advantage!!!!

“The only reason you are able to build socheaply is that you foist the programming offonto your users.” Ulka Rodgers

Building the System

StrategyAnalysisDesignBuildTest

Strategy -- no changeAnalysis (Rule Gathering andvalidation)

Gather rulesImplement systemTest

Build Custom Applications

Rules-BasedTraditional

Business Rules approachis not a new idea

Existing business rule-based approaches:1. Reference tables2. Data modeling tools3. Generic modeling4. Existing business rule tools

All are fragmented approaches.

Imagine PlanetBusiness Rule where…

Users are enabled to articulate theirrequirements (aka business rules).We can easily gather and placerequirements into a business rulesrepository.The whole system is generated from thebusiness rule repository.

Is Planet Business Rules a trap?

Rules must be manageable!500,000 sentences is not viable.Flowcharts with 3000 boxes don’t help.

Helpme!

How can you managebusiness rules?

1. Analysis Rules ≠ ImplementationRules

Analysis rules = how users talkImplementation Rules = precisespecification

2. Rules must be partitioned.

????

Business rule-basedsystems development

Analysis RulesDeclarativeBusiness ramblings

Implementation RulesStructural (Data Model)Process (Process Flows)

Final system

Hard, creativetransition

Trivial transition

Hard Questions to Ask

1.Where will all of the rulesgo?

Database triggers, proceduresRules ProductApplications

2. How will the systeminteract with the DBMS?

Extracting to rules tool isterrible.

3. How will very detailedsecurity be handled?

Who can do what in each state?

4. What about configurationmanagement?

Real time update is not enough.

5. How can the system beintegrated with existingapplications?

Integration must be seamless.

Tool Types

Capture ruleparagraphsSort intocategoriesGeneratestandardAnalysisDocument

Flowcharts, STELook great in demos

Need hundreds ofboxes for productionflow

Don’t do as much asthey seemGenerate codeUsually are notintegrated intoDBMS

Specifystructuralrules

“Start date <End date”

Generatetrigger codeLimited use

Analysis Rule Gathering Process Flows Database Triggers

Implementation Rules

The Industry

Analysis rule gatheringBusiness Rules Solutions

Framework Solutions

BRIM™Dulcian, Inc.

Process Flow (Biggestgroup)

ILOGSavantSeeristicBRIM™

Database triggerNintechSeeristic

Full system generationBRIM™

Need for Technical Leadership

Every successful business rules-basedimplementation has used a senior architect.Why does business rule-based developmentrequire a good tech lead?

1. Requires getting pieces to work well together(although there are fewer pieces)2. Totally model-driven design3. True paradigm shift even if you are usingtraditional tools

The moral of the story is:You just can’t buy a tool and run with it.

How to guaranteeBR project failure

1. Attempt to bolt in a toolDon’t think through the wholeprocess

2. Inadequate tech lead3. Insist that “We don’t needany help.”4. Get rid of tech lead toosoon.

5. Start writing lots of code toovercome deficiencies in rulerepresentation.6. Use declarative processrules

Process rules require a processflow.

7. Don’t worry aboutconfiguration management

Cost of V2 is hugeFull data migration

The Business RulesCommunity

2 main groupsThe originals:

Ron Ross, Terry MoriartyBusiness Rules ForumFocus on Analysis rules, grammars, taxonomies

The builders:Paul Dorsey, Roland Berg, Dave WendelkenODTUG Business Rules SymposiumFocus on building systemsTools, utilities, code/DB generators

Can’t we all just get along?

Case StudyUS Air Force Recruiting – V1

Air Force RecruitingTools/Approach

Oracle DesignerGeneric ModelingDeclarative Rules

Cost $5million rangeResults

SuccessWhen tech leads left – project struggled

Lessons learnedIt’s hard to do on your ownFull rule support is very hard on a home-grownsystem.

Case StudyUS Air Force Reserves

Recruiting – V1Air Force RecruitingTools

BRIM™

PureEdge (front-end tool)Cost $1million rangeResults

Looking good so farThings are going very fast.

Lessons learnedAnalysis rules are VERY important.Map analysis rules to implementation rulesHaving all rules in a single repository makes themindependent of the physical implementation.

Part II:The Quest to Create a

Complete Business Rules-BasedDevelopment Environment

The Vision

All rules go into a repository.Rules grammar is robust enough to specify the wholesystem.Users can read (and help enter) rules.You can generate the whole system.

The rules ARE the system.

The generated system will be almost the same as thesystem you would build by hand.

Recall: Business rule-basedsystems development

Analysis RulesDeclarativeBusiness ramblings

Implementation RulesStructural (Data Model)Process (Process Flows)

Final system

Hard, creativetransition

Trivial transition

Analysis Rules

Everyone thinks aboutrules differently.Users think in text.Let each project teamdesign its own analysisrules structure.Map analysis rules toimplementation rules.

Implementation Rules

This is the way we have been thinking for years.We just need to improve upon the idea.

Structural Rules: Data Model

Process Rules:Process Flows

Partition the rules:

UML as a businessrule language

Unified Modeling LanguageOracle’s directionEstablished standardExtensibleStructural rules

Class diagrams

Process rulesActivity diagrams

Structural Rules – the problem

ERDs – Can be improved uponNot enough rules includedNot extendableReference tables aren’t niceNo inheritance

Structural Rules – the solution

Use UML Class diagrams withextensions:

StandardExtensibleSuperset of ERDs (Easy to move to)

Makes rule representation compact.

A Better Way to Model

1. No reference tables2. More precise and complete

EMPLOYMENT

EMP DEPTEMP DEPT

EMPLOYMENT{PK HISTORY}

**works for >

Process Rules – the problem

Declarative rules arehard to implement:

“Purchase orders over$50,000 require threelevels of approval.”Too many rulesRules interactTerrible performanceExample:

14,000 rulesNo idea of processNo way to debugPoor performance

Traditional flowcharts orstate diagrams are alsodifficult:

Too many little boxesDecomposition onlymoves the boxes around.

Process Rules – the solution

Business-based process flowsTry a user’s idea of a “state.”

One user state replaces 20-30 state transition enginestates.Makes rule representation compact.

Process step

States Belong to Objects

Application-independentNo rules in applicationsFully integrated with data model“Classes have attributes. Classes have security rules.Some classes have states.”

“Inbox State” flowchart

SELECTTRANSITION

CLOSEOBJECT

WAIT TOOPEN

EXECUTESUCCESS

TASKS

GIVEERROR

GIVEERROR

SHOWALTERNATIVES

EXECUTEEXPIRETASKS

EDIT

SELECTTRANSITION

EXPIRE

CHECKOPEN

RULES

FAIL

SUCCEED

EXECUTEBEFORE

OPENTASKS

SUCCEED

OPENOBJECT

CLOSEOBJECT

BAIL TASKSBAIL

CHECKREQUIRED

RULES

PROCESS

CHECK DATAVALIDATION

RULES

SUC

CES

S

SELECT ALTERNATIVE

CANC

EL

CHECKRULES

EXECUTEFAIL TASKS

FAIL

CANCEL

SUCCEED

ON SETTASKS

SELECTTRANSITION

GIVEERROR

FAIL

OPEN

GIVEERROR

FAIL

Timesheet Flow

System Generation:Structural Rules

Classes are tables.Attributes are columns.Reference tables are domains.Should be as close to traditionalDBMS as possibleGenerate:

tablesviewstriggers

System Generation:Process Flows

Generate procedures to run in:DatabaseMiddle tierClient

Code must be generated to provide adequateperformance.Application independentApplication should call “ProcessObject( )”

System Generation:Making it work

Planet Business Rule isjust a playgroundwithout:

ConfigurationmanagementRich security modelFull integration withDBMS

Conclusions

Business rule-based design and development isthe next big shift in the industry.Using an existing commercial product is, at best,a fragmented approach.Complete rules-based environments are coming.The key to project success is a good technicallead.

Dulcian’s BRIM Environment

Full BR based development environmentFreewareFor Demo/License

Write “BRIM” on business card

Finding out more aboutBusiness Rules-Based

SystemsJoin the Business Rules Advisory Group

Free membershipDiscounts on BR products, conferencesFree listserv run by ODTUGWrite “BRAG” on business card

Business Rule ConferencesBusiness Rules Forum

November 4-8, 2002 – New Orleans, LAODTUG Business Rules Symposium

June 15, 2003 – Miami Beach, FL

BRIM™ is sharewareComplete business rules-based environmentFree, unrestricted site licensesFor free demo, write “BRIM” on business card

Contact InformationDr. Paul Dorsey – paul_dorsey@dulcian.comDulcian website - www.dulcian.com

JDeveloper 3Handbook

Developer AdvancedForms & Reports Designer

Handbook

Coming by year end Oracle 9i JDeveloper Handbook

Design Using UMLObject Modeling