Next up was Jerome Boyer presenting the Agile Business Rules Development Methodology, an approach ILOG makes available based on agile methodologies. The methodology has four tracks - Business Process, Data, Business Rules and Architecture. The balance between them varies and all four are built in iterations. ILOG has developed a methodology based on the Rational Unified Process - RUP - and has donated some of this to the Eclipse foundation. In particular it uses the Eclipse Process Framework (check out www.eclipse.org/epf). The EPF tool can be downloaded and lets you manage your own best practices as well as download things like OpenUP (lightweight version of RUP) and the Agile Business Rules Development (ABRD) library. The tool can then generate a methodology website.

The ABRD has role definitions, activity definitions, work product definitions etc. These are derived from the OpenUP approach and extended by ILOG to support business rules development. The ABRD has a number of goals:

• Separate rules out for management
• Involved business user in ownership
• Support traceability
• Link rules to context and motivation
• Develop rules
• Develop a domain object model
• Prepare rule sets for deployment
• Support governance process

Business rules modeling is an evolutionary process and is, as I have said before also, a perfect fit for agile values. Jerome walked through an example, making the point that identifying decision points, likely to be implemented as decision services (wiki), is critical. Each decision point is then developed using an iterative approach.

The basic process is iterative and has a number of steps:

• Discovery
  This is not particularly different from other kinds of discovery (such as requirements discovery as noted here) apart from the focus on decision points.
• Analysis
  Define a rule schema, determine where the rules must be implemented (a BRMS is key for managing the rules within a decision but other rules might be implemented in processes or database constraints), build a rule project for each decision service, refactor and synch with the data model
• Authoring
• Validation
• Deployment

But not as a sequential approach, as an iterative one with lots of loops and phases. Phases are something like this:

1. Quick discovery and analysis (less than a week)
2. Discovery, analysis and authoring (using the tool now). Continuing discovery is critical
3. Less discovery now and more analysis-authoring-validation to flesh out rules - focused on authoring
4. Deployment some rules, probably after only 25 days
5. Enhancement and maintenance

Jerome made the point that deployment should always happen before the rules are complete - it is impossible to get all the rules right before deploying them so don’t try. Cover some of the transactions and refer the rest for manual review and extend the percentage being covered over time. This is definitely a best practice in my experience. After all, you are unlikely to get to 100% coverage through rules anyway so the process will need to have some ability to refer for manual review to cover the rest. Build this early and just gradually increase the percentage handled automatically.

Jerome wrapped up by pointing out that the methodology and best practices in ABRD are not terribly ILOG specific. Hopefully other rules vendors and their customers will be able to participate in this also and a high-quality, common development methodology will be the outcome.