Stellan raises some good points about using business rules technologies in automating decisions.His questions are essentially these

• Rules are normally tied to the underlying data model and therefore difficult for business analysts to work with
• Tools make rules look too techie for business analysts to consume.
• Tools are very difficult to use
• Business Rules Tools come with a lot of baggage that are unnecessary for business analysts.

Many vendors including my company will be guilty on many counts for all these charges. However, there are some points that I wanted to make. Based on what I have seen, here are some of my own observations.

• Non-technical users like business analysts are most comfortable with Decision Tables.
• They are also comfortable defining decision making sequences using Flow charts
• They are not very comfortable with writing If Then Rules or Named Action Sets or Named Condition Sets (Decisions Branches)

The example that Stellan uses to illustrate his point is this one.

One of your analysts suddenly discovers that a competitor has lowered the levels for being eligible for a discount and you think that this will impact your business if you do not do the same, so the analyst needs to quickly adjust your current discount levels in the system.

Here, the rules we are talking about are Adjustment Rules for Pricing. And typically these kind of rules change often.

These kind of rules are mostly Decision Tables. Other scenarios where rules will be modeled as Decision Tables will be Rate Calculations, Eligibility Criteria, Pricing Rules etc.

As I had mentioned in my Seven Tips for your first Business Rules Project, how rules are designed is a critical aspect. You need to keep business analysts in mind when a rules enabled system is architected. Good tools by themselves are useless, if they used incorrectly.

Here are some suggestions on how to involve your business users

• All things start small. So, don’t push your business analysts into business rules too early
• Involve them in the rule capture phase, and get your IT Developer to write the rules under their eyes. You can consider Pair Rule Development for a small period of time.
• Involve your business users in the rule design phase. Here organizing the rules into logical units is the deliverable, and their inputs will be invaluable
• Let them discover how easy it is to update decision tables and Flow Rules. Do not expect them to do anything more than Decision Tables and Flow Rules.
• If you are using Inference Rules and Rete, things can get complex. So, use expert judgement as to whether you want them to do this at all.
• With If Then Rules, they can probably begin with making parametric changes, and with experience go into adding new rules themselves.