Prologue
I recently came across a LinkedIn thread which inaccurately described the origin of the term “BRMS.” In response, I’m going to cover the real story based on my first-hand account. While, like any story, many versions may be true. Therefore, I welcome other storytellers in joining me. Note: by BRMS, I mean Business Rules Management Systems. So if you’re looking for the origin of Benefit & RIsk Management Services, Biologic Response Modifiers, Bayesian Regression Models using Stan, or Backup, Recovery, and Media Services, look elsewhere.
Once upon a time…
I was working in Sales at ILOG around 1999. It was definitely sometime before 2000 because that’s when I moved to Blaze Software. At ILOG, I was responsible for the entire presales organization in the Americas for Telecom. In addition to managing my team, I built and presented prototypes using ILOG’s suite of software components. I liked all of their products (of course), but JRules business rules engine (now Rules) was my favorite. Having built expert systems prior to joining ILOG, I had an affinity for AI-ish technologies.
The more I worked with JRules, the more I appreciated the cleverness of the Rete algorithm used in execution. I spent a lot of time trying to figure out how to explain JRules and Rete in a simple way and come up with materials that my team could present. This was no easy task. I remember a lot of glazed expressions. How do I convey the power of rules technology when each meeting would get technical? Business users couldn’t keep up and developers didn’t want to keep up. Developers were more comfortable writing C++ or Java than exploring our product. In the worst situations, prospects compared us to database triggers.
And then we kissed the frog…
My co-worker had a brilliant idea on how to simplify the concept. He compared JRules to Database Management Systems (DBMS). I was resistant to his idea initially, mainly because of the database trigger confusion. However, once we worked together in refining how to articulate it, I was pleased with the result. My co-worker proposed that we call JRules a Rulebase Management System (RBMS), which I rejected and James Owen will forever hate me for that. It’s the “rulebase” that bugged me. It sounded too technical and structural and would not help our cause with business users or developers. I wanted the name to reflect JRules’ higher purpose: managing policies and more generally, logic. I also remember wanting to re-order the letters at some point, but I can’t remember why. Anyways, I proposed Business Rules Management System (BRMS) and that name stuck.
What is a DBMS?
A DBMS is a software system that allows users to manage databases. This includes creating, reading, updating, and deleting data in databases. DBMS organizes the data in such a way that it can be efficiently extracted by other users and systems. In addition to storage, DBMS provides security and promotes data integrity and consistency throughout an organization.
For the sake of the younger generations, here’s is a brief overview of the evolution of software systems up to this point:
- First, we had monolithic systems, which by definition, included everything. Back in those days, customer details had to be duplicated in every single system throughout the organization.
- Then, the industry realized that there was value in extracting the Data out of those applications so that it could be shared by several applications and protected (backup, security, etc.). Enter DBMS.
- Next, the industry realized that there was value in isolating the Presentation layer. I will not go into more detail since the rationale was operational rather than for management purposes.
- Finally, the industry was realizing that there was value in extracting the Logic out of the application. This is where JRules could play. Enter BRMS.
How do BRMS resemble DBMS?
Prior to BRMS, the focus was on helping organizations quickly update pieces of code without the burden of a full-blown software design effort. That is why JRules and other BREs were developed. But by comparing rules technology to DBMS, we uncovered enterprise benefits. Just as DBMS treats data as assets, BRMS treats logic as assets. A BRMS, like DBMS, provides the following capabilities:
1) Protection
When a crash happens (which is inevitable), a DBMS ensures your data is not lost for good. All you need is your DBA to resurrect the most recent backup. Similarly, a BRMS provides a backup of your logic for re-use in the future. This comes in handy not only in times of catastrophe but in times of change. For example, you could be testing a new product, feature, or marketing campaign. With a BRMS, you can easily rollback to a previous version of your logic once the test is over.
While it’s become common practice to use a source code management system (ex. Subversion) to backup and manage your code, the focus is on functionality and not logic. Relying on source code management systems to manage logic is not practical. Often, many bug fixes occur between one different logic versions. Reverting to a previous version means you would lose all those bug fixes. Therefore it’s best to manage the logic separately, in a BRMS.
A DBMS also secures your data. Similarly, a BRMS secures your logic through access control. Some may have no access, others may have read-only access, and others may only have editing access to specific parts of the logic. A BRMS ensures only the right people can manage the logic.
2) Sharing
Sharing is an obvious benefit from storing your data in a database. Having a database allows you to enter data once and then have all your systems access that data. The time savings is huge, not to mention the reduction in inconsistencies and errors. A BRMS also allows you to author your logic once and then have all your systems access that logic. For example, a bank could write the logic for credit origination once, and deploy that logic to a call center application, online self-service application, and mainframe processing (for mailed applications).
In addition to sharing across applications, logic can be reused by multiple decision services. For example, local and federal tax laws and rates. Rules that govern what to charge when can be authored once and applied to the different decision services, regardless of the product line.
3) Management Tools
As the name suggests, DBMS come with tools for managing data and its structure. Similarly, BRMS comes with tools for managing logic, including creating, viewing, and updating business rules.
4) Deployment
This is where BRMS differs from DBMS. Applications typically access databases via drivers. In the case of BRMS, a decision service exposes the decision logic in which applications can invoke. The decision service is a little more integrated as a “native” component of the architecture (ex. Java class, .NET assembly, a web service or session bean).
This DBMS analogy has enabled us to communicate the value of rules technology and to accelerate its adoption. I’m proud to be a part of this BRMS origin story and the BRMS evolution. If you have a different story, I’m curious to learn how you arrived at that acronym. Continue to my next post where I talk about BRMS and The Repository.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager