Business Rules Engine versus BRMS: The Origin

on January 6, 2011
SMARTS™ Data-Powered Decision Management Platform

In the comments of a recent thread in a LinkedIn discussion, I realized that the origin of the term BRMS was not accurate.

As for any stories, there are often more than one version that may be true.  I welcome other storytellers to join me and shed the light on the true origin of the term BRMS.  Let me tell you here in full details the story I am intimately familiar with.

Once upon a time…

I was still in Sales, still at ILOG.  It must have been year 1999 I am guessing.  It was definitely before 2000, when I moved over to Blaze Software.  I was responsible for presenting, demoing and building prototypes with the entire set of software components that ILOG had to sell.  I liked all of their products of course but the one that got my attention was Rules (then JRules).  After a few years building expert systems (prior to joining), I knew I had a lot of affinity for the AI-ish technologies.  It was not a surprise that their rules technology caught my interest.

I developed a lot of respect for the cleverness of the RETE algorithm.  I was so excited about it that I spent a lot of time trying to figure out how to explain it in a simple way.  Being responsible for the entire presales organization in the Americas for Telecom I also had to come up with materials that my team could present.  I remember a lot of gestures back then that were caught on some videos that I would not dare watching now!  It was complicated though to convey the power of the technology when each single meeting had to start *that* technical.  The main issue we were facing is that Business Users were obviously out of the picture as soon as we got into that level of details, and developers were typically more comfortable writing C++ or Java than exploring what appeared as a clever little tool.  In the worst situations, we had to explain why it was better than writing database triggers.

And then we kissed the frog…

Well…  Kind of…  If the rules technology was seen as a frog back then, you can really tell that something happened when this ugly BRE turned into a charming BRMS (no kiss involved though).

The sales guy that I was working with had a brilliant idea on how to simplify the concept.  He came to me with this analogy to DataBase Management Systems (DBMS).  We tweaked a few concepts together and refined how to articulate it.  I was a little resistant to the idea at the beginning — mostly because of the database trigger confusion I feared — but it ended up looking quite good after we discussed it.  James Owen will always hate me for not liking the name that my then-business-partner proposed: RuleBase Management System (RBMS).  It bothered me though because I wanted it to be not so much about the rulebase (which sounded technical and somewhat structural) and more about its higher-level purpose: managing policies and generally speaking *logic*.  I remember vaguely that I really wanted to change the order of the letters but now, 10+ years later, I just can’t remember why!  So I proposed Business Rules Management System (BRMS) and we got a term we both liked!

So how do BRMS resemble DBMS?

I am sure that you have heard it many times in the past decade.  For the sake of the younger generations, I will explain it one more time.

Following the evolution of software systems, we have seen several important eras:

  • Monolithic Systems included everything by definition
  • Then the industry realized that there was value in extracting the Data out of those applications so that it could be protected (backup, security, etc.) and shared by several applications — do you remember when customer details were still duplicated in every single system throughout the organization?
  • Then the industry realized that there was value in isolating the Presentation layer — I will not go into much details here since the rationale was operational rather than for management purpose.
  • Then the industry realized that there was value in extracting the Logic out of the application.  That was where we were.  We were starting to realize it.

Initially we were more interested in quickly updating pieces of code that needed to change without the burden of a full-blown software design effort.  This was really the primary reason for using a BRE.  But when we looked at the parallel with DBMS, it became clear that more benefits were at stake.  Yes we want to treat the logic as assets like we have been doing for the data stored in the database.

  • Protection:
    • In prevision of a “catastrophic” event, having your Data in a database allows you to easily back it up.  When the crash happens — and it always end up happening sooner or later — it takes a DBA to resurrect the most recent backup and get you back on your feet.  Why wouldn’t you want the same protection for your business logic?  Nowadays it is common practice to use a source code management system for your code (like Subversion, CVS, etc.) which provides that level of functionality.  There is a difference though…  Code evolves to add functionalities and fix bugs while business logic might evolve in a non-progressive way.  You might want to keep around older pieces of logic that applied to older accounts (think about grand-fathered terms and conditions).  Some experiments regarding marketing offers or account management might be cancelled if they do not perform.  Going back to the previous version of the code may not be practical as bug fixes may have happened in that tie window.  It is feasible to manage the logic with the code of course but because of the frequent changes — possibly back and forth — of the logic, the processes that apply to code life-cycle may be overkill for the business logic.  If it is separated then you can more easily back up and restore the revisions as needed.
    • Protection refers also to the security required around your business logic.  In the same application, you may want to grant different levels of control to your stakeholders.  Very often, access control allows people to see the logic across the board but they may be restricted to edit only the business rules that apply to their business unit.  In some more extreme cases, groups might be even more isolated with no read-access to parts of the logic.  We have seen that actually more frequently as it applies to a competitive secret sauce such as a risk score formula.  Access control at the code level is often more permissive.
  • Sharing:
    • That is obviously a very important aspect of storing your Data in a database.  If you can enter your data only once and automatically have all systems know about your product catalog or customer list, it saves you from a lot of extra work and potential inconsistencies.  the beauty of the database is also that it is agnostic of the technology used in the application that accesses it.  The same is true for your decision logic as well.  If you can codify and execute your origination logic only once and apply it consistently throughout your sales channels, you can obtain the same benefits in terms fo savings and consistency, leading to client satisfaction, etc.  Rules captured in a BRMS can be deployed to a call center application as well as the online self-service application, as well as the Mainframe processing the mailed applications.  Some of them are also agnostic of the technology used (C/C++, Java, .NET, COBOL) but it is not always true.
    • Sharing can also apply to business rules to that are reused by multiple decision services.  Take the example of a global application with decisioning logic segmented per State or Country.  You likely have worldwide policies that need to be included no matter what in all deployment and possibly some policies that are “a la carte“.  Segmentation might be per line of business, product-line or type of transaction.  the idea is the same.  You can manage the business rules at the level of granularity that makes sense and reuse them again and again in your new decision services.  Keep in mind that you can mix and match the segmentations too. I recall a massive project for healthcare claims processing that divided the problem into rules for each one of the 50 States and for each medical problem.  It was the only way to codify and manage such a large body of rules effectively.  We are talking about hundreds of thousands of rules here — although the divide-and-conquer approach allowed them to reduce that number to a few dozen thousand rules in the end.
  • Management Tools:
    • DBMS come with tools for managing the data and its structure.  The same is true with BRMS.  Authoring clients allow to view, create and modify business rules.
  • Deployment:
    • Applications can access DBMS via drivers.  In the case of BRMS, the decision service is a little more integrated as a “native” component of the architecture, e.g. a Java class or .NET assembly, a web service or session bean, etc.

This analogy has enabled us in the industry to communicate the value brought by the technology and to accelerate its adoption.  It has been quite nice being part of that transformation.  I wonder who else came up with the same acronym and whether they had the same rationale for landing on BRMS.

Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager

Search Posts by Category


Sparkling Logic Inc. is a Silicon Valley-based company dedicated to helping organizations automate and optimize key decisions in daily business operations and customer interactions in a low-code, no-code environment. Our core product, SMARTS™ Data-Powered Decision Manager, is an all-in-one decision management platform designed for business analysts to quickly automate and continuously optimize complex operational decisions. Learn more by requesting a live demo or free trial today.