Skip to main content
Agile Rules? A "conversation" with Scott Ambler

Scott Ambler is a well known writer on Agile techniques and some of his comments were posted on a business rules group recently - I found some of them very interesting and so got Scott's permission to re-post them here and thought I would comment on his thoughts from a rules perspective.

My [says Scott] focus has been on the modeling side of things, and I often use business rules as a perfect example of why it's important to use the right model for the situation.  Business rules are related to many aspects of your system, to capture them in use cases makes it very difficult to refer to them in data models for example (and vice versa), so my advice is to capture BRs in some sort of BR spec/database/... where each one is uniquely identifiable and therefore easy to reference.  The overall concept is called single source information, Single Source Information: An Agile Practice for Effective Documentation and it is the only new practice added to Agile Modeling for v2.

Excellent advice. Business rules are not something to mix in with all your other requirements, but something to "model" or "document" explicitly. They change on their own pace, have different external influences (legislation for instance) and so on. Daryl Kulak's book has some good tips on using business rules alongside and complementary to use cases, for instance.

When asked if he has any guidelines on how to implement business rules, he says:

The quick "consultant answer" is that it depends on the situation. <snip> options:

  1. Rules engine.
  2. Rules component/class (basically a home grown rules engine).
  3. Implement the rules in business classes.

As for maintaining the rules and sharing them, it's harder to do the further down that list you go.

These are, of course, the three sensible ways to do this. When I started working with business rules some 5 years ago one of the most common evaluations customers did was build v buy. Now they are pretty much deciding against building their own rules engine.  Most organizations seem to have realized that if they want to manage rules they should buy a rules management system in the same way they buy a database management system to manage data. There are always the NIH exceptions but by and large it is now 1 v 3.

So when should you pick 1 over 3? Well there are really four key reasons:

  1. You have a very large number of rules, making management a key issue - see Sun's rationale for choosing Blaze Advisor.
  2. You have some very complex rules that will be hard to "code" and easier to "declare"
  3. You have rules that change all the time and want to be able to have your system reflect this - see Egg for an example of a Blaze Advisor customer that makes regular changes.
  4. You have rules that require some business know-how to manage effectively and so want to empower a business person (an insurance underwriter for instance) to manage them rather than relying on IT.

I am often asked who our biggest competitor is and I usually say "a room full of Java programmers". If one of the four things above is true, perhaps you should think rules not code.

Lastly Scott was asked about when he saw clients using business rules engines:

I don't really have any hard and fast guidelines, although the following comes to mind:

  1. The client paid for the rules engine and now needs to justify it's purchase.
  2. The application is business rule intense (a gut feel call).
  3. The business rules, at least many of them, are potentially reusable (though it's not reusable until it's been reused, see )
  4. You have rules engine expertise on staff and will be able to keep them over time (otherwise, your app wouldn't be maintainable).  Most of my rules regarding MDA would be applicable to BR engines, see Are you ready for the MDA

Now I might be a little less cynical about #1 - saying that customers with rules engines want to maximize re-use and so want to keep all the rules in the same format. I might also qualify #2 by saying that this means if meets one of my four criteria above. #3 is a great point and part of why you need a business rules management system and not just a business rules engine. #4 made me think though. Was this true? Clearly any tool has this problem to some extent but business rules management systems should reduce the risk as the business users have some control over the actual rules - Egg, for instance, rolls out new changes without any IT involvement. Nevertheless he makes a good set of points.  While most of them do apply to business rules in much the same way as they do to MDA, there are a couple with which I would take issue from a business rules perspective. Here are the five items where I think MDA and rules differ.

  • Do you have people who are both strong modelers and strong coders?
    • In general you need developers who can understand how rules are structured and who can code but they don't need to be strong rule-writers. This is why business user empowerment through business rules management is so valuable.
  • Are your stakeholders sophisticated enough to understand PIMs?
    • The equivalent issue in rules often does not arise - the rules product allows the stakeholders to see the rules in a format that they find familiar, using their terminology. This is part of the beauty of the approach.
  • Are you allowed to be agile?
    • The equivalent here is that you may not be allowed to give the business users real power over the rules in their system. Some IT departments, and some business users, like the current arrangement better as it allows them to blame each other for failure. Only if everyone feels in it together can IT and the business see the value of having business users own the rules. You may not be allowed to change the ownership.

Anyway, thanks Scott for the interesting prompts and thanks to Terry Moriaty who looped Scott into the conversation on the Yahoo group.

related posts