Presentation is loading. Please wait.

Presentation is loading. Please wait.

Business Rules © Ed Green Penn State University All Rights Reserved.

Similar presentations


Presentation on theme: "Business Rules © Ed Green Penn State University All Rights Reserved."— Presentation transcript:

1 Business Rules © Ed Green Penn State University All Rights Reserved

2 1/15/2015Business Rules2 Topics What business rules are Why business rules are important Problems with business rules Language of business rules

3 1/15/2015Business Rules3 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

4 1/15/2015Business Rules4 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.

5 1/15/2015Business Rules5 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

6 1/15/2015Business Rules6 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

7 1/15/2015Business Rules7 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

8 1/15/2015Business Rules8 Building Software – Current Process Business Owner Operational System Business Descriptions Analyst Deployment Constraints Developer Evaluate, Use (Redefine Interpret Interact Structured System Descriptions Test Generate Source Code Tester Define Interpret Interact Code Errors Software Modules Software Modules Create, Refine Define System Development System Administrator Integrate Deploy (Redefine

9 1/15/2015Business Rules9 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

10 1/15/2015Business Rules10 System Development Vision Business Owner Operational System Generate Software Modules Software Modules Evaluate, Use Structured Business Descriptions Structured Business Descriptions Human Readable Views Human Readable Views Machine Readable Views Machine Readable Views Structured Deployment components Structured Deployment components System Development Review (Redefine Manage Deploy

11 1/15/2015Business Rules11 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

12 1/15/2015Business Rules12 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

13 1/15/2015Business Rules13 Practicality of the Vision Realistic steps 1. Increase structure for describing business needs 2. Improve structure for describing computing environment 3. Generate code fragments from enhanced business descriptions 4. 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.

14 1/15/2015Business Rules14 Defining Business Rules Rule statements Forming rule statements Construction rules

15 1/15/2015Business Rules15 Rule Statements Characteristics Business Aspects of Rule Statements Rule Contents Expression Levels Rule Definition Options Culture Impacts

16 1/15/2015Business Rules16 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

17 1/15/2015Business Rules17 Business Aspects of Rule Statements Concerns Reducing/minimizing risks Improving customer service Optimizing utilization of (corporate) resources Controlling/managing workflow AspectExamples 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 integrityDefault values, computational algorithms, value and range validation, editing prior to capture.

18 1/15/2015Business Rules18 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?

19 1/15/2015Business Rules19 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

20 1/15/2015Business Rules20 Low-technology Rule Definition Fact Model Rule Text Analyst Rule Structure Designer Developer Business Signoff Implementation

21 1/15/2015Business Rules21 Controlled Rule Definition Fact Model Rule Text Analyst Rule Structure DesignerDeveloper Business Signoff Fact Definer Code Generator Fact Definer Implementation Rule Template Test

22 1/15/2015Business Rules22 Long Term Objective For Business Rule Definition Fact Model Rule Text Rule Structure BusinessDefinition Fact Definer Code Generator Rule Definer Implementation Rule Template Other model elements

23 1/15/2015Business Rules23 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

24 1/15/2015Business Rules24 Forming Rule Statements Overview Pattern conventions Rule patterns

25 1/15/2015Business Rules25 Rule Statements and Relationships Fact Model UML Classes Rule Template Business Rule Statement Rule Database Formal Expression Implementation View of Defines terms for Equates to Translates to Stored in Defines structure for

26 1/15/2015Business Rules26 Pattern Conventions (1) ElementMeaning The determiner of the subject taken from the following list: A, An, The, Each, Every, (nothing 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. The business behavior that must occur to enforce the relationship. 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. A list of items., Numeric parameters. A value (numeric or non-numeric) that has some business meaning. The result is often the value of the attribute of a business object. 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. 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. 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.

27 1/15/2015Business Rules27 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

28 1/15/2015Business Rules28 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

29 1/15/2015Business Rules29 Rule Construction Using facts Simple constraints Quantification and qualification States and events Actors Verb utilization Structure and consistency

30 1/15/2015Business Rules30 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

31 1/15/2015Business Rules31 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

32 1/15/2015Business Rules32 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

33 1/15/2015Business Rules33 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

34 1/15/2015Business Rules34 Actors Be certain that actors are needed and clearly defined and described Do not make actors the subject of rules

35 1/15/2015Business Rules35 Dangerous Verbs Command verb forms Action verbs Create unclear definitions CRUD words Create Read Update Delete

36 1/15/2015Business Rules36 Computation Make the computational result the subject of the rule Avoid embedded computations

37 1/15/2015Business Rules37 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

38 1/15/2015Business Rules38 Discovering Business Rules

39 1/15/2015Business Rules39 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

40 1/15/2015Business Rules40 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 never, ever be surprised

41 1/15/2015Business Rules41 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

42 1/15/2015Business Rules42 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

43 1/15/2015Business Rules43 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

44 1/15/2015Business Rules44 State Transition Theory Describes conditions and outcomes Identifies Prior state Action Succeeding state State Transition Diagram documents flows across an environment Enterprise Information system

45 1/15/2015Business Rules45 State Transition Diagram CurrentState Next State (Alternative 3) Next State (Alternative 2) Next State (Alternative 1) Action 1 Action 3 Action 2

46 1/15/2015Business Rules46 State Transitions CurrentState Prior State 2 Prior State 3 Prior State 1 Action Action Action Current state can be reached from multiple prior statesCurrent state can be reached from multiple prior states Actions on prior states likely to be dissimilarActions on prior states likely to be dissimilar Transition from current state to next state not usually dependent on arrival from prior stateTransition from current state to next state not usually dependent on arrival from prior state

47 1/15/2015Business Rules47 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

48 1/15/2015Business Rules48 Decision Tree Schematic p p p Given this state Any of these states are possible Probability of each p state is p Following state determined by preceding events and decisions

49 1/15/2015Business Rules49 Finding Rules Organizing Approaches Static analysis Interactive sessions Automated rule discovery SourceStatic AnalysisInteractive SessionsAutomated Discovery DocumentationHighModerateUnreliable Tacit know-howNot ApplicableHighNot Applicable Automation systemsLowModerateHigh Business RecordsDepends on SourceLowDepends on Source

50 1/15/2015Business Rules50 Static Analysis Types of source documents Internal External Analyzing documents 1. Get an electronic copy 2. Develop a system and follow it 3. 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 clarity 6. Focus on stakeholder understanding; keep political constraints in sight 7. Identify open issues; assign action items

51 1/15/2015Business Rules51 Interactive Sessions Participatory session involving both technical and business practioners Involves dialog and sharing Two forms Structured interviews Analysis workshops Characteristics Feature Session Type InterviewWorkshop Typical number of participants2 or 36 to 10 Typical Duration.5 <= x <= several hoursSeveral days Area of business expertise exploredSingleMultiple LogisticsSimpleComplex Typical venuePersonal officeConference room

52 1/15/2015Business Rules52 Interactive Sessions Structured Interviews 1. Research and understand interviewee 2. Observe usual courtesies 3. Keep careful notes 4. Make records 5. Provide feedback Analysis Workshops 1. Define the goal and the approach 2. Prepare, prepare, prepare! 3. Facilitate the workshop session 4. Execute follow-up actions and requirements 5. Review

53 1/15/2015Business Rules53 Workshop Activity Cycle Review WorkshopPreparation Define Analysis Topic & Approach Next Project State WorkshopSession ImmediateFollow-upActivities Consolidation & Research Review Appropriate? No Yes

54 1/15/2015Business Rules54 Automated Discovery Data mining Code analysis Manual Automated

55 1/15/2015Business Rules55 Automated Code Analysis* Texas Instruments, A Guide to Information Engineering Using the IEF, 1988, TI Part Number INFORMATIONENGINEERINGFACILITY(IEF) SOURCEPROGRAMS DATADEFINITIONS DATA FLOW DIAGRAMS ENTITYRELATIONSHIPDIAGRAMS USE CASES DIAGRAMS ASSOCIATEDDOCUMENTS

56 1/15/2015Business Rules56 Automated Code Analysis* Texas Instruments, A Guide to Information Engineering Using the IEF, 1988, TI Part Number INFORMATIONENGINEERINGFACILITY(IEF) SOURCEPROGRAMS DATADEFINITIONS DATA FLOW DIAGRAMSENTITYRELATIONSHIPDIAGRAMS USE CASES DIAGRAMS ASSOCIATEDDOCUMENTS Repository INFORMATIONENGINEERINGFACILITY(IEF) DATABASESCHEMAPROGRAM‘SOURCECODE EDITS

57 1/15/2015Business Rules57 The Language of Business Rules Creating a Grammar

58 1/15/2015Business Rules58 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

59 1/15/2015Business Rules59 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

60 1/15/2015Business Rules60 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

61 1/15/2015Business Rules61 User-Level Grammar :: ::| ::+|-|*|/|^ ::{e|real number} NOTES ::  Representation { }  Set notation |  Denotes ‘or’

62 1/15/2015Business Rules62 Processing Business Rules in User-Level Language Business Rules in.doc or.txt 1.Identifies lexical elements 2.Validates lexical elements 3.Formats result Business Rules in.dat PARSER EXTRACTION PROGRAM DBMS RULE BASE Business rules in user level language are stored here Business rules in user level language are converted to a computer-processable format

63 1/15/2015Business Rules63 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

64 1/15/2015Business Rules64 Flat File Record Layout Business Area Rule Number Mand Flag Business Object RelationActionSentenceFormula

65 1/15/2015Business Rules65 Processing Business Rules in User-Level Language Business Rules in.doc or.txt 1.Identifies lexical elements 2.Validates lexical elements 3.Formats result Business Rules in.dat PARSER EXTRACTION PROGRAM DBMS RULE BASE Business rules in user level language are stored here Business rules in user level language are converted to a computer-processable format Record definition is the grammar of the parser output

66 1/15/2015Business Rules66 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

67 1/15/2015Business Rules67 Processing Business Rules in User-Level Language Business Rules in.doc or.txt 1.Identifies lexical elements 2.Validates lexical elements 3.Formats result Business Rules in.dat PARSER EXTRACTION PROGRAM DBMS RULE BASE Business rules in user level language are stored here Business rules in user level language are converted to a computer-processable format Record definition is the grammar of the parser output Business rules in DBMS language are stored here

68 1/15/2015Business Rules68 Summary Business rules need a language of expression Three levels of language User preparation User expression – parsed Rule base storage Structure Elements Constructs Rules


Download ppt "Business Rules © Ed Green Penn State University All Rights Reserved."

Similar presentations


Ads by Google