business rules © ed green penn state university all rights reserved

Business Rules

© Ed Green Penn State University All Rights Reserved

04/11/23Business Rules2

Topics

What business rules are Why business rules are important Problems with business rules Language of business rules


Concept of Business Rules

Set of underlying principles that provide enterprise governance and guidance

Allows for variations across enterprises

Many points of similarityExternal forcesCommon goals


What Is A Business Rule

Compact statement about some aspect of a business Expressed in terms directly related to the

business Simple, unambiguous language that is common

to all stakeholders GUIDE

“a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.


Definition/Explanation of Business Rules

Set of statements Describe/define how a business operates

Governance “Rules of the road”

Influences Business process(es) Culture give and take

• Social• Organizational

Legal constraints and obligations Market activities and actions


Importance of Business Rules

Defines how the business operates Internal and external relationships Absence of business rules chaos

Forerunner to defining business processes Automate processes are a subset Essential precursor to establishing

functional requirements for IT solutions


Problems With Business Rules

Represent critical intellectual capital Limited (or less) organized collection

No central repository No standardized format Often reside with individuals – never documented

Opportunity – knowledge management Create a data store of business rules that is

• Complete• Comprehensive• Standard format• Managed by information

technology

Knowledge Base


Building Software – Current Process

Business OwnerBusiness Owner

OperationalSystem

BusinessDescriptions

AnalystAnalyst

DeploymentConstraints

DeveloperDeveloper

Evaluate, Use

(Redefine

Interpret

Inte

ract

StructuredSystem

Descriptions

Test

GenerateSource CodeSource Code

TesterTester

Define

Inte

rpre

t

Interact Inte

ract

Code

Errors

SoftwareModules

SoftwareModules

Create, RefineCreate, Refine

Define

System Development

System AdministratorSystem AdministratorIntegrate

Integrate

DeployDeploy

(Redefine


Issues With Current Development Process

Business owner – person who needs software, is underwriting the costs, has business but not technical acumen

Process contains implicit acceptance of frailty Process relies on descriptive materials requiring interpretation

Exacerbates communications gap between end users and developers producing a“I heard what you said but not what you meant!!”mentality

Process is labor intensive Process is slow Process does not address risk management/mitigation naturally

Developing software is risky, slow, and expensiveDeveloping software is risky, slow, and expensive


System Development Vision

Business OwnerBusiness Owner

OperationalSystem

GenerateGenerate

Generate

SoftwareModules

SoftwareModules

Evaluate, Use

StructuredBusiness

Descriptions

StructuredBusiness

Descriptions

HumanReadable

Views

HumanReadable

Views

MachineReadable

Views

MachineReadable

Views

StructuredDeploymentcomponents

StructuredDeploymentcomponents

System Development

Review

(Red

efine

(Redefine

Manage

Deploy


Implications of the Vision

Reduced system development time following requirements stabilization

Staffing profile shift Fewer programmers and testers More software analysts and software

engineers Significantly improved software quality Somewhat lowered software

performance efficiency


Practicality of the Vision

Software code generation is an inhibited technology Perception – subservient to manual

programming Current modeling technology do not provide for

requisite information richness needed for automation

Lack of standardized approach to expressing business and technical architecture needs

The problem is difficult


Practicality of the Vision

Realistic steps1. Increase structure for describing business needs2. Improve structure for describing computing

environment3. Generate code fragments from enhanced business

descriptions4. Focus development on refinement/extension of

generated code vis a vis creation. Accept, within limits, some degree of inefficiency

5. Package developed software in component form; simplify subsequent management/deployment; focus on interfaces; hide implementation details

6. Emphasize process improvement; use the best people; quantify, measure and continually review the process.

7. Reduce common system elements to manageable/reusable templates. Increase levels of commonality. Move differentiators into rule sets.


Defining Business Rules

Rule statements Forming rule statements Construction rules


Rule Statements

Characteristics Business Aspects of Rule

Statements Rule Contents Expression Levels Rule Definition Options Culture Impacts


Characteristics of Rules

Constraints – Define conditions that MUST hold true in specified situations WHAT must be the case rather than HOW it came to be

Define the desired logic of the business Conditions to be detected Actions required to establish a state of “TRUE”

Characteristics Atomic – elementary and essential; beyond (further) decomposition Unambiguous – single, clear meaning not subject to interpretation Compact – tightly worded without fluff or flourish Consistent – logically connected to others of its kind Compatible – common language with the business model and the

environment Power of business rules

Business-level statements translatable into requirements for an operational system

Combinational so that the value of the whole is greater than the sum of the individual requirements


Business Aspects of Rule Statements

Concerns Reducing/minimizing risks Improving customer service Optimizing utilization of (corporate) resources Controlling/managing workflow

Aspect ExamplesInformation consistency

Dates, modes of address, corporate styles. Establish so that such there is consistency of use throughout the enterprise.

Entity relationships

Relationships that must between entities that are relevant to the enterprise. Relationships may depend on particular conditions.

Situation identification

Recognition of common situations to allow standardized, predictable, and well-managed responses.

Data integrity Default values, computational algorithms, value and range validation, editing prior to capture.


Rule Content

Defines what the case should be Does not prescribe

Who invokes the rule When the rule is executed Where the rule executes How the rule is implemented

Two issues Why is a rule important When failure occurs, why did it happen?


Levels of Expression (Rules)

Informal – colloquial or natural language Technical

Structured data references Operators Constrained natural language

Formal – statements conforming to a more closely defined syntax with mathematical properties


Low-technology Rule Definition

FactModel

RuleText

AnalystAnalyst RuleStructure

DesignerDesigner DeveloperDeveloper

Business SignoffBusiness Signoff

ImplementationImplementation


Controlled Rule Definition

FactModel

RuleText

AnalystAnalyst

RuleStructure

DesignerDesigner DeveloperDeveloper

Business SignoffBusiness Signoff

FactDefiner

CodeGenerator

FactDefiner


RuleTemplate

TestTest


Long Term Objective For Business Rule Definition

FactModel

RuleText

RuleStructure

Business Business DefinitionDefinition

FactDefiner

CodeGenerator

RuleDefiner


RuleTemplate

OtherOthermodelmodel

elementselements


Cultural Impacts

Nature of work will change Increased computer and technology

literacy Increased business knowledge

Evolution of the information technology workforce From guildsman and artisans To engineers using commonly accepted

standards and processes Changing job descriptions

• Increasing job challenges and opportunities


Forming Rule Statements

Overview Pattern conventions Rule patterns


Rule Statements and Relationships

Fact Model

UML Classes

Rule Template

Business RuleStatement

RuleDatabase

FormalExpression

Implementation

View ofDefines

terms for Equates to

Translates to

Stored in

Stored inDefines structure for


Pattern Conventions (1)

Element Meaning

<det> The determiner of the subject taken from the following list: A, An, The, Each, Every, (nothing

<subject> A recognizable le business entity such as a business object visible in the fact model, a role name, or property of an object. The entity may be qualified by other descriptive elements (existence in a particular state) to specify the rule with necessary and sufficient precision.

<characteristic> The business behavior that must occur to enforce the relationship.

<fact> A relationship between terms identifiable in the fact model along with defined constants. The relationship may be qualified by other descriptive elements in order to precisely specify the applicability of the rule.

<fact-list> A list of <fact> items.

<m>, <n> Numeric parameters.

<result> A value (numeric or non-numeric) that has some business meaning. The result is often the value of the attribute of a business object.

<algorithm> A definition of the technique to be used to derive the value of a result. This element is normally expressed using combinations of variable terms identifiable in the facto model along with available appropriate constraints.

<classification> A definition of a term in the fact model. This typically defines either the value of an attribute, perhaps called “state”, or a subset of objects in existing classes.

<enum-list> A list of enumerated values. Open enumeration indicates that the list may be modified in the light of future requirements. Closed enumeration indicates that changes to the list are not anticipated.


Pattern Conventions (2)

Language elements Taken together, with rules for usage, create a grammar Rule patterns

Basic constraint – direct statement of condition List constraint – use one or more items from a list Classification – establishing a definition for using elements

of the fact model Computation – establishes a relationship between terms in

the fact model to allow determination or establishment of a value

Enumeration – establishes a range or set of values that can be taken by an element in the fact model


Fact Models

Shows artifacts with persistent values Business objects Relationships among business objects Attributes of business objects

Differentiate between items of business record versus operational artifacts with transient values


Rule Construction

Using facts Simple constraints Quantification and qualification States and events Actors Verb utilization Structure and consistency


Using Facts

Utilize a fact model Visible elements

Relate rule to elements in the business model Question basic assumptions; simplify by reducing any

associated qualifications Question terminology; be specific; do not generalize Establish explicit relationships so that constraints are

clearly defined Avoid facts and terms not adequately qualified

Use the “necessary and sufficient” standard Avoid vague terms


Simple Constraints Avoid unqualified terms that explicitly or implicitly grant

permissions Remember that the purpose of a rule is to define mandatory

and/or prohibited conditions Do not elaborate

Keep rules succinct and concise Make every word count

Do not use an ‘OR’ construct Decompose into multiple atomic rules

Use an ‘AND’ construct if and only if BOTH conditions must define truth

Avoid complexity and emphasize simplicity Every rule should be atomic and elementary Never use an ‘IF THEN ELSE’ construct in a business rule


Quantification and Qualification

Ask assessment questions Necessary Appropriate Correctness of ranges Correctness of specific values Specified elsewhere

Avoid using plurals of terms in rules Use ‘EACH’ and/or ‘EVERY’ where

appropriate


States and Events

A business event is a state Not a business action Cause rules to be evaluated Not subject of a rule

Be clear and unambiguous Terminology Time frames and time lines

Avoid conditionals statements ‘IF’ constructs ‘WHEN’ constructs


Actors

Be certain that actors are needed and clearly defined and described

Do not make actors the subject of rules


Dangerous Verbs

Command verb forms Action verbs

Create unclear definitions CRUD words

CreateReadUpdateDelete


Computation

Make the computational result the subject of the rule

Avoid embedded computations


Structure and Consistency Identify missing rules

Are all situations covered? Check for overlap

Boolean intersection Identify duplicate rules

Multiple rules saying the same things Be wary of inverted expression

Use straight forward wording Validate that rules do not conflict

Multiple rules producing contradictory results

Verify references among rule statements


Discovering Business Rules


Discovering Business Rules

Sources of Rules Kinds of Rules Information Sources Indicators

State Transition Theory Decision Trees Finding Rules

Static Analysis Interactive Sources Automated Discovery


Sources of Rules

Anywhere in the enterprise or extended enterprise

Anyone in the enterprise or extended enterprise Any time something is happening Any place something is happening

Discovery can happen without warning . . .Discovery can happen without warning . . .. . . never, ever be surprised. . . never, ever be surprised


Kinds of Rules

Structural Describe constraints and/or relationships among the

elements of the enterprise Behavioral

Define a course of action to be followed or process to be executed

Add detail to the process model (process architecture) Common features in workflow and information flow

environments Define recognition of and response to business events

Definitional Provide a (set of) value(s) that explain terminology and/or

relationships associated with elements of the enterprise


Information Sources

Documentation Causal elements/agents Explanatory/supportive materials History and relevancy

Tacit know-how Intellectual property

Automation systems Program source code

Business records Due diligence


Indicators in the Discovery Process

Externally-defined features and/or mandates

Systematic variations among organizational units

Entities with multiple states

Specializations Subclasses

Automated decision making

Boundary definitions Time-centricity Quality standards

and specifications ISO 9000

Significant discriminators

Event-based activities

Definitions, derivations, and calculations


State Transition Theory

Describes conditions and outcomes Identifies

Prior state Action Succeeding state

State Transition Diagram documents flows across an environment Enterprise Information system


State Transition Diagram

CurrentCurrentStateState

Next StateNext State(Alternative 3)(Alternative 3)



Action 1Action 1

Action 3Action 3

Action 2Action 2


State Transitions

CurrentCurrentStateStatePrior State 2Prior State 2

Prior State 3Prior State 3

Prior State 1Prior State 1

ActiActionon

ActionAction

ActionAction

•Current state can be Current state can be reached from multiple reached from multiple prior states prior states•Actions on prior states Actions on prior states likely to be dissimilar likely to be dissimilar•Transition from Transition from current state to next current state to next state not usually state not usually dependent on arrival dependent on arrival from prior state from prior state


Decision Trees

Pictorial depiction of thought processing Network based on decisions and

uncertainty analysis Probabilistic Risk-associative

Howard Raiffa, Decision Analysis: Introductory Lectures on Choices under Uncertainty, 1970, Addison-Wesley, Library of Congress Catalog 68-31436


Decision Tree Schematic

pp

pp

pp

Given this stateGiven this state

Any of these statesAny of these statesare possibleare possible

Probability of each state is pp

Following stateFollowing statedetermined bydetermined bypreceding eventspreceding eventsand decisionsand decisions


Finding Rules

Organizing ApproachesStatic analysisInteractive sessionsAutomated rule discovery

Source Static Analysis Interactive Sessions Automated Discovery

Documentation High Moderate Unreliable

Tacit know-how Not Applicable High Not Applicable

Automation systems Low Moderate High

Business Records Depends on Source Low Depends on Source


Static Analysis

Types of source documents Internal External

Analyzing documents1. Get an electronic copy2. Develop a system and follow it3. Read carefully (usually between the lines)4. Focus on early correctness; worry structure, traceability,

and cross-referencing later.5. Align with current business model; identify conflicts and

disconnects; demand clarity6. Focus on stakeholder understanding; keep political

constraints in sight7. Identify open issues; assign action items


Interactive Sessions Participatory session involving both technical

and business practioners Involves dialog and sharing Two forms

• Structured interviews• Analysis workshops

Characteristics

Feature

Session Type

Interview Workshop

Typical number of participants 2 or 3 6 to 10

Typical Duration .5 <= x <= several hours Several days

Area of business expertise explored Single Multiple

Logistics Simple Complex

Typical venue Personal office Conference room


Interactive Sessions

Structured Interviews

1. Research and understand interviewee

2. Observe usual courtesies

3. Keep careful notes4. Make records5. Provide feedback

Analysis Workshops1. Define the goal and

the approach2. Prepare, prepare,

prepare!3. Facilitate the

workshop session4. Execute follow-up

actions and requirements

5. Review


Workshop Activity Cycle

ReviewReview

Workshop Workshop PreparationPreparation

Define AnalysisDefine AnalysisTopic & ApproachTopic & Approach

Next Project StateNext Project State

WorkshopWorkshopSessionSession

ImmediateImmediateFollow-upFollow-upActivitiesActivities

ConsolidationConsolidation& Research& Research

Review Review Appropriate?Appropriate?

NoNo

YesYes


Automated Discovery

Data mining Code analysis

ManualAutomated


Automated Code Analysis*

Texas Instruments, Texas Instruments, A Guide to Information Engineering Using the IEFA Guide to Information Engineering Using the IEF, 1988, TI Part Number 2739756-0001, 1988, TI Part Number 2739756-0001

INFORMATIONINFORMATIONENGINEERINGENGINEERING

FACILITYFACILITY(IEF)(IEF)

SOURCESOURCEPROGRAMSPROGRAMS

DATADATADEFINITIONSDEFINITIONS

DATA FLOWDATA FLOWDIAGRAMSDIAGRAMS

ENTITY ENTITY RELATIONSHIPRELATIONSHIP

DIAGRAMSDIAGRAMS

USE CASESUSE CASESDIAGRAMSDIAGRAMS

ASSOCIATEDASSOCIATEDDOCUMENTSDOCUMENTS


Automated Code Analysis*

Texas Instruments, Texas Instruments, A Guide to Information Engineering Using the IEFA Guide to Information Engineering Using the IEF, 1988, TI Part Number 2739756-0001, 1988, TI Part Number 2739756-0001


FACILITYFACILITY(IEF)(IEF)

SOURCESOURCEPROGRAMSPROGRAMS

DATADATADEFINITIONSDEFINITIONS

DATA FLOWDATA FLOWDIAGRAMSDIAGRAMS

ENTITY ENTITY RELATIONSHIPRELATIONSHIP

DIAGRAMSDIAGRAMS

USE CASESUSE CASESDIAGRAMSDIAGRAMS

ASSOCIATEDASSOCIATEDDOCUMENTSDOCUMENTS

Repository Repository


FACILITYFACILITY

(IEF)(IEF)

DATABASEDATABASESCHEMASCHEMA

PROGRAMPROGRAM‘‘SOURCESOURCE

CODECODE

EDITSEDITS


The Language of Business Rules

Creating a Grammar


Salient Points

Rules govern all business operations Business rules are everywhere

Nearly every medium imaginable Nearly unbounded number of formats Often not written down

Business rules need to be documented “Of record” documentation supporting business

operations, including legal compliance Capture “enterprise knowledge” to preserve

corporate intelligence Standard language required

Applicable across business areas Consistent with organization’s culture Consistent with IT protocols


Grammar Discussed

Elements and rules of a language Language elements

Lexical – “parts of speech” Syntax – rules governing use of lexical

elements Applies to any language

Written Spoken Computer


Levels of Language for Business Rules

User level – the common language that functional experts will use to write business rules

Computer level – the common language that the computer will use to store business rules in a processable format


User-Level Grammar<rule>::<condition><verb><action>

<condition>::<business_object>

<relationship><value>

<business_object>::<an element involved in business operations

<relationship>::eq|neq|gt|lt|ge|ge

<value>::<string>

<string>::<alphbet<<numeric>|<alphanumeric>

<alphabet>::a|b|…|y|z|A|B|…|Y|Z

<numeric>::0|1|2|3|4|5|6|7|8|9

<alphanumeric>::<alphabet><numeric>

<verb>::<mandatory>|<preferred>

<mandatory>::shall|must

<preferred>::will|may|can|could|should|would

<action>::perform<sentence>|compute<equation>

<equation>::<business_object> = <formula>

<formula>::<business_object><math_op>constant>|<business_object><math_op><business_object>

<mat_op>::+|-|*|/|^

<constant>::{e|real number}

NOTES:: Representation{ } Set notation| Denotes ‘or’


Processing Business Rules in User-Level Language

BusinessRules in

.doc or .txt

1. Identifies lexicalelements

2. Validates lexicalelements

3. Formats result

BusinessRules in

.dat

PARSER

EXTRACTIONPROGRAM

DBMS

RULEBASE

Business rules in user level languageare stored here

Business rules in user level languageare converted to a computer-processableformat


Computer-Processable Format for Business Rules

Flat-file input record format

Fields Business area Rule number Mandatory indicator

flag Business object Relationship Business object

value Action Sentence Formula

Record definition Business area is

user-provided Rule number is

automatically generated within business area

Sentence is required if action is “perform” and formula must be omitted

Formula is required if action is “compute” and sentence must be omitted


Flat File Record Layout

BusinessArea

RuleNumber M

an

dFla

g BusinessObject

Relation Action Sentence Formula



BusinessRules in

.doc or .txt



3. Formats result

BusinessRules in

.dat

PARSER

EXTRACTIONPROGRAM

DBMS

RULEBASE



Record definition is thegrammar of the parseroutput


The Extraction Program

Assume the existence of a database table RULES Use the flat file from slide 8 (FFILE) The pseudo code:

Read a record from FFILEExec SQLInsert into RULES

(bus_area, rul_num, mflag, bus_obj, relat, bus_obj_val, action, sentence)VALUES(FFILE.business_area, FFILE.rule_number, FFILE.mandflag, FFILE.business_object, FFILE.relation, FFILE.action, FFILE.sentence);

End SQLNext

Note – above SQL uses action = perform; if action = compute, substitute formula



BusinessRules in

.doc or .txt



3. Formats result

BusinessRules in

.dat

PARSER

EXTRACTIONPROGRAM

DBMS

RULEBASE



Record definition is thegrammar of the parseroutput

Business rules in DBMS languageare stored here


Summary

Business rules need a language of expression

Three levels of languageUser preparationUser expression – parsedRule base storage

StructureElementsConstructs Rules

business rules © ed green penn state university all rights reserved

Documents