Friday, January 26, 2007

How to understand a large ruleset?

Peter Lin has a very valid concern :
My main caution to users is that no matter how nice the writing part is, how
does the tool make it easier to maintain and understand a large ruleset? Does it
have the ability to analyze the rules and show the relationship to the user?
At Acumen Business (where I work), we have addressed this issue by the introduction of the Interactive Rule Map. Sometimes also referred to as Rule Spider. This dynamic rulemap shows the direct dependencies of rules-to-terms and from terms-to-rules.

There is also a complete Rule Graph generation, however that will quickly loose it’s power when hundreds of rules are defined. The interactive rule map is an advanced browser that shows parts of the rule graph.

Currently we are doing some research to integrate the Rule Validation into the Interactive Rule Map. This allows step through debugging of the just the business rules. Our prototype is looking very promising.


James Taylor said...

Blaze Advisor uses a similar approach - there is a cross-reference browser to allow you to examine all the rule interactions (with data elements, rulesets etc) as well as an execution browser to allow you to view which rules are being scheduled, evaluated, executed etc. It's a powerful technique for sure.

woolfel said...

I've tried the cross-reference browser in blaze 6.1 and it wasn't very useful. Not only do I want to know the relationship of the current rules, but I also want to be able to see older versions. this is especially important for large rulesets, which are written by a large group of people spread out over the world.

What if someone made a mistake and applied a change they shouldn't have. one of the biggest weaknesses of Blaze repository it that a ruleset is 1 file. I don't consider that enterprise level rule versioning. At minimum, an enterprise class rule repository should version at the condition level and allow me to store it in a RDBMS. I should also be able to store my testcases, test data and test reports. This way, I can really see the full life cycle of a rule and have the ability to really audit.

Will the next release of blaze address these issues?

Marco Ensing said...


Thanks for sharing your concern. On a side note, Acumen's Rule Repository does store the rules as a single entity.

A single rule will have a change history. And a single rule can allow different user access control. Or it will receive the inherited access control from the ruleset (policy), or rulebase.

Currently the rule manager has adaptors for CA Aion rules, Microsoft Biztalk and Microsoft Windows Workflow Foundation.

Do you know if the Blaze ruleset is stored as an Xml structure? If this is an open rule schema (and it should be, else you really get tight to one vendor), then we could create an adapter for Acumen's Rule Repository to give you this functionality.

woolfel said...

I've looked at the Blaze 6.x API and the format is XML. Though the generated XML is a bit cryptic. It would take some work to reverse engineer their format, which I'm told is not recommended. Blaze does not provide a rule object model for developers to extend, atleast not one that I can see in the official documents. I've asked a few Blaze people and the response I got is the internal rule object model of Blaze is not available.

I think it's rather unfriendly of blaze to prevent developers from accessing those API. If the rule object model and rule parser API is accessible and customers can get support from Fair Isaac, I could atleast build custom solution on top of blaze. Since Blaze makes it difficult to access and extend the those parts, it means Blaze is a dead end to me.

I would rather not build a ton of custom stuff on top of blaze, but the functionality is missing.

I'll take a look at Acumen's product. thanks.


make files explained if you did not grew up with them

Here is a nice post on how to define makefiles for a go project and actually teaching you some makefile constructs: