Business Rules Framework

3,953 views

Published on

A presentation of a business rules framework and methodology for all aspects of a business rules project including: Planning, Rule Discovery, Analysis, Modeling, Design and Delivery

0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,953
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
0
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

Business Rules Framework

  1. 1. Contents Scope Project Plan Iterative Development Planning Rule Sources Knowledge Elicitation Discovery Organization Modularization Rule Discovery Analysis Behavior Model Data Model Process Model Modeling Design Implementation Verification Rule Management Delivery Presented by: Joe DiGiovanni Business Rules Forum November 2004 Standards Rule Architecture Rule Details
  2. 2. Planning <ul><li>Iterative Systems Development </li></ul><ul><ul><li>Iterative project lifecycle favored over Waterfall approach for rules projects </li></ul></ul><ul><ul><li>Divide project into iterations to gain greater control and mitigate risk </li></ul></ul><ul><ul><li>Each iteration involves a distinct set of activities with a well defined result </li></ul></ul><ul><li>Project Scope </li></ul><ul><ul><li>Define initial project scope </li></ul></ul><ul><ul><li>Identify and engage project stakeholders </li></ul></ul><ul><ul><li>Define project outcomes and deliverables </li></ul></ul>Scope Project Plan Iterative Development <ul><li>Project Plan </li></ul><ul><ul><li>Guidelines for business rules projects </li></ul></ul><ul><ul><li>Use a schedule tracking tool such as Excel or MS Project </li></ul></ul>
  3. 3. Planning – Project Scope Define Initial Project Scope <ul><li>Determine overall size, complexity, and cost of the project </li></ul><ul><li>Identify the risks and benefits of the project </li></ul>Identify and Engage Project Stakeholders Define Project Outcomes and Deliverables <ul><li>Define requirements of the system, expected outputs, and acceptance criteria </li></ul><ul><li>Define the project deliverables, taking into account assumptions, limitations and dependencies </li></ul><ul><li>Determine what the project intends to achieve – the Project Plan will determine how it is achieved </li></ul><ul><li>Stakeholders are those that have an impact on or are impacted by the proposed project </li></ul><ul><li>They ensure the scope is in line with strategic company goals, standards, and policies </li></ul><ul><li>Stakeholders must reach agreement on project outcomes and deliverables </li></ul>
  4. 4. Planning - Project Plan Guidelines for a Business Rules Project Plan <ul><li>Serves as a road map, providing direction for project managers to follow - including Work Breakdown Schedule (WBS) and resource allocation in a projected timeline </li></ul><ul><li>Needs to account for change in direction or detours </li></ul><ul><li>Set of living documents that will change over the course of project </li></ul><ul><li>Establish baseline with multiple checkpoints and performance measures </li></ul><ul><li>Always schedule enough time for reviews, testing, and debugging - including design reviews, code reviews, test plan reviews, unit testing, user acceptance testing, and post production testing * Test plans are just as important as the project plan </li></ul><ul><li>Use a schedule tracking tool such as Excel or MS Project to: - estimate how long a project should take - track what resources are needed and when - plan the order of the tasks - manage dependencies between tasks - aid with risk mitigation and unforeseen schedule impacts - continually provide an overall view of the project timeline </li></ul>
  5. 5. Planning - Iterative Systems Development Rules projects favor an Iterative project lifecycle over the Waterfall approach <ul><li>Divide project into iterations to gain greater control and mitigate risk </li></ul><ul><li>Each iteration involves a distinct set of activities with a well defined result </li></ul><ul><li>Each iteration through the phases will reduce the amount of change and risk </li></ul><ul><li>Plan multiple iterations ahead of time, ensuring the right tasks are in each iteration </li></ul><ul><li>Keep to the plan for each iteration - complete each iteration before moving to the next iteration - avoid iterative nature as an excuse to “finish things in the next iteration” - prevent scope creep iteration to iteration </li></ul><ul><li>Project plan requires continuous rework and will always be in flux </li></ul>Tips for an Iterative project lifecycle plan START Planning Discovery Modeling Design Analysis Delivery
  6. 6. Planning - Iterative vs. Waterfall Iterative Project Lifecycle <ul><li>More work to set up, plan, control, track </li></ul><ul><li>Discover problems and validates architecture earlier </li></ul><ul><li>Better predictability – remove risks at each iteration </li></ul><ul><li>Scales better – easier for engineering team </li></ul><ul><li>Requires the right tasks in each cycle and planning multiple cycles at a time </li></ul><ul><li>Classic project management approach </li></ul><ul><li>Many hard problems and risky items are pushed later in the process </li></ul><ul><li>Architecture is not validated until coding begins more than half way into the project </li></ul><ul><li>More rework at the end of each cycle and later in the project </li></ul>Classic Waterfall Approach START Planning Discovery Modeling Design Analysis Delivery Requirements Analysis Development Verification Design Delivery
  7. 7. Discovery Standards Rule Sources <ul><li>Identify Rule Sources </li></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Policies </li></ul></ul><ul><ul><li>Documentation / Manuals </li></ul></ul><ul><ul><li>Computer Code / Legacy Systems </li></ul></ul><ul><li>Establish and Follow Rule Standards </li></ul><ul><ul><li>Rule Templates </li></ul></ul><ul><ul><li>Rule Set Templates </li></ul></ul><ul><ul><li>Rule Table Templates </li></ul></ul><ul><ul><li>Rule Naming Conventions </li></ul></ul><ul><li>Identify High-Level Business Rule Statements and Business Rules </li></ul><ul><ul><li>Business Rule Statement - needs to be transformed into one or more business rules </li></ul></ul><ul><ul><li>High Level Business Rule - can be broken down further into atomic business rules </li></ul></ul>Knowledge Elicitation
  8. 8. Discovery - Rule Sources Step 1 – Identify rule sources from where the rules will be elicited Rule Elicitation <ul><li>Computer Code - from existing or legacy systems </li></ul><ul><li>People - subject matter experts - managers with company knowledge </li></ul><ul><li>Manuals - system documentation - written company policies - guideline manuals </li></ul>Standards Rule Sources Rule Templates
  9. 9. Discovery – Rule Standards Step 2 – Establish and follow rule standards and guidelines Rule Elicitation <ul><li>Rule Templates - use Rule and Rule Set Templates - guide the rule elicitation process - provide consistent structure for entire project </li></ul><ul><li>Rule Naming Conventions - identify a consistent way to name rules - publish standard to team / organization - include keywords in rule names Use names that describe and group rules and rule sets together </li></ul>Standards <ul><li>Rule Sets and Knowledgebases - mechanisms for organizing rules - rules should be grouped consistently - by product line, subject area, process </li></ul>Rule Sources Rule Templates
  10. 10. Discovery – Business Rule Statements Step 3 – Identify high level business rules and business rule statements Rule Elicitation <ul><li>Atomic Business Rules - rules in their simplest form - expressed in “IF-THEN” form - also called the “Condition-Action” form - when all of the conditions are true, the actions are executed </li></ul><ul><li>Business Rule Statements - similar to a policy statement - will be transformed into one or more business rules </li></ul>Standards <ul><li>High Level Business Rules - complex business rules - need to be broken down into multiple atomic business rules </li></ul>Rule Sources Rule Templates
  11. 11. Discovery – Rule Templates Step 4 – Capture business rules and rule statements in rule templates Rule Elicitation <ul><li>Guidelines for Templates - define rules in their simplest form - typically filled in electronically - can be stored in a database called a Rule Repository </li></ul><ul><li>Rule Templates - provide structure for rule declarations - ensure all relative details captured from the rule elicitation process are retained - include documentation </li></ul>Standards <ul><li>Rule Set Templates - organize and group related sets of rules - rules designed to solve specific task </li></ul>Rule Sources Rule Templates
  12. 12. Discovery – Sample Rule Definition Template
  13. 13. Discovery – Sample Rule Set Definition Template
  14. 14. Analysis <ul><li>Top-Down Rule Discovery </li></ul><ul><ul><li>Begin with business context </li></ul></ul><ul><ul><li>Drive toward policies and to rules </li></ul></ul><ul><li>Organization </li></ul><ul><ul><li>Group rules into rule sets and rule phases </li></ul></ul><ul><ul><li>Organize rule sets and rule phases into knowledge bases </li></ul></ul><ul><ul><li>Visual representation with Venn Diagram </li></ul></ul><ul><li>Bottom-Up Rule Discovery </li></ul><ul><ul><li>Begin with system interactions or use cases </li></ul></ul><ul><ul><li>Search for decisions and rules </li></ul></ul><ul><li>Modularization </li></ul><ul><ul><li>Functional Decomposition </li></ul></ul><ul><ul><li>Goal: atomic rules and rule sets </li></ul></ul><ul><ul><li>Information hiding </li></ul></ul><ul><ul><li>Clearly defined inputs & outputs and pre-conditions & post-conditions </li></ul></ul>Organization Modularization Rule Discovery
  15. 15. Analysis - Rule Discovery Step 1 – Top-Down Rule Discovery <ul><li>Break down high level business rule statements into business rules - use the content captured during the Discovery Phase - begin with business policies and drill down to details and business rules - some high level business rule statements represent an entire set of rules - eventually all business rule statements will be refined down to atomic rules - atomic rules cannot be broken down into any more detail and are composed of one or more atomic conditions and actions </li></ul>Business Rule Statement BusinessRules BusinessRules BusinessRules Atomic Rules Step 2 – Bottom-Up Rule Discovery <ul><li>Build business rules from use cases - use cases are a sequence of interactions between an actor and a system - an actor is an external entity that interacts with a system to achieve a goal - use case diagrams show relations between actors and use cases and relations among other use cases - scenarios are a sequence of events described using informal or structured text and are usually accompanied by UML Sequence Diagrams </li></ul>
  16. 16. Analysis - Modularization Step 3 – Create Rule Sets (modules) <ul><li>Guidelines for grouping rules into Rule Sets - functional decomposition – group rules together to solve a well-defined task or goal - re-use – rule sets can be used by other parts of the system to solve the same task - information hiding – the implementation of this set of rules is hidden - if the implementation of these rules changes, it will not affect the system - modularity - limit the way a rule set can interact with other rules and rule sets - this limits the probability of having to change these rules when the system changes - atomic rule sets – just as we desire atomic rules, the rule sets should also be atomic - they should be broken down into the smallest task possible - if a rule set solves multiple tasks or goals, then it is not atomic </li></ul><ul><li>Clearly define the inputs & outputs and pre-conditions & post-conditions - well-defined inputs are required for the user to correctly invoke these rule sets - well-defined outputs provide documentation for system implementers and testers - pre-conditions specify the expected system state before the rule sets are executed - post-conditions specify the expected system state after the rule sets are executed </li></ul>Rule Set A Rule Set C Rule Set B
  17. 17. Analysis - Organization Step 4 – Group Rules into Rule Sets and Rule Phases <ul><li>Group rules into Rule Phases - group rules that function as “Flow-Control” rules into Rule Phases - these rules typically address some sort of procedural flow to sets of rules - “Flow-Control” rules are common when rules are used to control work-flow tasks </li></ul>Step 5 – Organize Rule Sets and Rule Phases into Knowledge Bases <ul><li>Group rules into Rule Sets - remaining rules that were not added to Rule Phases or combined to form rule modules - group these rules into rule sets based on subject area or other criteria - all rules belong to a rule set – just as procedural code is contained in a class or function </li></ul>Rule Phase 1 <ul><li>Knowledge Bases are composed of Rule Sets and Rule Phases - a Venn Diagram can be used to visually assist with the organization process (see next slide) </li></ul>Rule Phase 2
  18. 18. Analysis – Organization – Venn Diagram Step 5 – Organize Rule Sets and Rule Phases into Knowledge Bases (cont) <ul><li>Knowledge Base – highest level of organization - can contain any number of rule sets and rule phases </li></ul>Knowledge Base Rule Set B <ul><li>Rule Set – lowest level of organization - can contain a number of rules - can belong to only one Knowledge Base - can be invoked from multiple rules or rule sets </li></ul><ul><li>Rule Phase – used for organizing flow-control rules - can contain a number of rules - can belong to only one Knowledge Base - mutually exclusive from Rule Sets </li></ul><ul><li>Rule – atomic definition of conditions and actions - can only belong to one Rule Set or Rule Phase </li></ul>Rule Set C Rule Phase 1 Rule Set A Rule Phase 2
  19. 19. Modeling Behavior Model Data Model Process Model <ul><li>Process Models </li></ul><ul><ul><li>Flow Charts </li></ul></ul><ul><ul><ul><li>Capture or document program process flow </li></ul></ul></ul><ul><ul><ul><li>Rule Flow modeling of Rule Phases </li></ul></ul></ul><ul><li>Behavior Models </li></ul><ul><ul><li>Decision Tables and Matrices </li></ul></ul><ul><ul><ul><li>Models of contingencies and the actions to be taken for each </li></ul></ul></ul><ul><ul><li>State Transition Diagrams </li></ul></ul><ul><ul><ul><li>Model for system state transitions </li></ul></ul></ul><ul><li>Data Models </li></ul><ul><ul><li>Entity-Relationship Model </li></ul></ul><ul><ul><ul><li>Data model for persistent data </li></ul></ul></ul><ul><ul><li>Class Diagram </li></ul></ul><ul><ul><ul><li>Data model for run-time data and methods </li></ul></ul></ul>
  20. 20. Modeling – Data Models Entity-Relationship Model <ul><li>Data Model for Persistent Data Storage - represents the architecture of a database - documents table and field definitions including primary keys, field types and sizes - documents relationships between tables & fields represented by foreign keys </li></ul>Object Model / Class Diagram <ul><li>Data Model for Persistent Data Storage - o bject-oriented modeling - documents classes, attributes, and methods - documents data encapsulation and inheritance </li></ul>
  21. 21. Modeling – Process Models Flow Chart <ul><li>Process Flow Model for Program Flow - represents the decision making flow - documents program path and decision points </li></ul>Rule Flow Diagram <ul><li>Rule Flow Modeling of Rule Phases - represents flow between Rule Phases - documents rule execution paths </li></ul>Flow Control Rule Rule Phase 2 Rule Phase 1 Rule Phase 3
  22. 22. Modeling – Behavior Models Decision Tables and Decision Matrices <ul><li>Decision Table - represents a decision situation where the combination of conditions determines action(s) </li></ul><ul><li>Decision Matrix - represents a two-dimensional table where the action is determined by the intersection point of two conditions </li></ul>
  23. 23. Modeling – Behavior Models State Transition Diagrams <ul><li>Finite State Machines (FSM) Modeling - represents a set of system states and valid transitions from one state to another - documents state transitions when past system behavior influences future behavior </li></ul>
  24. 24. Design <ul><li>Complete Details on the Rule Templates </li></ul><ul><ul><li>Rule Template - description, name, rule set, rule type, classification, category </li></ul></ul><ul><li>Rule Architecture </li></ul><ul><ul><li>Organization of knowledge bases </li></ul></ul><ul><ul><li>Sample knowledge base architecture </li></ul></ul><ul><ul><ul><li>- Rule Types - core knowledge and flow control rules </li></ul></ul></ul><ul><ul><ul><li>- Rule Phases - flow control between rule sets </li></ul></ul></ul><ul><li>Complete Details on the Rule Set Templates </li></ul><ul><ul><li>Rule Set Template - description, name, knowledgebase, rules in the rule set </li></ul></ul>Rule Architecture Rule Details
  25. 25. Design – Rule Architecture Rule Engine Core Rule Flow Control Rules Read-XML Phase Run-Process Phase Run-Sequence Phase Run-Activity Phase Run BPML Rule Set Sample Knowledge Base Architecture Parse-XML Rule Set
  26. 26. Design – Complete Details on the Rule Templates
  27. 27. Design – Complete Details on the Rule Set Templates
  28. 28. Delivery <ul><li>Rule Management </li></ul><ul><ul><li>Release Management </li></ul></ul><ul><ul><li>Rule Repository </li></ul></ul><ul><li>Verification and Validation </li></ul><ul><ul><li>Verification Criteria </li></ul></ul><ul><ul><li>Validation Criteria </li></ul></ul><ul><li>Rule Implementation </li></ul><ul><ul><li>Rule authoring tools </li></ul></ul><ul><ul><li>Commercial rule engine products </li></ul></ul>Implementation Verification Rule Management
  29. 29. Delivery – Rule Implementation <ul><li>Rule Authoring Tools </li></ul><ul><ul><li>Used for coding business rules in an integrated development environment </li></ul></ul><ul><ul><li>User-friendly graphical user interface </li></ul></ul><ul><ul><li>Present rules in a form readable and maintainable by non-programmers </li></ul></ul><ul><li>Commercial Rule Engine Products – JRules, ART Enterprise , OPS/J, Advisor, Jess </li></ul><ul><ul><li>Required for execution of business rules </li></ul></ul>
  30. 30. Delivery – Verification and Validation <ul><li>Verification – Rules captured and coded correctly </li></ul><ul><ul><li>Verification Criteria - ex. Completeness, Consistency, Clarity, Traceability </li></ul></ul><ul><li>Validation – Rules executed as expected </li></ul><ul><ul><li>Validation Criteria - ex. Accuracy, Acceptance, Integrity </li></ul></ul><ul><ul><li>Boundary Cases </li></ul></ul><ul><ul><li>Test Coverage - Path coverage - Rule and Condition coverage - Looping logic </li></ul></ul>
  31. 31. Delivery – Rule Management <ul><li>Release Management </li></ul><ul><ul><li>Delivery of a completed, verified, and validated software package </li></ul></ul><ul><ul><li>Version control to maintain and track multiple iterations of releases </li></ul></ul><ul><ul><li>Procedures for internal and external software releases </li></ul></ul><ul><li>Rule Repository Database </li></ul><ul><ul><li>Single location for storage of all business rules </li></ul></ul><ul><ul><li>Mechanism for persistent storage of business rules </li></ul></ul><ul><ul><li>Usually implemented using a relational database </li></ul></ul><ul><ul><li>Typically part of a Rule Authoring Tool </li></ul></ul><ul><ul><li>Beneficial for all phases of the Business Rules Framework from early Rule Discovery through Delivery and Maintenance </li></ul></ul>
  32. 32. Conclusion Presented by: Joe DiGiovanni Business Rules Forum November 2004 Questions ??? Scope Project Plan Iterative Development Planning Rule Sources Knowledge Elicitation Discovery Organization Modularization Rule Discovery Analysis Behavior Model Data Model Process Model Modeling Rule Architecture Rule Details Design Implementation Verification Rule Management Delivery Standards

×