On current project, we chose the business rules engine called inRule. The product itself, compared to the BizTalk one, is very interesting, in my two days of learning, compared to BizTalk Rules Engine, it provides enhancements on

• a much much much more fancy environment for creating the rules, being the irAuthor, word plugin, visual studio plugin. The interface is much smoother and feature rich (i.e. decision tables). Compared to this, the BizTalk rules composer needs a long way to go.
• a very good tool for debugging, both creating unit tests and functional test cases. a much more feature rich in tracing. It certainly reminds me the dark days of scratching my head, watching the debugview to figure out what went wrong in debugging my BizTalk rules.
• a good version control business rule catalog, provides source control on business rules and stage promotion (DEV-.QA->Prod)
• a good wrapper for the engine service, providing a in-process plus out of process rules execution host
• a great report covering all the rules, this is almost mission impossible in BizTalk one!
• extensibility..silverlight control..via irSDK

The inRule models the rules on entities, rather than a mix model (entity plus XML schema) provided by the BizTalk rules engine. To a guy like me with fairly extensive exposure to BizTalk BRE, it is somehow a bit inconvenient. To me, the BizTalk BRE score better in tighter integration with BizTalk, more low level control over the engine functions, convenience with strong typed schema, long running facts… I would argue functional wise, I cannot picture anything inRule can do while BizTalk BRE cannot.

On the other hand, I do like inRule, for its effort in making a true business user friendly BRE engine. On this note, I recalled once make my team of BA laugh when I talked about how they can use BizTalk BRE to create and edit the rules.