≡ Menu

Live from DIALOG – Best Practices in Agile Business Rules Development


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 http://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.


Comments on this entry are closed.

  • Paul Haley February 25, 2008, 10:32 am

    Do you or Ilog have thoughts on explanation? Many feel that improvements in explanation that brings it up to the human level more than an execution trace are necessary for users to understand and improve the behavior of knowledge they maintain. BTW, the methodoloty documented on the Haley web site agrees with you and Ilog re decision points, but uses the word actions. In the methodology I developed there, we focused on what the system or business process does and then iteratively elaborating, clarifing, and otherwise refining the circumstances (conditions and exceptions) under which they are appropriate.

    One parenthetical: I think we need to emphasize knowledge more than “object” models, even if we put the word “business” before them. Any kind of object model is and should be irrelevant to business people. The word object is also wrong. Is money an object? How about “knowledge” or “knowledge model”? I think “ontology” is as out of bounds as “object” for now, and “semantic” or “conceptual” are a bit too academic for many. How about you?

  • Jerome Boyer February 26, 2008, 11:07 pm

    I would like to take the opportunity of James’s post to put some emphasis that ABRD is a Eclipe Process Framework content plugin and everybody can contribute to it.

    The goal is to develop a simple, iterative approach for developing business application using business rules. This platform should help exchanging best practices and leverage our knowledge in this field so that business rule management system (BRMS) customers will use the platform more efficiently.
    I’m still thinking we are at the beginning of the BRMS wave, Database took time to grow-up, exchanging best practices, code sample, methods will help to grow the BRMS adoption and help the developers and business analysts to quickly use this technology. Product documentation is always a good start, but experience of people in this field is always a plus.
    I started to blog on the subject see http://www.agileitarchitecture.com and I hope to be more active on those subjects. I also plan to deliver one new version-update of the content of ABRD every month, so that every one interested can help to contribute to it, and can get new fresh version.
    Thank you again for your summary, James. I will put some presentation schema in my blog.