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.
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:
Harvesting, the activity of gathering business rules
Prototyping, the activity of entering business rules into the BRMS
Building, the activity of building a working system representing the organizations business rules
Integrating, the activity of deploying the rules to an execution environment suitable for end to end testing
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
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
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:
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.
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%
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
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 marshalling 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.
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.
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
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.