InfoWorld just came out with a head-to-head eval of the two leading BRMS offerings, ILOG JRules and FairIsaac Blaze Advisor. To sum it up, Blaze slightly outpointed ILOG overall, with better benchmark performance and documentation, while ILOG rated higher in rule management and developer tools. The new version of Blaze is speedier than the old largely through the implementation of a new RETE algorithm resulting from FairIsaac’s acquisition of RulesPower last year.
Motivated by Gartner’s insistence that a BPMS must “include” business rule management as a ticket to entry to the magic quadrant, BPMS vendors over the past couple years have either partnered with ILOG, FairIsaac, or lesser known vendor, or scrambled to build their own business rule engine and design tool. What I learned yesterday, however, when I met with Alain Gendre, ILOG’s marketing manager for BPM and SOA, is that while these formal vendor partnerships help a bit in integrating the BPMS and BRMS design environments (and of course from a selling angle), SOA is making them much less important. When a ruleset is deployed as a rule service, it can be invoked by any BPMS or indeed by any non-BPM application as well. In other words, just because your BPMS vendor has a partner agreement with BRMS vendor X, there is no reason why you couldn’t use BRMS vendor Y instead… as long as it supports rule deployment as a web service.
In Gendre’s view, rule services belong at the SOA layer, along with other business services, not – as some analysts have described it – at some higher level application or process logic layer. Business rules represent enterprise policies, shared across applications and across business processes, exactly like other business services in SOA. This makes a lot of sense to me.
Gendre believes that ILOG has a leg up on Blaze in this regard, since (he says) it integrates better with common web service infrastructure on both J2EE and .Net. I can’t judge that, but it certainly wasn’t one of InfoWorld’s evaluation criteria. Maybe it should have been.
I completely agree with Gendre: rules should be accessed via services from the BPMS, not be part of the BPMS, since BPM is just one of the applications that may want to call the rule service. Standardizing policies across the organization via enterprise business rules is the only way to go.
Well Alain would say that, wouldn’t he 🙂
Seriously, both the “titans” do a great job integrating with SOA and thence with BPMS. There’s more difference on .NET (where ILOG has a separate product from JRules and Fair Isaac has another Blaze Advisor version that shares the same repository as its Java version).
The open issues for integration are around logging (how do people want to log a process instance that executes a rule service) and impact analysis (which processes do I impact if I change this rule). There are others, but those two are more urgent.
Lots more on the blog, of course.
[…] If you recall my discussion a week or so back with ILOG’s Alain Gendre re business rules — another of Gartner’s BPMS checklist items — he explained why rules belonged at the SOA layer, not in the BPMS or any one application system. A similar logic obviously applies to ECM. It should be a business service in the SOA layer. But in rules, just as in ECM, what you have in reality are partnership agreements between BPMS vendor A and rules/ECM vendor B, involving some bit of proprietary integration to glue the pieces together. In a perfect SOA world you wouldn’t need such agreements, but so far, in the real world, you still do. […]
[…] BPMS Watch More on Business Rules and BPMHome; About; Archives; Contact If you recall my discussion a week or so back with ILOG s Alain Gendre re business rules another of […]