Paul Armborst, someone I have known for a long time, was up after lunch talking on True Adventures in Business Rules. Paul is from Westfield Group, a top 50 insurance company based in Ohio. Back in the 1990s needed to transform their business – from a mainframe/back office company to one where agents could serve customers more directly. Wanted to do more business with the same staff (pretty common view of the value of decision management). Moved to a Java based online environment that uses a Fair Isaac’s Blaze Advisor business rules management system for editing, eligibility, rate, underwrite and produce change comments.
Uncovering business rules: Used legacy code but they found only really useful for data validation; interview business exerts in a facilitated environment with someone recording; run a “model office” using a statistically significant sample of current, and perhaps desired, data.
Documenting business rules: Documenting them in structured from in something like Excel or Notes and then review them. These are not executable but can be reviewed and assessed. This will tend to get out of synch as the production rules evolve. Indeed the production rules become the primary definition. Would like to get to the point where could automatically extract usable English-language rules from the production rule repository. In other words, generate reporting on the production rules. His experience is that this is mostly a custom activity because the production environment is unlikely to contain everything you need. Westfield has a problem with programmers being very resistant to developing anything other than code. Some combination would be ideal therefore. Everyone needs to be able to work off the permanent repository – developers, rules experts, business users and so on. Developers can provide some of the information as they develop while business users will need to add some information themselves.
Implementing business rules: Paul recommends that you avoid else statements they are often complex to balance and this is, indeed, best practice. For instance, the production rule standard from OMG does not support else statements and Rete-based engines will execute faster. Decision tables represent a large number of rules in a compact form. They let you see a set of complementary rules in a compact, easy to use form. This is more compact than writing separate rules and they are MUCH easier to maintain, especially for business users. You do need your product to check for gaps and overlaps in your tables and you need to avoid building over-large tables as these can be impossible to maintain. Decision trees have some of the same advantages as decision tables in that the whole path is visible and many rules are represented fairly compactly. Gaps and complexity can be an issue and getting the nodes in the wrong order can generate very complex trees.
Another issue is stateful v stateless. Stateless is simpler to automate. Stateful maintains information while in a conversation with a user of the engine. Stateful can have some advantages but uses more resources and often required more additional conditions. Most decision services are stateless as a result.
- Isolates the business logic from other code which is great
- Very productive environment – small number of people able to produce a large amount of effective functionality that has been very stable
- Being able to execute sequentially and using forward chaining
- Can add/change/delete rule constructs without minimal worry about impact of changes – VERY important. Set of independent rules work fine and can be easily managed separately.
- All products have features who have to work around
- Testing is something you ALWAYS need to think about
They write all their rules using developers today – business minded technical people write the rules. Thinking about how to bring technically-minded business people in through business user rule maintenance. You would need to offer an environment that is more friendly and that allows you to hide technical details, rename fields so they can be more friendly and so on. You also need to back them up to make sure they think about abuse and potential problems. They can be sheltered from technical details but they MUST NOT be sheltered from a need to take a rigorous, logical approach. If they cannot learn this, don’t let them edit rules. REALLY. You also need a set of checks and balances – testing must be independent of rules development and this is more important than ever when using business users.
Sandy also blogged this session here.