The Agile Business Rule Development methodology details all the different activities the project team may need to follow to develop a business rule application. Starting from from rule discovery to rule set deployment and maintenance, this method helps to develop rule set using an agile, iterative approach. We can group the set of activities into five groups. Those groups are used to build an iterative development of each rule set and decision service:

• 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.

In the first loop, between Discovery and Analysis, the team harvests the rules from the business process description, the subject matter expert knowledge or any other source. This loop represents the first phase of the rule set construction.

Cycle 1- Harvesting:

A first phase includes a short time period where 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.

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 Inception Phase (See OpenUP for more information) the project team is doing business modeling activities (not covered here) which aim at describing the business process and decisions applied to the business event 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

Cycle 2- Prototyping:

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 ruleflow, and the first major elements of the Business Object 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 discovery and analysis, to complete the rule harvesting.

Cycle 3- Building

From our experience based on hundreds of successful implementations of decision-support systems, executable rules are more important than the ones defined on paper or in requirement tracking tools in a non-executable form.

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.

Cycle 4- Integrating

The goal of this cycle is to deploy the rule set under construction to the execution server 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.

Cycle 5- Enhancing

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. Those modifications will follow the standard release management process of the core business application.

This phase approach has many advantages in driving the development process of a Rule Set. It involves all the key stakeholders and prepares for the future maintenance. As a business application using a rule engine is, per design, very agile and supportive of changes, the analysts team needs to understand early in the development process how the components exposed to the rule engine work together, how to change, add, remove rules, how to deploy them...

In parallel of these Rule Set development activities the software architect develops the Decision Service integrated into the core business application. This decision service will use the Rule Sets developed.