Download presentation
Presentation is loading. Please wait.
1
Business Rules © Ed Green Penn State University All Rights Reserved
2
Topics What business rules are Why business rules are important
Problems with business rules Language of business rules Business Rules 4/8/2017
3
Concept of Business Rules
Set of underlying principles that provide enterprise governance and guidance Allows for variations across enterprises Many points of similarity External forces Common goals Business Rules 4/8/2017
4
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. Business Rules 4/8/2017
5
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 Business Rules 4/8/2017
6
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 Business Rules 4/8/2017
7
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 Business Rules 4/8/2017
8
Building Software – Current Process
Business Descriptions (Redefine Operational System Deploy Evaluate, Use Interpret Interact Business Owner (Redefine System Administrator Deployment Constraints Integrate Analyst Interact Interact Software Modules Define Code Errors Developer Test Interpret Define Tester Structured System Descriptions Create, Refine Source Code System Development Generate Business Rules 4/8/2017
9
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 expensive Business Rules 4/8/2017
10
System Development Vision
Evaluate, Use Operational System Deploy (Redefine Business Owner Review Structured Business Descriptions Human Readable Views Structured Deployment components Manage (Redefine Software Modules Generate Machine Readable Views Generate Generate System Development Business Rules 4/8/2017
11
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 Business Rules 4/8/2017
12
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 Business Rules 4/8/2017
13
Practicality of the Vision
Realistic steps Increase structure for describing business needs Improve structure for describing computing environment Generate code fragments from enhanced business descriptions Focus development on refinement/extension of generated code vis a vis creation. Accept, within limits, some degree of inefficiency Package developed software in component form; simplify subsequent management/deployment; focus on interfaces; hide implementation details Emphasize process improvement; use the best people; quantify, measure and continually review the process. Reduce common system elements to manageable/reusable templates. Increase levels of commonality. Move differentiators into rule sets. Business Rules 4/8/2017
14
Defining Business Rules
Rule statements Forming rule statements Construction rules Business Rules 4/8/2017
15
Rule Statements Characteristics Business Aspects of Rule Statements
Rule Contents Expression Levels Rule Definition Options Culture Impacts Business Rules 4/8/2017
16
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 Rules 4/8/2017
17
Business Aspects of Rule Statements
Concerns Reducing/minimizing risks Improving customer service Optimizing utilization of (corporate) resources Controlling/managing workflow Aspect Examples Information 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. Business Rules 4/8/2017
18
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? Business Rules 4/8/2017
19
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 Business Rules 4/8/2017
20
Low-technology Rule Definition
Fact Model Rule Text Rule Structure Implementation Analyst Developer Designer Business Signoff Business Rules 4/8/2017
21
Controlled Rule Definition
Designer Developer Implementation Code Generator Fact Model Test Rule Structure Fact Definer Fact Definer Analyst Business Signoff Rule Template Rule Text Business Rules 4/8/2017
22
Long Term Objective For Business Rule Definition
Other model elements Code Generator Implementation Fact Model Business Definition Rule Structure Fact Definer Rule Definer Rule Template Rule Text Business Rules 4/8/2017
23
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 Business Rules 4/8/2017
24
Forming Rule Statements
Overview Pattern conventions Rule patterns Business Rules 4/8/2017
25
Rule Statements and Relationships
UML Classes Implementation View of Translates to Defines terms for Equates to Fact Model Business Rule Statement Formal Expression Stored in Rule Template Rule Database Defines structure for Stored in Business Rules 4/8/2017
26
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. Business Rules 4/8/2017
27
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 Business Rules 4/8/2017
28
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 Business Rules 4/8/2017
29
Rule Construction Using facts Simple constraints
Quantification and qualification States and events Actors Verb utilization Structure and consistency Business Rules 4/8/2017
30
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 Business Rules 4/8/2017
31
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 Business Rules 4/8/2017
32
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 Business Rules 4/8/2017
33
States and Events A business event is a state Be clear and unambiguous
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 Business Rules 4/8/2017
34
Actors Be certain that actors are needed and clearly defined and described Do not make actors the subject of rules Business Rules 4/8/2017
35
Dangerous Verbs Command verb forms Action verbs CRUD words
Create unclear definitions CRUD words Create Read Update Delete Business Rules 4/8/2017
36
Computation Make the computational result the subject of the rule
Avoid embedded computations Business Rules 4/8/2017
37
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 Business Rules 4/8/2017
38
Discovering Business Rules
4/8/2017
39
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 Business Rules 4/8/2017
40
Sources of Rules Discovery can happen without warning . . .
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 . . . never, ever be surprised Business Rules 4/8/2017
41
Kinds of Rules Structural Behavioral Definitional
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 Business Rules 4/8/2017
42
Information Sources Documentation Tacit know-how Automation systems
Causal elements/agents Explanatory/supportive materials History and relevancy Tacit know-how Intellectual property Automation systems Program source code Business records Due diligence Business Rules 4/8/2017
43
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 Business Rules 4/8/2017
44
State Transition Theory
Describes conditions and outcomes Identifies Prior state Action Succeeding state State Transition Diagram documents flows across an environment Enterprise Information system Business Rules 4/8/2017
45
State Transition Diagram
Next State (Alternative 1) Action 1 Action 2 Current State Next State (Alternative 2) Action 3 Next State (Alternative 3) Business Rules 4/8/2017
46
State Transitions Action Prior State 1
Current state can be reached from multiple prior states Actions on prior states likely to be dissimilar Transition from current state to next state not usually dependent on arrival from prior state Action Prior State 2 Current State Prior State 3 Action Business Rules 4/8/2017
47
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 Business Rules 4/8/2017
48
Decision Tree Schematic
Any of these states are possible p Following state determined by preceding events and decisions Probability of each state is p p Given this state p Business Rules 4/8/2017
49
Finding Rules Organizing Approaches Static analysis
Interactive sessions Automated rule discovery Source Static Analysis Interactive Sessions Automated Discovery Documentation High Moderate Unreliable Tacit know-how Not Applicable Automation systems Low Business Records Depends on Source Business Rules 4/8/2017
50
Static Analysis Types of source documents Analyzing documents Internal
External Analyzing documents Get an electronic copy Develop a system and follow it Read carefully (usually between the lines) Focus on early correctness; worry structure, traceability, and cross-referencing later. Align with current business model; identify conflicts and disconnects; demand clarity Focus on stakeholder understanding; keep political constraints in sight Identify open issues; assign action items Business Rules 4/8/2017
51
.5 <= x <= several hours
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 Business Rules 4/8/2017
52
Interactive Sessions Structured Interviews Analysis Workshops
Research and understand interviewee Observe usual courtesies Keep careful notes Make records Provide feedback Analysis Workshops Define the goal and the approach Prepare, prepare, prepare! Facilitate the workshop session Execute follow-up actions and requirements Review Business Rules 4/8/2017
53
Workshop Activity Cycle
Next Project State Define Analysis Topic & Approach Review Workshop Preparation Yes Workshop Session No Review Appropriate? Immediate Follow-up Activities Consolidation & Research Business Rules 4/8/2017
54
Automated Discovery Data mining Code analysis Manual Automated
Business Rules 4/8/2017
55
Automated Code Analysis*
DATA FLOW DIAGRAMS INFORMATION ENGINEERING FACILITY (IEF) SOURCE PROGRAMS ENTITY RELATIONSHIP DIAGRAMS USE CASES DIAGRAMS DATA DEFINITIONS ASSOCIATED DOCUMENTS Texas Instruments, A Guide to Information Engineering Using the IEF, 1988, TI Part Number Business Rules 4/8/2017
56
Automated Code Analysis*
Repository INFORMATION ENGINEERING FACILITY (IEF) SOURCE PROGRAMS DATA DEFINITIONS DATA FLOW DIAGRAMS ENTITY RELATIONSHIP USE CASES ASSOCIATED DOCUMENTS INFORMATION ENGINEERING FACILITY (IEF) EDITS DATABASE SCHEMA PROGRAM ‘SOURCE CODE Texas Instruments, A Guide to Information Engineering Using the IEF, 1988, TI Part Number Business Rules 4/8/2017
57
The Language of Business Rules
Creating a Grammar Business Rules 4/8/2017
58
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 Business Rules 4/8/2017
59
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 Business Rules 4/8/2017
60
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 Business Rules 4/8/2017
61
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’ Business Rules 4/8/2017
62
Processing Business Rules in User-Level Language
Rules in .doc or .txt Business Rules in .dat Identifies lexical elements Validates lexical elements Formats result PARSER EXTRACTION PROGRAM DBMS Business rules in user level language are stored here RULE BASE Business rules in user level language are converted to a computer-processable format Business Rules 4/8/2017
63
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 Business Rules 4/8/2017
64
Flat File Record Layout
Business Area Rule Number Mand Flag Object Relation Action Sentence Formula Business Rules 4/8/2017
65
Processing Business Rules in User-Level Language
Record definition is the grammar of the parser output Business Rules in .doc or .txt Business Rules in .dat Identifies lexical elements Validates lexical elements Formats result PARSER EXTRACTION PROGRAM DBMS Business rules in user level language are stored here RULE BASE Business rules in user level language are converted to a computer-processable format Business Rules 4/8/2017
66
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 FFILE Exec SQL Insert 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 SQL Next Note – above SQL uses action = perform; if action = compute, substitute formula Business Rules 4/8/2017
67
Processing Business Rules in User-Level Language
Record definition is the grammar of the parser output Business Rules in .doc or .txt Business Rules in .dat Identifies lexical elements Validates lexical elements Formats result PARSER EXTRACTION PROGRAM DBMS Business rules in user level language are stored here RULE BASE Business rules in user level language are converted to a computer-processable format Business rules in DBMS language are stored here Business Rules 4/8/2017
68
Summary Business rules need a language of expression
Three levels of language User preparation User expression – parsed Rule base storage Structure Elements Constructs Rules Business Rules 4/8/2017
Similar presentations
