Business Rules © Ed Green Penn State University All Rights Reserved

Topics What business rules are Why business rules are important Problems with business rules Language of business rules Business Rules 4/8/2017

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

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

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

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

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

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

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

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

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

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

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

Defining Business Rules Rule statements Forming rule statements Construction rules Business Rules 4/8/2017

Rule Statements Characteristics Business Aspects of Rule Statements Rule Contents Expression Levels Rule Definition Options Culture Impacts Business Rules 4/8/2017

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

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

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

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

Low-technology Rule Definition Fact Model Rule Text Rule Structure Implementation Analyst Developer Designer Business Signoff Business Rules 4/8/2017

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

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

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

Forming Rule Statements Overview Pattern conventions Rule patterns Business Rules 4/8/2017

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

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

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

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

Rule Construction Using facts Simple constraints Quantification and qualification States and events Actors Verb utilization Structure and consistency Business Rules 4/8/2017

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

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

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

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

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

Dangerous Verbs Command verb forms Action verbs CRUD words Create unclear definitions CRUD words Create Read Update Delete Business Rules 4/8/2017

Computation Make the computational result the subject of the rule Avoid embedded computations Business Rules 4/8/2017

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

Discovering Business Rules 4/8/2017

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

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

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

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

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

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

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

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

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 Business Rules 4/8/2017

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

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

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

.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

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

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

Automated Discovery Data mining Code analysis Manual Automated Business Rules 4/8/2017

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 2739756-0001 Business Rules 4/8/2017

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 2739756-0001 Business Rules 4/8/2017

The Language of Business Rules Creating a Grammar Business Rules 4/8/2017

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

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

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

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

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

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

Flat File Record Layout Business Area Rule Number Mand Flag Object Relation Action Sentence Formula Business Rules 4/8/2017

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

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

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

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