1. Building the Kuali Student BRMS (Business Rules Management System)
Cathy Dew & Leo Fernig
Kuali Days :: Chicago May 13-14, 2008
Good morning – Welcome to “Building the Kuali Student BRMS ( Business Rules Management System)”
I’m Cathy Dew and this is Leo Fernig – we are the representatives of the Kuali Student BRMS (Business Rules management System) team
I say representatives because this is and will continue to be a very collaborative effort. As you know, Kuali Student is a consortium of universities building the next generation of student systems, using SOA – Service Oriented Architecture.
For the Rules Team, the process and our resulting product to date – yep we have a working prototype – has been a collective intellectual effort. From our resident concept and theory guru to the insights and shepherding from the service architects to the roll-up-your-sleeves and dig-into-the-code modelers and developers – it has truly been a team effort. And, I think they are all here today!
The Objectives for this Session -- we’ve only got an hour – so figuring out what not to talk about was a challenge…
Our focus will be ::
Walking your through what we’ve done and why
Results of our efforts to date

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
Today we have three topics surrounding the Kuali Student Business Rules management System ::
Harvesting and Structuring Rules
Industry Best Thinking and Practices
Kuali Student Analysis
Leveraging Ross & Graham
Setting up the Technical Implementation of the system
KS Business Rules Environment
Component Systems
The BRMS, Drools, and the UI
Work to Date
Integrating BRMS and SOA
The Rule Entity Model
Putting It All Together
This should leave some time for Q&A at the end

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
The BRMS is a critical aspect of configuration in KS
And one of the results of Phase 1 was the rampant reference to rules – if it involved logic, it was a rule…
The strategy to separate business logic from application code has long been recognized as the way to go
But how to get started on this huge task
Our Methodology started with two concurrent efforts ::
Research – digging into what the experts in the field are saying, we’ve got a great reading list for you on the next slide
Data Collection – partners represent a diverse and rich collection of higher ed institutions
Meanwhile the other KS teams were busy modeling services, collecting use cases, and compiling data concepts
This resulted in service definitions, actors & scenarios, and entity diagrams and message structures
As the rules team was getting a handle on Classification & Categorization and refining our Terminology & Definitions
We were able to bring all of this thinking and design work together into our “straw man” BRMS strategy
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
Admittedly this is quite a list and many of us read a little to a lot of some or all of these references – some more, some less
We ended up relying heavily on Ross, in particular his Rulespeak for terminology and templates
We also found Graham’s synthesis and summary, and most important the notion of Pattern Language, very helpful

5. In fact, Kuali Student has to do all of this as part of the BRMS
Everyone Agrees
A business rule should define what should 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
In a traditional project where you are adding a BRMS to the mix, it’s really important to understand that the point of the business rule is to express the “WHAT” – not the who, when, where, or how.
In fact with Kuali Student we have to do all of this – our problem space is really the entire mix…

6. Ross “RuleSpeak” Templates
A Sentence Pattern is 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
Start with the WHAT -- as I mentioned, Ross does a great job of outlining a way to get started structuring rules with RuleSpeak.
The first concept is a Sentence Pattern ::
A Sentence Pattern IS NOT technical in nature – it is designed to improve communication at the business level
It ensure that written rules are more easily understood
And it helps make sure that different practitioners express their ideas in the same way
Functional Categories of rules help to frame and refine the rule by thinking about its main purpose ::
Rejector e.g., prevent a student from enrolling if the student has not paid their fees or met certain pre-reqs
In terms of our initial focus, on the Learning Unit and in particular pre-requisite rules – these are pretty much all in the category or Rejector Rules
Producer can be Computation (standard arithmetic operation) or Derivation (true or false based on logical operations),
e.g., student’s overall GPA = course credits times grade for course divided by total credits
Projector rules cause a new event
e.g., exception types, if student has instructor’s permission, ignore pre-req rules
Ross goes on to provide specific templates for each type – here are a few for Rejector rules
Before going broad, we decided to go deep and ensure that the templates translate into tangible executable code

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
More Rulespeak that ended up Establish the anchor of the rule (in other words, finding a type in the data model to which the rule “belongs”).
What the rule is attached to, e.g., course for pre-requisites
Establish the correspondent(-s) of the rule (in other words, finding the data type(-s) in data model that is/are necessary in order to evaluate the rule).
For example, the set of pre-req courses and the student’s academic record of courses taken are compared in the condition portion of the rule
We had mixed feelings about the term correspondent – as you will see later in our KS BRMS model – we ended up using Fact and Fact Structure rather than correspondent
It was important to have terminology that we could all buy into and that would be embraced by SME’s as we get a larger group working on rule collection
With agreed upon terms and definitions, we could start to analyze business logic and discover rules.

8. Discovering Rules
Delta – community college in northern central California
Florida State University
MIT
University of California, Berkeley
University of British Columbia in Vancouver
University of Maryland, College Park
We had an amazing pool of material to start delving into rules surrounding the KS concept of Curriculum Development (Learning Unit)

9. Collecting Examples Academic Evaluation Admissions
Transfer Articulation
Degree Composition
Grades, GPA, etc.
Enrollment
Transfer Credit Articulation
This is one of our many, many WIKI pages.
It is an index to some of the raw data that we collected as part of looking at the rules across our various partner institutions.
As you can see we looked at ::
Admissions rules
Degree Rules
Course Rules
Enrollment Rules
Rules surrounding grades and GPA

10. Focus on Enrollment Rules
General Eligibility
Description
Rule
Facts
The next step was to narrow in on something – we chose enrollment rules
As we started looking at those, we quickly identified a set of basic rules that aren’t necessarily specific to the particular course or program
But are general eligibility requirements
We started by extracting the specific logic that represented a rule
And then identified the associated facts needed to evaluate the rule

11. Focus on Enrollment Rules
FSU
Course
Prereq / Coreq
Rule
Facts
Next we started getting into specific academic requirements at the course level – re-requisites, co-requisites
We discovered the need to also track anti-requisites, who knew?
FSU
Successfully completed a course or in this case a set of courses – most basic pre-requsite
Admitted to Business School

12. Focus on Enrollment Rules
MIT
Course
Prereq / Coreq
Rule
Facts
MIT
Added the fact about instructor permission

13. Focus on Enrollment Rules
UBC
Course
Prereq / Coreq
Rule
Facts
UBC
UBC’s rule were complicated in terms of subsets along with AND/OR logic, but we didn’t find any new 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
After doing this across lots of rules, we found a huge diversity in the rule specifics, but also many similarities in the arguments
General patterns started to emerge, for example ::
Lots of pre-req rules include counting courses within a specific list
A slight variation was instead of counting courses, it would be credits or unit hours (MIT credit x meetings/week)
Another variation was the course plus a minimum grade
Overall GPA or in some cases a GPA for a particular time period (2nd year) or within your major
We started to get comfortable that we had started to surround the logic and the data needed to support pre-requisite rules

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
The next “AHA” moment came when we heeded/remembered Graham and his point about separating business rules authoring from rules execution
The ownership and authoring might be one domain and the execution point might be a different domain
Associated with the offered course in Spring 08, e.g., there are 200 seats in this course section
Executed during registration
This led to a better understanding of things like anchors (where the rule is attached) and facts ( data needed to execute the rule) and which business domain would actually trigger the rule
For example, Scheduling
Owned by Central Scheduling Office
Created during the process of scheduling
Associated with the offered course in Spring 08
E.g., there are 200 seats in this course section
Could also be executed during a timetabling/planning exercise

16. The Technical BRMS Environment
I’d like to hand the discussion over to Leo now who will talk about the technical environment that was being designed in parallel with the functional analysis work

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. KS Business Rules Environment
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
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. Aug – Dec 2007 Selection of Rules Engine Technology
Phase 1
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
Aug – Dec 2007 Selection of Rules Engine Technology

20. Phase 2 Jan – May 2008 Creation of BRMS BRMS_Drools interface Drools
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
Jan – May 2008
Creation of BRMS
BRMS_Drools interface

21. Phase 3 May – June 2008 Integration of BRMS and service stack Drools
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
May – June 2008
Integration of BRMS
and service stack

22. Development of User Interfaces
Phase 4
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
Development of User Interfaces

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

24. A Business Rule
Example rule: Total credits > and grade point average >
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
Program
Visa status
Cost per credit
Arts
Canadian
200
Student visa, Visitor
400
Science, Applied Science
300
600
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:
Program
Min credits
Max credits
Visa status
Cost per credit
Arts 15
Canadian 50
Student visa, Visitor
100 30 75
200
Science, Applied Science
300
400

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
Pre-requisites for CHEM 415
Both courses
CHEM120, CHEM130
AND OR
Total credits
>12
1 course
CHEM 230
Average
>80%

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. How does a business services “know” which rules to invoke?
Data Warehouse
Business Service
Rules User Interface
Drools
Executable Rules
Rule Execution Engine
BRMS
Rules Metadata
Rules
We have already gained an enormous amount of flexibility by being able to define our business rules dynamically to the system (rather than having them hard coded in our Java code base).
But there is still a point of inflexibility in this scheme. If references to rules are hard coded in the business services that consume them, then if we need to change which rules are called, we need to change code.
So, we need a dynamic way of specifying which rules need to be executed in a given business context.

33. Integrating the BRMS and SOA
We really solidified the structure of the meta data about the business rule, leveraging Ross and Graham

34. Agenda Determination Structure
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
This is a simplified version of the rules entity diagram, but focuses on the key concepts
Agenda Determination Structure :: information needed to determine the specific Agenda
Rule, probably a decision table, that is used to determine what rules apply
Link to the implementation
Agenda :: set of Business Rule that apply to a business process needing a decision
Output :: for each Agenda, the expected output
Result that the caller, e.g., application uses to decide what to do next
Business Rule :: individual business rule
May be multi-part/composed with and/or logic connectors with parentheses
Tie to a Drools rule set, executable rule in the Rules engine
Fact :: structure of data (facts) needed to execute a rule
Arguments of the Rule AND Facts that are evaluated by the Rule
The BRMS isn’t responsible for gathering the facts, but knowing what structures are needed in order to get the facts
Actual facts may be gathered by service calls invoked by the caller
Anchor :: for each Rule, the entity type instance to which the rule is attached
Implicates the business domain that owns and maintains the rule
Fact

35. Agenda Determination Decision Table
Type
Relation State
Agenda Name
Agenda Description >> Rules
Output
course
enrolled/ registered
Student Enrolls in Course
enrollment reqs (student, admitted, no holds)
academic reqts (min GPA, good standing)
course reqts (pre/co/anti-reqs, w/grade)
program reqts (GPA, major match)
financial reqts (enr fees paid, lui fees paid)
OK / Not OK with Explanation
planned
Student Plans Course
Status and Recommendations
This tells us which rules get executed in which business context
A different business process has a different agenda that has a different set of rules, some individual rules may be the same bu others are omitted

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
In terms of completing the design, there are still some hard problems left to solve
Linking business process to an agenda
Smallest foot print possible
Agenda Determination Decision table is promising
Completing the fact structures
Without violating service model (and who knows what)
Without requiring BRMS to “know” about domains
Service layering

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