Building the Kuali Student BRMS (Business Rules Management System)

1. Building the Kuali Student BRMS(Business Rules Management System) Cathy Dew & Leo Fernig Kuali Days :: Chicago May 13-14, 2008

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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.

8. Discovering Rules

9. Collecting Examples Academic Evaluation Admissions Transfer Articulation Degree Composition Grades, GPA, etc. Enrollment Transfer Credit Articulation

10. Focus on Enrollment Rules General Eligibility Description Rule Facts

11. Focus on Enrollment Rules FSU Course Prereq / Coreq Facts Rule

12. Focus on Enrollment Rules MIT Course Prereq / Coreq Facts Rule

13. Focus on Enrollment Rules UBC Course Prereq / Coreq Rule Facts

14. 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

15. 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

16. The Technical BRMS Environment

17. 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.

18. 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

19. 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

20. 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

21. 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

22. 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

23. A Business Rule A rule consists of a condition and action(s)When proposition 1 and proposition 2 Then action 1 Condition Action

24. A Business Rule Example rule: Total credits > 30 andgrade point average > 3.5 Boolean Operator Right Hand Side Comparison Operator Left Hand Side Proposition

25. UML for a Business Rule

26. 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…)

27. 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:

28. Visual Stereotype #3: Flowchart Are the grades complete? No Yes Apply Evaluation Rule Is the result a “PASS”? No Yes Create Registration Record

29. Visual Stereotype #3: Procedural Rule

30. Example of a User Interface

31. 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)?

32. 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?

33. Integrating the BRMS and SOA

34. 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

35. Agenda Determination Decision Table

36. 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

37. 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

38. 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

39. Thank You Coming Soon, to a university near you...