« Book Review: Real-Life MDA | Main | Are business rules a bridge or a ferry? »

Why business rules? A curious reader asks..

I got a comment yesterday from Alexander asking some pithy and pertinent questions about business rules. Here then are my answers (somewhat delayed due to a machine crash wiping out the first version of the post).

Personally, I have nevery really understood the business rules movement.

Well that's why I'm here. Seriously, this is why I write the blog. I think business rules is an under-appreciated and under-exploited technology and it is my mission to convince people of this. Really.

So here goes with his actually statements/questions with my follow-up answers and links

Rules based languages and rules engines have been around for decades but they have never really taken off except for in small niche segments.

  • Well business rules engines have certainly been around for a decade. Before that I might consider that the market was generated by AI languages and expert systems.
  • The business rules market learned a lot from the expert systems experience, not least that to be useful there must be easy integration with enterprise applications. This is why most modern business rules products can manipulate .Net, Java or XML objects and deploy as web services, EJBs or whatever.
  • While it is true that business rules have thrived in certain niches, this is because those niches required business decisions to be automated. Business rules are a great way to automate decisions and so thrived in those niches. Indeed business rules work better than code for this because the separation gives you flexibility to make changes with minimal impact on basic systems, because business rules are more understandable to business-level people and because rule management lets users update rules in a controlled manner without knowing anything about syntax or code.
  • As the pressures on companies to act more quickly, across more channels, while enforcing more regulations and focusing more closely on individual customers, the need for more organizations to automate decisions will grow. As it does, the use of business rules will grow too.
  • The growth of the loosely coupled organization (described in The Only Sustainable Edge) forces decision automation also as it is not acceptable for an extended supply or demand chain to wait for a person to be available. That means computers are making business decisions and code is not a good way to automate those decisions.

I have never seen a convincing argument for why developers should stop coding business logic into applications in favour of using a business rules engine as general way of developing applications.

  • I don't believe that anyone suggests that a business rules engine is a good general way to develop applications.
  • Anyway, who builds applications any more? Haven't we all gone over to services?
  • It seems to me that there are lots of different kinds of services and that one of the categories is that of decision services.
  • It becomes particularly clear (to me anyway) why one would use business rules once you start thinking about the micro decisions your business takes all the time. If you really want to control decisions at that level, and increasingly you do, you need more tools in your toolkit and business rules should be one of them.
  • Building decision services with business rules, and so reducing the maintenance burden on those services going forward by empowering business users to do some of their own maintenance, frees up IT money for innovation and let's programmers stop doing maintenance and start doing something interesting. Given the amount of time a typical decision service will spend being changed, much greater than it will spend being developed, technology for developing decision services should set you up for "change time"
  • There are also a few problem domains where you simply must have inferencing such as that provided by the Rete algorithm (or updated versions of it like Rete III) but these are a minority of the decision-centric problems that rules work well for.

My experience with rules engines is that they are much more difficult to work with than procedural or object oriented languages are are almost impossible to debug.

  • Given a focus on the kinds of decisioning problems for which business rules work I don't think this is generally true
  • The testing and debugging tools for business rules management systems, at least good ones like Blaze Advisor and ILOG, are really sophisticated. They support stepping through rules, evaluating rule execution methods, watch and trace and all the usual stuff. More and more verification and validation tools are included and the recently announced Blaze Advisor 6.5, for instance, supports a version of jUnit for rules.
  • Even if some programmers find them harder, and I guess some do, business users absolutely do not. Business rules can boost business and IT collaboration and resolve one of the most pressing problems with programmers - how to find good technical skills with great business know-how.
  • Using business rules can also help you avoid write-only code.
  • In many cases the problem for code is that of management. When you have 10s or 100s of thousands of rules to implement, a business rules management system simply does a better job of impact analysis, traceability, logging and so on than code. With atomic rules everything from versioning to effective dates to auditing to reporting gets easier.

Hopefully this gives you all a sense of why I remain a business rules booster. Those who are still not convinced might enjoy my top 10 excuses for not automating decisions.

, , , , , , ,
First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference Why business rules? A curious reader asks..:

» Links for April 6th, 2007 from bored and blogging
Why are business rules better than traditional code? - Enterprise Decision Management - Reasons why using business rules management system can be better than implementing rules in code. - (tags: business software) What you need to know about Decision ... [Read More]


Gary Furash

Great post. I'd go on to argue, though, that except for mechanics (e.g., how to send an email, build a connection to an MQ queue, code something wierd in an AJAX drop-down field), most of the programming stuff done could be done with a rules approach. Having used a system that encourages rules for this kind of thing, I can tell you its more productive, more maintanable, and debuggable. It's just hard to sell that because its less "programmy" and programmers love programming.

Mark Proctor

I think part of the problem is that most of the information out there is pontification aimed at none technical people to help sell an idea or a product, it just reads like marketting blurb found in handouts from some conference.

There is very little information aimed at technical users, i.e. existing java/c# usrs, that shows them how to write rules and why thats an improvement over doing it with java. Where are you use cases, your design patterns, indepth tutorials, your smell codes, technical case studies etc.

Until there is a wealth of hands on information with real meat this industry will struggle to go mainstream.

Gene Weng

Good point, Mark.

I got chances to explain rule engine to a few of my software developer friends and found it's actually not easy. They graduated from computer science department and have many years development experience!

I found the first chapter (The Rule Engine) of the Drool Document is the best I found online so far for the technical people:



I've used a few BREs such as Fair Isaacs' Blaze Advisor, JRules' ILOG and TIBCO's BusinessEvents.
However, I've noticed that none of these products or companies provide "BRE patterns". We tend to solve a wide range of problems using BREs, and I would've thought that there'd be design patterns that could help BRE users solve typical problems using any theoretical BRE.

Gene Weng

Hi John,

That's a great point. There are design patterns and best practices existing today that are common to BRE technology. However, I'd also hope more people will write them up and publish them.

Not using pattern languages, I tried to summerize some of my experience in the book chapter: The Role of the Rule Architect in Organizing Thousands of Rules



The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.