Business Rule Templates

Templates are included as comments to this entry. You may suggest either a template or critique templates in your comments.

Staffing the Business Rules Management Office

Business Managers want to know about the organization and staffing of the responsibility to manage business rules. This gets to the practical issues of who is in control, where do the people come from, how do they get trained, what are roles and responsibilities, what are reporting relationships, and who owns the PY's?

Please share your experience and recommendations.

One suggestion is to model the Business Rules Management Office after the Project Management Office. Another model calls for each business organization to have its own set of rule specialists. Representatives of each organization can meet periodically or establish other means to share rules with one another to avoid inappropriate duplication and to promote standards for documentation and vetting rules. A third model calls for an analogy to the database administration office. The DBA takes business rules after full articulation and processes the rules through to implementation. The Rules Unit then works with projects to form individual rules into policies to be orchestrated as automation decision making processes.

Amazon Listmania on Business Rules

Here are links to Amazon Listmanias on Business Rules (no warranty expressed or implied)

By Jorge Cordeiro Duarte
http://www.amazon.com/Business-Requirements-Rules/lm/R1HV7VKF7DZK70/ref=cm_lmt_dtpa_f_1_rdssss1/104-5753007-5346319?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=listmania-center&pf_rd_r=06CYJKVTR6VRW5QD24VH&pf_rd_t=201&pf_rd_p=253462201&pf_rd_i=1600050131

By Alain Jean Marie Gougeon
http://www.amazon.com/Business-Rules-Complete-List/lm/28DF3O4RC9962/ref=cm_lmt_dtpa_f_3_rdssss0/104-5753007-5346319?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=listmania-center&pf_rd_r=06CYJKVTR6VRW5QD24VH&pf_rd_t=201&pf_rd_p=253462201&pf_rd_i=1600050131

Generally, do your own research on these books; Listmanias are not reviews but bibliographies.

Business Rules Manifesto (Business Rules Group)

The Business Rules Group has published a Manifesto worth using in efforts to get a sponsor for a business rules initiative। Here is the link to the Manifesto.

http://businessrulesgroup.org/brmanifesto.htm

Use Cases for Business Rules Management

Placeholder for a diagram to reflect the Business Rule Life Cycle. Please critique the Life Cycle entry so that the State Transition diagram can be updated.
Here are a set of Use Cases to represent the States of a Business Rule. It will be refactored along with the earlier post on the life cycle of a Business Rule so that the two are in synch.

Business Rule Life Cycle

What are the States for a Business Rule? Business Rules are more "real" than requirements in that decisions get made in the production environment based on a Rule. Sarbannes-Oxley type of seriously is applicable, whereas requirements are subject to a lot of manipulation and interpretation. Here are States we propose for an upcoming project. We encourage your reactions:
Candidate - these are nominations. They may come from new legislation or harvested from a legacy application. Rules discovered from Legacy applications are a different type of Candidate than a Rule proposed as a result of newly enacted legislation (or Board action or Audit Exception finding). Harvested rules are already in Production. But we don't really know if the Rule is correctly implemented or even widely understood. Therefore, harvested Rules require as much scrutiny as newly proposed Rules. Comments encouraged on this premise.

Clarified - The initial wording from the Candidate is re-stated based on templates or peer review.

Articulated - The Rule has gone through a Business rule authoring tool -- preferably.

Verify - This is a combination of authenticating the source of the rule (legislation, board action) AND testing of the Rule -- preferably by the Articulation production.

Approved - This might be an overly bureaucratic step that implies that after documenting the Verification that someone must Approve the Rule.

Versioned - The Rule goes into configuration management.

Build - The Rule is translated into a programming language either through a Tool or through the work of the Developer.

Tested - The Developer has conducted Unit and String Testing. String Testing includes combining the Rule with Rules executed in conjunction with the Rule.

Orchestrated - The Rule is part of an Orchestration intended for Deployment for Production. It is ready for System Testing and Unit Testing. It is not necessary to log the success of the Rule in these types of testing. If a defect is found, the orchestration goes through modifications to determine if it is the rule or the orchestration that is at fault. If the defect is in the Rule, then the developer must return the Rule to Verification. There may be a disagreement between the Unit Acceptance Testing participants as to what the Rule is and what the Verification authority determines the Rule to be. This poses an interesting set of problems to track resolution to make certain the User Acceptance folks accept the final decision. But this may mean the Verification authority will have to dissect whether the problem is with the Rule or with the Orchestration.

Deployed - The Rule is in production. Ideally, the Rule management system can track which Orchestrations use the Rule.

If the Rule is deployed in automations other than a Business Rules Engine--in hand coded implementations, then it becomes more important to know where the Rule is utilized. Because if the Rule is modified where accessed by the Business Rules Engine, then there has to be a way of detecting the Rule needs modification in the hand-coded solution(s) as well.

When a hand coded change is made, there has to be a governance process than ensures the Rules Management Repository reflects the change as well. Otherwise, we will have stove piped applications changing Rules that go unnoticed by the governance process and the Rules Repository and the other implementations throughout the Enterprise.

Introduction to Contributors and the Curious

Explore Business Rules Management:
Shift Business Rules identification to the very beginning of the project, no longer delayed until the Analysis workflow (UP's Specification Phase)
What are best of breed tools for rules harvesting, rules articulation, rules repository, rule testing, generating code from rules, business rules engines
Impact of rules management on application architecture: separation of rules from orchestration;
How Rules Management motivates and enables the line of business management to take a more influential role in the design, development, and maintenance of automated systems
Relationship of and mapping of business rules to process models
Importance of business process analysis and models to the management of business rules.