This post is part of a series on Business Rules Governance and Management for which the main article can be found here.
In previous posts, we have focused mainly on the topic of Governance. It is now time to start looking at the Business Rules Management aspect of things.
The Life Cycle of a Rule
Rules have a life of their own. From Birth to Death we need to have an idea of how the rule will live its life. Similarly to a person, a rule will go through many phases in its life.
Birth and Development: A human is born and from that moment on and for the years that will follow will develop in the person he will become. A rule gets created and defined.
Validation: A person will eventually go through some type of testing (either through education or simply through life) that will confirm the knowledge and skills and Make them ready for a productive working life. A rule needs to be tested and validated to confirm that it does what it is meant to do.
Working Life: A Person will usually spend a large portion of their life working doing the exact same job, at the same company (Note from the author: “Humour me!”). A rule will execute it’s work for as long as it makes sense, working night and day, relentlessly… 🙂
Retirement: At some point after a long and productive working life, a person will [choose one: be entitled, be forced] to retire from active working life and enjoy retirement. When a rule does not make sense anymore, it needs to be retired from execution.
Ok, so we now have some of the basic building blocks for our Rule Life Cycle.
As a more serious inspiration for a rule life cycle, we can look at an example Rule life cycle which is composed of the following states:
- New: the rule is created, and can be modified by the writer
- Ready for review: the rule writer has completed the initial work and a reviewer can now make sure that the rule is written correctly and represents the intent of the business (note: it is assumed that until the reviewer has reviewed the rule, he will work with the writer to bring the rule to the next state).
- Reviewed: the rule has been reviewed by the reviewer is ready for the next steps
- Ready to test: the rule is ready to test and will remain in this state during testing and until the tester either accepts or rejects the rule
- Rejected: the rule has been tested un-successfully
- Tested: the rule has been tested successfully
- Ready to deploy: One last state before the rule goes into production
- Deployed: the rule is part of a rule set deployed on production platform
- Retired: the rule was deployed on a production platform but is no more active because it is out of date
The following diagram shows these states, the accepted transitions between states as well as which role is responsible for each transition.
This Rule Life Cycle may or may not actually be relevant to your specific situation, but the point remains that the management team needs to think about what makes sense to your situation. Create you own life cycle, and with the help of the management processes (see next post), set things up so that it works in your environment.
When creating your own life cycle, you may also want to consider the environment in which you are developing, testing and deploying these rules for execution. For example, if you have 3 environments (development, UAT, Production) versus 4 (development, QA, UAT, Production), the life cycle may be significantly different. You may also need to consider the types of rules that you have and might have slightly different life cycles based on the types of rules.
Note that the life cycle indicated above was mentioned for a rule, but it may very well be that this applies to a set of rules (ruleset).
The reason why we want to start discussing the rule life cycle is that at the same time it will force some preliminary discussions on the management processes which is the topic of the next post.
Agile Business Rules Development, ABRD v1.2, available at http://www.eclipse.org/epf/downloads/praclib/praclib_downloads.php