Monday, December 6, 2010

What is a Rule Repository?


What is a Rule Repository? What does it do? Why have one? Believe it or not, I actually went out to everyone in the industry that I could think of who might have an opinion, searched the web, went to my old text books on rulebased systems and this is all I can come up with. My friends came up with everything from “Who needs it if you have CVS?” to “Absolutely Critical and 50 reasons why you need it.” (Don’t panic – I won’t give you those 50 reason why.) But, all in all, it’s quite a bit like doing ITIL (Information Infrastructure Information Library) and SOA (Service Oriented Architecture); some do it and are quite good at it and can show a HUGE benefit from even getting started. (See InfoWorld Article on ITIL, 10/23/06, page 23+) on how to get started on ITIL and the one on getting started on SOA.) Meanwhile, others just don’t understand it at all. And there’s everything in between. So, here goes. Generally speaking, a Rule Repository is much like a source code control system with some really cool enhancements. First – what are a few of the things that a source code control system like CVS or Clear Case should provide for you?

  • Life cycle management, from creation to retirement and store the retirement
  • Version control, from to the latest pre-alpha
  • Audit trail. For Auditors and bookkeepers (The IT variant).
  • Who put what where, when did they put it there and the reason that they gave.
  • Check-out and check-in and privileges thereof

So, what should a Rule Repository give you other than that? Well, things like

  • Really, really fine-grained access management
  • Search for objects accessed during the last run of the rules
  • Search for objects not touched by the last run of the rules
  • Search for which rule fired the most on the last run
  • Search for which rule fired the most on the last ten or twenty runs of the rules,
  • Search for which rule never fired on the last run of the rules
  • Search for which rule never fired on the last ten or twenty runs of the rules
  • Search for which rule has NEVER fired
  • Search for which rules ALWAYS fire and how many times, average, for each one
  • Stepping through the rules with a debugger for each line in the rule (lots of overhead for this one) and this one is the trickiest of all
  • Tracking who put the rule into the system and why but more complex than CVS
  • Authorization for anyone to put rules into the system
  • And lots more…

Now why in the world would you need all of this (and more) clutter? Answer: Auditing for Sarbannes-Oxley, SOA, IT Auditing compliance, and, most of all, debugging of the system when something doesn’t go according to plan. If you’re using one of the "open systems", "free-ware" or "share-ware" versions like OPSJ, Jess or JBoss Rules you can always integrate the rules with the CVS or Clear Case. On the other hand, if you’re using the rich rule repositories of IBM/ILOG JRules or FICO Blaze Advisor then you will have laid the basic ground work for SOA, Sarbannes-Oxley or any other IT auditor who comes around. All you have to do is do it right the first time. Again, you might want to go read the article in InfoWorld and maybe something more recent.



1 comment:

Carole-Ann Matignon said...

Hey James,

I like your post. I added some thoughts -- and history on how we got there -- in a follow-up post on my blog:

Let me know your thoughts!