Comments on: Live from DIALOG - Best Practices in Agile Business Rules Development

By: Jerome Boyer

Jerome Boyer — Wed, 27 Feb 2008 07:07:09 +0000

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

By: Agile Business Rules Management Requires Methodology « Commercial Intelligence

Mon, 25 Feb 2008 19:20:38 +0000

[...] Agile Business Rules Management Requires Methodology Filed under: Business Rules, Decision Management, Methodology — Tags: business agility, Business Rules, conditions, Decision Management, elicitation, exceptions, Haley, Ilog, Methodology — paul@haleyAI.com @ 2:20 pm Don’t miss the great post about his and Ilog’s take on rule and decision management methodologies by James Taylor today (available here). [...]

By: Paul Haley

Paul Haley — Mon, 25 Feb 2008 18:32:23 +0000

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?