The Agile Business Rule Development (ABRD) Methodology provides a framework that project teams may adapt to meet the needs of their specific business rules application project. The methodology supports the full rule lifecycle, from discovery to governance by using an 'agile', iterative approach. ABRD activities fall into five categories described below. Each of these activities is executed multiple times as the process is followed.

• Rule Discovery

• Rule Analysis

• Rule Design

• Rule Authoring

• Rule Validation

• Rule Deployment 

Like all agile methodologies, in ABRD rules as other software element are developed incrementally, in multiple iterations of short time frames. However, in ABRD, the entire process lifecycle may not be followed for each iteration. Instead, a number of very short cycles between phases may occur, with the entire rule set gradually evolving. The entire process may be represented by the process flow diagram below:

In the process flow diagram above, each of the tasks loops back to previous tasks in the flow. These 'loops', or cycles, are repeated as required, with the loops gradually moving from left to right through the process until the rule sets are deployed. This method of rule development reflects the nature of BRMS: a mature and stable domain object model is a prerequisite for rule development, therefore we may multiply cycles through the early part of the process flow in order to develop such models early in the process. As each of these cycles is completed, the ruleset will gradually grow until it reaches a state where it reflects the requirements set forth by the business.

A typical ABRD Project

From a project management perspective, there are five phases, or activities of project, each of which maps onto parts of the technical process flow described above. The project phases are:

1. Harvesting, the activity of gathering business rules
2. Prototyping, the activity of  entering business rules into the BRMS
3. Building, the activity of building a working system representing the organizations business rules
4. Integrating, the activity of deploying the rules to an execution environment suitable for end to end testing
5. Governance, the activity of monitoring, maintaining and enhancing business rules 
    

Cycle 1- Harvesting

Rule harvesting, consisting of the Discovery & Analysis tasks, involves gathering together all the sources of knowledge available to the team. These sources may include a business process description, subject matter experts, policy manuals or other sources of rules. The goal of this activity is to understand the Domain Object Model within the scope of the application and to identify enough rule patterns to begin implementation of rules in the next phase.

During this activity, the development teams divide the day into two parts, executing discovery workshops in the morning (in 2 or 3-hour sessions), then performing analysis and documentation for the remainder 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 starting point of the Rule Discovery is a Decision Point Table artifact:  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 any business events supported by the 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 decisions are made. Decision point represents potential candidate for rule sets.

Cycle 2- Prototyping

The prototyping activity extends the tasks performed to include rule authoring. When a workable number of rules (this number will vary by project) have been harvested the development team should start to define the structure of the rule project: the rule set parameters (input-output business objects), and the basic sequencing of the rules (the ruleflow), and the major elements of the Business Object Model. The team should then be able to already implement some rules.

Tip: During the first pass through the prototyping activity, it is better to err on the side of too few rules

A best practice 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.

Cycle 3- Building

The goal of the build activity is to create rules that can be 'seen', 'used' and, most importantly, tested, by business users. Rules that can be executed by the rule engine are more valuable than ones defined on paper or in abstract forms. This fully endorses the agile statement: "Working software over comprehensive documentation."

The second goal of this phase is to create a set of realistic test scenarios, using real data if possible, to test the rules created during the Authoring activity. This is a form of Test Driven Development (TDD). This activity extends the Build activity by adding a Rule Validation task.

The day-to-day authoring activities consist of a series of small steps that include:

• Test case implementation
• Writing rules and executing rules
• Validating rules with the business team members.

The build activity consists of all the previous tasks, with short iterations:

• Enhance rules (Authoring & Validation tasks)
• Improve rules (Analysis, Authoring & Validation) as needs are identified
• Complement rules (Discovery, Analysis, Authoring & Validation) with additional rules to provide complete coverage of the business domain (once every two days).

The Building activity should take between two and three weeks, and the output artifacts should be a ruleset that can be loaded into the rule engine and executed.

Checkpoint:
During the first iteration of this activity, the total number of rules will be only around 40% to 60% completed. The idea is to get something to business users that is sufficient to get comment and feedback on, and that will form the basis of the next phase. By this point, the Business Object Model (BOM) should be at least 90% complete.

Depending on the size of the ruleset, this activity may deliver less than 40% of the rules. In that case, this activity may have to be repeated. In this situation, it is recommended that the activity be time-boxed to three weeks so that a concrete build may be delivered to the QA or validation team for review. Once a build is delivered, another iteration of this cycle may be started.

At the end of this cycle it is possible to release the rule set integrated as a decision service into the core business application. The development team can then execute functional test on it.

Cycle 4- Integrating

The goal of this cycle is to deploy the rule set under construction to the execution server in order to test it with an end-to-end scenario. The integration of the decision service and the domain object model is an important task. Integration involves the marshaling of data to/from external data sources, such as Database, MOM, files or sockets into a form that can be understood by the execution engine. This is a 'mapping' of the data received by the decision service to the Business Object Model created in previous activities.
There are a number of tools and techniques that can be used to marshal data, and the best choice will vary by project. When this activity is complete, data (preferably 'real' data) will be sent to the rule engine to fire rules, make decision and the results delivered over the same channels as the production system. These test scenarios were developed in previous phases, but now they're being run with all of the 'plumbing' in place. In the future they will serve as non-regression test suite
 

Cycle 5- Enhancing

Cycle 5 is used during the development phase as well as during the rule maintenance or governance activity. One of the goal here is to empower business users or at least business analysts to author and test the rules.

The Enhancing cycle is a transition phase in which last minute changes can be made involving some short, face to face discovery meetings with SMEs (Subject Matter Experts) to wrap up any outstanding issues or questions before entering the Governance activity. The Governance activity is an open-ended, long running process to enhance and maintain the rules created in previous activities. A governance process will vary by organization and is a fundamentally different process, usually performed by a different team than the rule development team. This team is more business oriented and, as owners of the rules and business policies, they can develop at their own pace, using the infrastructure put in place by the development team.

It is important to note that there will almost certainly be some need to enhance the object model or physical data model to add some new facts, attributes, or entities. These modifications will follow the standard release management process of the core business application.

ABRD has many advantages as a framework for the  business rule development process. It involves all the key stakeholders, provides a proven development process and a clear transition to business analysts to start the governance activities . As a business application using a rule engine is, per design, very agile and supportive of changes, all parts of the organization need to be brought together, such as business analysts, software architects and software developers to gain an understanding 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 Services integrated into the core business application. Each of these decision services executes one or more rule sets.