390 likes | 404 Views
Building the Kuali Student BRMS (Business Rules Management System). Cathy Dew & Leo Fernig Kuali Days :: Chicago May 13-14, 2008. Agenda. Harvesting and Structuring Rules (Cathy) Industry Best Thinking and Practices Kuali Student Analysis Setting Up the Technical BRMS Environment (Leo)
E N D
Building the Kuali Student BRMS(Business Rules Management System) Cathy Dew & Leo Fernig Kuali Days :: Chicago May 13-14, 2008
Agenda • Harvesting and Structuring Rules (Cathy) • Industry Best Thinking and Practices • Kuali Student Analysis • Setting Up the Technical BRMS Environment (Leo) • KS Business Rules Environment • Work to Date • Integrating the BRMS and SOA (Cathy) • The Rule Entity Model • Fitting It All Together
Getting to Functional Business Rules RESEARCH Theory Concepts Best Practices DATA COLLECTION Partner Institutions Focus on Learning Unit Service Modeling Service Definitions Use Case Collection Actors & Scenarios Classification & Categorization Entity Diagrams & Message Structures Data Concepts Terminology & Definitions Strawman BRMS Strategy
Essential Reading • Business Rules and Information Systems: Aligning IT with Business Goal -- Tony Morgan • The Business Rule Book: Classifying, Defining and Modeling Rules -- Ronald G. Ross • Business Rules Management and Service Oriented Architecture: A Pattern Language-- Ian Graham • Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML-- Jim Arlow and Ila Neustadt • Principles of the Business Rules Approach-- Ronald G. Ross • Smart (Enough) Systems-- James Taylor and Neil Raden • What Not How: The Business Rules Approach to Application Development -- C. J. Date • Business Rules Applied: Building Better Systems Using the Business Rules Approach -- Barbara von Halle
Everyone Agrees • A business rule should define whatshould be the case • It should not prescribe :: • Who invokes the rule (use case) • When the rule is executed (business event or process description) • Where the rule executes (design) • How the rule is to be implemented (design) • In fact,Kuali Student has to do all of this as part of the BRMS
Ross “RuleSpeak” Templates • A Sentence Patternis a basic structure (Template) used to express a Rule in a consistent, well-organized manner • Every rule has a functional category :: • Rejector – a constraint, any rule that disallows an event • Producer – neither rejects for projects, simply computes • Projector – stimulus/response rule, causes some new event • Some Rejector Rules • A non-major student must have permission from instructor • A pre-registration slate must not contain more than 20 credit hours • A student may enroll only if the student is in good standing
Rulespeak Terminology • Establish the anchor of the rule • The thing being constrained • Rule must have one and only one anchor • Establish the correspondent(s) of the rule, a.k.a. facts • The thing doing the constraining • Rule must have at least one correspondent With agreed upon terms and definitions, we could start to analyze business logic and discover rules.
Collecting Examples Academic Evaluation Admissions Transfer Articulation Degree Composition Grades, GPA, etc. Enrollment Transfer Credit Articulation
Focus on Enrollment Rules General Eligibility Description Rule Facts
Focus on Enrollment Rules FSU Course Prereq / Coreq Facts Rule
Focus on Enrollment Rules MIT Course Prereq / Coreq Facts Rule
Focus on Enrollment Rules UBC Course Prereq / Coreq Rule Facts
Patterns Start to Emerge • Count (set of courses, criteria) >= numeric value • Credits • Courses • Subjects • Unit Hours • Grade/GPA (criteria) >= numeric value • Course grade • GPA for term, for year, overall, within major • Student is/is not value • Status is eligible, no holds, has permission • Admitted to institution, college, major
Ownership vs. Execution • Ownership of rules is a function of the process (and people) responsible for authoring, maintaining and publishing a set of rules • Execution of rules is the process responsible for executing a rule may be different from the processes responsible for creating/authoring the rule. • Scheduling Rules, e.g., course has 200 seats • Owned by Central Scheduling Office • Created during the process of scheduling • Executed during registration
KS Business Rules Environment • A Business Rules Management Service (BRMS) • A Rules Engine (Drools was selected for KS) • Business Rules User Interfaces (that allow business analysts to create and modify business rules) • Business services that execute rules • Placing the rules execution inside the service that needs it. • The enrolment service would execute pre-requisite rules, degree rules etc • The student financial service would execute fee calculation rules • Business Rules Data Warehouse • Rules are extracted from the BRMS (using the standard BRMS service definitions) and loaded into the data warehouse. Business Intelligence tools (such as Jasper) can be used to write reports against this data warehouse. • Workflow • Business Rules that are managed in the BRMS can be moved through workflow processes for various levels of approval, just like any other object.
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse KS Business Rules Environment Metadata is used to produce the user’s palette to create and edit rules Execute Rules Get Agenda Exported to executable format Rule data extracted to data warehouse Rules are created, saved and updated through the user interface
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse Phase 1 Aug – Dec 2007 Selection of Rules Engine Technology
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse Phase 2 Jan – May 2008 • Creation of BRMS • BRMS_Drools interface
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse Phase 3 May – June 2008 Integration of BRMS and service stack
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse Phase 4 Development of User Interfaces
A Business Rule A rule consists of a condition and action(s)When proposition 1 and proposition 2 Then action 1 Condition Action
A Business Rule Example rule: Total credits > 30 andgrade point average > 3.5 Boolean Operator Right Hand Side Comparison Operator Left Hand Side Proposition
How do we get rules into the system?The Rules User Interface There are 3 stereotypical ways of presenting rules: • A decision table • A flowchart • A procedural rule (if…then…)
Visual Stereotype #1: Decision Table This is not a look-up table. Not only can you change data but you can change the structure of the table without any programming changes. For example, two new columns can be added with no changes to the code:
Visual Stereotype #3: Flowchart Are the grades complete? No Yes Apply Evaluation Rule Is the result a “PASS”? No Yes Create Registration Record
Rules and Business Intelligence • Traditionally Business Intelligence only deals with “facts” in the Enterprise Systems. Now we can apply Business Intelligence to business rules. • For example: • Is there any correlation between student success and pre-requisite rules? • Which courses are referenced most frequently in curriculum rules? • Are there any rules that inhibit student success (in the sense of causing students to take more than 4 years to finish their program)?
Business Service Business Service Business Service Drools BRMS Rules User Interface Executable Rules Rules Rules Metadata Rule Execution Engine Data Warehouse How does a business services “know” which rules to invoke?
Rules Entity Diagram Agenda Determination Structure • Agenda Determination Structure :: information needed to determine the specific Agenda • Agenda :: set of Business Rules that apply to a business process needing a decision • Output :: for each Agenda, the expected output • Business Rule :: individual business rule • Anchor :: for each Rule, the entity type instance to which the rule is attached • Fact :: data (facts) needed to execute the rule Output Agenda Anchor Business Rule Fact
Example Business Rule Validate Relationship Enroll in Course • Agenda Determination :: Validate relationship of type Enroll for Course • Agenda :: Student Enrolls in MATH 301 • Output :: OK / Not OK • Business Rule :: Student has met pre-reqs of • 2 of (static list) • 6 credits of (dynamic list) • overall GPA >= 3.0 • Anchor :: MATH 301 • Facts :: course sets (static and dynamic), student’s academic record OK / Not OK Student Enrolls in MATH 301 MATH 301 Met MATH 301 Prerequisites MATH 101, MATH 102, MATH 103 200-level MATH courses Academic Record
Fitting It Together KS BRMS • Harvested a bunch of rules • Developed a strategy for collecting and classifying rules • Agreed on terminology and a business rule entity model • Completed a Proof of Concept for a representative pre-requisite rule • Built the Core BRMS • Defined and stored a business rule • Translated it to a Drools • Executed the rule from our Enrollment business service
Fitting It Together KS BRMS • We are in the process of modeling :: • How a business process determines which rules to execute • What is the link to the Agenda • Smallest footprint possible • Who is responsible for getting the facts needed to execute the rule • Without violating SOA (who knows what) • Without requiring BRMS to know about domains
Thank You Coming Soon, to a university near you...