- Rule Discovery
- Rule Analysis
- Rule Authoring
- Rule Validation
- Rule Deployment
The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business.
Figure 1 Rule Set Development Life Cycle
In the first loop, between Discovery and Analysis, the team harvests the rules from the business process description, the subject matter expert knowledge, legal documentation, use cases or any other source. This loop represents the first phase of the rule set construction.
This phase is limited in time. The development team splits the day into two parts, executing discovery workshop in the morning (2 or 3-hour sessions), then performing some analysis and documentation for the remaining of the day. The team iterates on these two steps during 2 to 5 days maximum, depending on the number of rules and their complexity. Meeting execution is based on standard requirement elicitation techniques. To make the better use of the development and business team's time it is important to plan in advance the workshop sessions and to clearly state what is in the agenda.
To organize the session the project team may need to name a moderator responsible of managing the meeting and keeping the team on track. His other roles are:
- Establish professional and objective tone to the meeting.
- Start and stop the meeting on time.
- Establish and enforce the “rules” for the meeting.
- Introduce the goals and agenda for the meeting.
- Facilitate a process of decision and consensus making, but avoid participating in the content.
- Make certain that all stakeholders participate and have their input prepared.
- Control disruptive or unproductive behavior.
The goal is to document just enough rules to be able to start the implementation. In addition, this phase aims at understanding the object model within the scope of the application and to identify and extract some rule patterns.
The starting point of the Rule Discovery is the Decision Point Table: During the Project Inception, the project team is doing business modeling activities (not covered here) which aim at describing the business process and decisions applied to the Business Events corresponding to the scope of the business application. One important work product built during this modeling phase is the Decision Point Table which describes the point in the process (task, activities, transition) where there is a lot of decision points involved (test conditions and actions). These decision points represent potential candidate for rule sets.
Once a certain level of discovery progress is done, the development team should be able to define the structure of the rule project: the rule set parameters (input-output business objects), the basic sequencing of the rules, also called Rule Flow, and the first major elements of the Domain Logical Model. The team then should be able to already implement some rules.
The idea is to execute the step “Rule Authoring” as soon as possible to uncover possible analysis and design issues. Indeed, most of the rules look good on paper but real issues arise most of the time during implementation and test. The next morning workshop session communicates the issues back to the business team. This leverages the feedback loop approach and provides an efficient mechanism to build a pragmatic, adequate and business-relevant executable rule set.
The second phase still does some discovery and analysis, to complete the rule harvesting.
Executable rules are more important than the ones defined on paper or in requirement tracking tools in a non-executable form. This is part of the agile-manifesto.
This agile statement is at the core of this cycle. Based on a Test-Driven Development (TDD) approach the goal of this phase is to implement a set of test scenarios with real or close to real data, to test the rules within their corresponding rule sets and their targeted execution context.
The day-to-day authoring activities can be seen as a set of little steps including test case implementation, writing rules, executing them, and doing some validation with the team members.
This cycle is still using short daily loops:
- Loop on Authoring and Validation to develop test cases and rules
- Loop on Analysis, Authoring and Validation to author executable rules, complete the analysis, do some unit testing and address/resolve issues.
- Loop on a bi-daily basis on Discovery, Analysis, Authoring and Validation. The discovery will be used to complete the scope of the rule set and address the issues identified during implementation.
The cycle 3 should finish after 2 to 3 weeks. The goal is to release the rule set within an integrated development build in order to start testing the business application with the decision service. The rule set should only be 40 to 60% complete. Business users or rule writers will then elaborate and complete it in cycle 5 (Enhancement). But at the end of cycle 3, the Object Model used with the rule should be at least 90% complete, and the project structure should be finalized.
It is still possible to execute this cycle multiple times, if the size of the rule set is bigger than what can be done in three weeks (exactly 40% of the size of the rule set cannot be done in three weeks). In this case, it is recommended to still time-box this cycle to three weeks and deliver a concrete build to the QA or validation team for review and execution. Then embark on another build for the next 3 weeks.
The goal of this cycle is to deploy the rule set under construction to the execution server and business application to test it with an end-to-end testing scenario. The integration of the decision service and the domain object model is an important task. Data is sent to the rule engine to fire rules and infer decisions. During the previous phases the development team develops a set of test scenarios with realistic or real data which will trigger rule execution. Those test scenarios will be executed during the integration phase to support end to end testing. In the future they will serve as non-regression test suite.
It can be seen as a more mature phase where the goal is to complete the rule set, and to maintain it.
It includes authoring, validation and deployment. It is still possible to do some short face-to-face discovery activities with the Subject Matter Expert to address and wrap-up some issues and questions. But with this approach, the team responsible for maturing the rule set to close to 100% coverage can be another team than the initial development one. This team is more business-oriented. As owners of the rule set and the business policies, they can develop at their own pace as they have all of the core infrastructure implemented by the development team.It is important to note that there will be some needs to enhance the object model or physical data model to add some new facts, attributes, or entities. This can be started in the Rule Business Object Model view by an analyst or can be done in the executable object model by a developer. Those modifications will follow the standard release management process of the core business application.
We will details some of those activities in details later.