Wikipedia defines a business rule management system, in general, as follows: "a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems."

A key aspect of a rules management system is that it enables rules to be defined and maintained separately from application code. This modularity has the potential to reduce application maintenance costs, enable increased automation and application flexibility, and to enable business analysts and business process experts who are not developers and who reside outside of the IT organizations in the business departments themselves, to be more directly involved in creating and managing their rules.

A rules management system in general includes a repository of decision logic and a rules engine that can be executed by applications in a run-time environment. Again from wikipedia: "... provides the ability to: register, define, classify, and manage all the rules, verify consistency of rules definitions (”Gold-level customers are eligible for free shipping when order quantity > 10” and “maximum order quantity for Silver-level customers = 15” ), define the relationships between different rules, and relate some of these rules to IT applications that are affected or need to enforce one or more of the rules."

(Work in progress - Start with definition of how KRMS adds to Rice in the area of business rules.)

Kuali's Rule Management System (KRMS) supports the creation, maintenance, storage and retrieval of business rules and agendas (ordered sets of business rules) within business contexts (e.g., for a particular department or for a particular university-wide process).

KRMS enables you to define a set of rules within a particular business unit or for a particular set of applications. These business rules test for certain conditions and define the set of actions that result when conditions are met. KRMS enables you to call and use this logic from any application, without having to re-write and manage all the rules' logic within the application.

Integration with organizational hierarchies and structures can be accomplished today using KEW for routing and approval. But before KRMS, other business logic such as "route to this set of people if the dollar amount is less than x, or to this other set if the dollar amount is over that" was the responsibility of the applications themselves. KRMS now offers a way to manage this type of business logic independently and once, using the logic across applications.

Because KRMS is a general-purpose business rules engine, you can use it for many things, for example, you can define a rule to specify that when an account is closed, a continuation account must be specified. You can also define rules to manage your organizational hierarchies and internal structures. You can define compound rule logic, for example, "Must meet":

Before KRMS, and using only KEW, these types of business rules were the responsibility of each application to manage.

(Maybe move the paragraphs below into an new section of the KEW document for PeopleFlow)

Calling a KRMS set of rules (an agenda) from your application can result in a call to a full-blown KEW workflow or to a lighter-weight PeopleFlow, which is a new feature in KEW in Rice 2.0, or to any other action you define in KRMS. PeopleFlow gives you a new type of request activation strategy called "priority-parallel" to activate requests generated from a PeopleFlow in the appropriate order. Essentially, it's like a mini people-based workflow that doesn't require you to specify a KEW node in the document type for each individual who might need to approve or be notified. You can define "Stops" in a PeopleFlow, where everything in the same stop proceeds in parallel, but all must be done within the stop before proceeding to the next stop.

The same PeopleFlow that defines a routing order among a set of persons, groups or roles can be called by KRMS rules, with the KRMS rules defining which type of action request to pass to the PeopleFlow (for example, an "approval" or a "notification" action).

You can define a PeopleFlow (simple workflow) via a simple maintenance document. You can call/execute a PeopleFlow from a KEW workflow node directly, or you can invoke the KRMS rule engine from an application and any PeopleFlows that get selected during rule execution will be called. In this way, you can integrate business rules across your applications and workflows.

PeopleFlow is our Kuali Rice instantiation of the "maps" concept in Coeus. For all intents and purposes it's a prioritized list of people to send action requests to. You can use a new type of request activitation strategy called "priority-parallel" to activate requests generated from a PeopleFlow in the appropriate order, so essentially it's like a mini people-based workflow that doesn't require you to specify a KEW node in the document type for each individual who might need to approve.

(Work in progress - Scenario for using KRMS in addition to KEW, scenario for using KRMS without KEW. When to use KEW without KRMS, when to embed logic in your applications instead of using a rules engine) )

(Work in progress)

(Work in progress) Include integration with KEW and KIM at a high level (& with KEN & KOM?) And clarify how any application can include KRMS.

Work in progress)

KRMS Overview