Last month Manny Gandarillas wrote the "Devil's Advocate View of Business Rule Engines."^[1]  A devil's advocate is described as someone who argues against something not as a committed opponent but simply for the sake of argument.  The idea behind a devil's advocate is to help determine the validity of something.  Manny makes some good points in this article, and puts some common (if tongue in cheek) words in the mouths of some of those being pitched business rules.  But there are four fallacies in his argument that I just can't leave unchallenged:

• He argues there is not broad agreement on the definition of a Business Rule Management System (or BRMS) when there is.
• Like many supporters of business rules, he thinks that the technical innards of business rules products matter.
• The value of business rules technology is not that it lets business users write their own applications but that it allows the business and IT to collaborate effectively.
• He worries that businesses don't see the value of a "centralized knowledgebase" and of the huge project to develop and integrate one when this is a failed model for business rules — incremental automation of decisioning is the model that works.

Let's drill into these one at a time.

I am constantly irritated by the myth that the business rules technology market is "fragmented" or that there is not a broad consensus on what a BRMS should do.  Go look at the market numbers, add up the revenue from the top technology vendors (who all have the same basic definition of a BRMS), and compare it with the minor players.  The overwhelming percentage of revenue goes to a group of vendors who offer recognizably similar and comparable products that can be used to manage operational decisions with business rules.  I define a BRMS as having a critical set of functions:

• Technical (programmer) and non-technical (business user/analyst) rule authoring tools.
• An accessible, semantically rich, and declarative rule syntax.
• A repository to store, version, manage, and audit rules.
• Tools for testing, validating, verifying, and simulating rules and rule changes.
• Deployment capabilities to package up rules and put them into a decision service.

You can find many products that have these capabilities, you can compare them easily, and where they do differ you can clearly articulate the differences.  At a minimum, IBM/ILOG, FICO, Corticon, Visual Rules, Drools, Oracle Rules, and Delta-R meet this definition (though at different levels of sophistication, clearly).  Perhaps the problem is that the products Manny is used to (Haley, Mindbox, and Pega) are not like these products?  Pega is a rules-based business process management system not just a BRMS while Mindbox and Haley are no longer available as general purpose rules products and were pretty quirky even when they were.

The second problem is related in that far too many people who talk about rules start talking about the technical mumbo-jumbo that matters to them and not to business people.  Any vendor that expects business people to

compare the details of sequential programming that they never fully understood (object-oriented, subroutines, etc.) with new and improved details (RETE, truth maintenance, backward chaining)

is either out of touch with what matters to business people or is spending too much time gazing at their own navel.  These technical details NEVER make the difference between success and failure in rules projects.  They contribute to a product's ability to do things that do matter — like find incomplete sets of rules, or efficiently manage rule execution, or scale as more rules are added and changed — but the technical details are just that — details.

Moving on, let's consider the statement that

Another advantage of Business Rule Management Systems (BRMSs) is that business people can write their own rules.

Or, as he says later, whole applications.  Personally I don't think this is an advantage of business rules.  Even if adopting business rules meant business users could write their own rules, it would not be that interesting as the vast majority of business users don't want to write business rules any more than they want to write code.  What a BRMS and a business rules approach allow is collaboration.  Using a declarative, verbose syntax and visual metaphors makes it possible for a non-technical user to understand and collaborate on rules relating to their domain expertise.  And that's important to remember — business users don't need to be able to work on an arbitrary rule, just one that is inside their domain.  Sometimes these business users will collaborate with IT by writing a specific set of rules themselves, sometimes by editing existing rules or creating rules that conform to a template.  But often the most value comes just because, for the first time, the business and IT folks can look at the same thing and both of them can understand it.

Even business rules are not perfect in this regard — it is certainly possible to write inaccessible, confusing, and even cryptic business rules.  And when people are not thinking about decision-making with rules they can get themselves in trouble by randomly replacing bits of programming logic with business rules.  But focus on the decisions at issue and use a BRMS the way it is intended and it will (to quote a rules user I met some years back) "do just what it says on the tin."  One of the best things about being an independent consultant working with lots of rules vendors has been discovering just how many of them have customers who share this perspective — use a mainstream BRMS the way it was intended and you get the results people like me say you will get.

Finally, the most pernicious fallacy of all — the need for a massive get-all-the-rules-in-one-place, rip-and-replace, build-a-central-knowledgebase project.  Given that this mindset already killed the expert system/AI view of rules, you would think this would be dead and buried by now, but it keeps coming up.  And Manny's example (from Sungard) shows why.

... five different business units, each using its unique data model and a mix of COBOL and Microsoft.  An effort to centralize rules for the entire organization failed when the time/resource/cost estimates exceeded even the most pessimistic projections.  Resistance came from business units that had rules embedded in applications and from those whose motto was "if it ain't broke don't fix it."

Let's think about centralization first.  Either the five divisions had a decision in common or they did not.  If they did then there is almost certainly value in making it consistently and in reducing the cost to change.  And adopting a BRMS could help you do that.  If, on the other hand, the systems gave the right answer, did so consistently across the relevant channels, and didn't cost more or take longer to change than was acceptable then they didn't need a business rules engine.  No technology should be adopted unless there is a compelling business problem that it can solve.  Business rules technology can ensure decisions are made consistently, it can make it easier to get the decision right (by bringing business users into the process more effectively), and it can dramatically increase agility/reduce cost to change.  Either those things matter enough or they don't.

And as for the big-bang approach, one of the values of business rules technology is that it can (and should) be adopted incrementally — one decision at a time, enhancing existing systems by adding decision services that inject "intelligence" into the system or upgrading legacy applications by replacing a hard-to-change module with a more flexible, agile decisioning component.  Adding decisioning is incremental — that's the point.  Anyone who addresses rules as a rip-and-replace, centralize-everything-at-once project deserves the grief they will surely get.

So, speaking as someone who has worked with all the major vendors and spoken with dozens, if not hundreds, of their customers, here's the realistic view.  We know what a BRMS is, we know how to make it work, and we have lots of cases that show it does — come to the Business Rules Forum in November or read the examples in Smart (Enough) Systems (the book I wrote with Neil Raden) and you can see plenty.  There are technical differences between products but these are not critical to project success.  A BRMS is not the silver bullet that will let business users build their own systems but it will let IT and business folks collaborate like never before, increasing agility and reducing errors.  And decisioning and a BRMS can and should be adopted incrementally, generating an ROI at each stage.

Is everything rosy?  Well, no, of course not.  Too many IT professionals have heard of rules but not adopted them, we still have too many people talking about rules in terms of expert systems and AI, and we have too many companies with one or two successful BRMS adoptions who can't make the change become more decision and rule-centric.  But these are problems we can work on.

Using business rules and a BRMS to automate and improve business decisions is a powerful and increasingly well-understood way to deliver business value.  Decisioning delivers smarter, simpler, and more agile business processes and systems.  It's time to engineer your organization for change and adopt business rules.

References

[1]  Manny Gandarillas, "Devil's Advocate View of Business Rule Engines," Business Rules Journal, Vol. 10, No. 7 (July 2009), URL:  http://www.BRCommunity.com/a2009/b487.html  

# # #