One of the considerations I faced, recently, was the notion of using a business rules engine (BRE) in manner that is often contemplated but rarely discussed. I needed to create rules in one system and apply them consistently in many other systems.
This is not a new concept, of course. We want to pull business rules out of software code. Some of the value comes from using those rules in different settings across the enterprise. There is more than one way to do this from an architecture perspective. This article will discuss this element of architecture: patterns of business rule integration.
For each of these patterns, I will discuss one sample rule and show how each pattern differs in executing that rule. Here is our sample rule: All New Salesmen at any level will have 33% lower quota for their first six months, regardless of level.
Interesting rule. The data to decide how long a salesman has been in their role is typically in the HR system. The impact of the rule is felt in the sales compensation system. Now, let’s look at the different patterns.
Pattern one: Smart center
With this pattern, a company would evaluate business rules at the data master, using them to create “derived” data attributes that are stored with the data items themselves. The rules are specific to data subject areas, not to systems. The company makes those derived attributes available via integration with “edge” systems. The edge systems do not need to evaluate the business rules since they have already been evaluated. The edge system uses the derived attributes to drive logic.
To apply this to our sample rule, we would create an attribute in the master system that would be used downstream. For our example, let’s create an attribute in the HR system for each sales employee. That attribute will be called the “quota adjustment”. It will have a floating point number from 0 to 1.0, with the default being 1.0.
In the HR system, we would create a rule as following:
If employee.DaysInRole < 180 then
employee.quota_adjustment = 0.66
else
employee.quota_adjustment = 1.0Then in the sales compensation system, the sales quota would derive from their regular formula (often by region, level, role, etc) and an edge system would simply multiply the quota by the employee.quota_adjustment.
This method is surprisingly common but it creates serious coupling between systems. When using this approach, the architect is adding a requirement to every edge system. She is requiring that the formula for calculating this value (sales quota) must use a variable that is always properly set in another system. Data cannot be out of date (since the quota value can change on any day) and in fact, the definition of “what’s the cut off date based on” is actually defined in the HR system, not the sales compensation system. All of the systems have to agree.
Pattern two: Enterprise managed
I think “business rule purists” will prefer this pattern, but I’d love to get feedback to validate that guess.
This is a distributed execution pattern. With the “enterprise managed” pattern, enterprise business rules, across multiple enterprise systems, are captured in a centrally managed data structure. The rules are tied to entities and any system that uses an entity (like customer, order, partner, or product) would query the central rule repository for the rules pertaining to that entity.
The first obstacle is a serious one: Each of the edge systems require a full implementation of the rules engine. All of the edge systems would use the same taxonomy of business events (since your rules are written to use that taxonomy). Your edge systems will need to be fairly consistent in what events they implement, and when those events are triggered.
On the flip side, if you are using a “forward chaining” rules engine, you can write one rule to calculate the sales quota, another to adjust it for the tenure of the employee, and a third to apply it to a particular sale in order to determine sale compensation. All of those rules can be stored in the central repository and attached to both “employee” and “sale”. No need to add an attribute to the employee object as we did in the “smart center” pattern.
The calculated attribute is still there, as it was in the smart center pattern, but we’ve moved the location where it is calculated. This attribute is no longer calculated at the center. It is now calculated in the edge system.
Pros and cons of enterprise managed business rules
The downside, as may be obvious from reading this discussion, shows up with two forms of difficult coupling: standardized engine and consistent semantics.
We want multiple systems to execute these rules. Each of the systems that uses the rule has to implement the rules engine. That is a major stumbling block. In fact, most systems do not have a business rules engine in them and cannot easily add one.
In many cases, we need the same business rules engine in each edge system. Perhaps even the same version of the same business rules engine.
This last requirement is abating somewhat, now that standards exist for recording and transmitting business rules. Given these standards, you can now implement two different business rules engines, from different vendors, as long as both can understand the same standard rules language.
(Aside: The most promising mechanism for consistency in business rules, that I’m aware of, is DMN and FEEL. If you think I should be referring to a different standard, say so in the comments).
As difficult as it may be to ensure that every downstream system implements a compatible rules engine, that is not the most difficult part! Far more challenging, and just as important, is the requirement that each business rule actually means the same thing in multiple systems. To pull this off, we require that “chained” business rules all execute in the same manner, reacting on the same business events and conditions. This semantic normalization is exceedingly difficult to pull off and requires a level of organizational maturity that is uncommon.
In our example, we are looking at a business rule that relates to the number of days that an employee has been in a role. Great, but is that calculated when midnight hits, or is that calculated when a sale is made? Is the date of the sale available when the order is being booked? Can it change later? If it does change later, does that mean we recalculate the quota on that day as well?
This is just one example rule. Multiply this by ten thousand business rules and you start to get an appreciation for the scale of the coupling you need to ensure when executing business rules using the “Enterprise Managed Rules” pattern.
Pattern three: Smart Parts
Just when you thought it couldn’t get any more difficult, surprise surprise, we come to the overwhelming favorite among our implementation patterns: Spart Parts. Why do I suggest that this is the favorite? Because nearly every implementation of a business rules engine actually starts with this model!
In the “smart center” pattern, we associated business rules to a business domain or subject area (a group of related enterprise data objects) like “customer” or “product”. All systems that use that data subject area would use those rules. The Smart Parts pattern assumes that we attach rules to systems, not data subject areas.
Of course, in most organizations, even the best run organizations, each data subject area is mastered in a single system. So attaching business rules to that system makes sense. It also means that an organization can have completely disparate rule engine technologies between their systems, with some rules executed in SAP (or Oracle Financials), others in a no-code-platform like Salesforce or Dynamics, and a few others executed in a rules engine like Drools that has been built in to a bespoke data mastering system.
Each set of rules is distinct, managed specifically to the domain of data, and built in to the system that manages that data subject area. I call this “smart parts” because this is the most decoupled of the distribution mechanisms. Each system manages its own rules and if you want to change the rules for a system, you do it in that system.
Pros and cons of the smart parts pattern
The problem with smart parts is that rules never extend beyond the boundaries of a system. If you want to set up a business rule to apply system wide, you will have to write it as a rule in one place, as code in another, and perform it as a human process in a third.
This is exceedingly common, and exceedingly expensive. Smart Parts is a business rules anti-pattern. Yet we do it. In fact, we do it all the time. If your company is just embarking on the concept of managed business rules, you will do it too, simply because you have to start somewhere. You start by describing business rules in a single system first.
That’s when you discover that you wrote those business rules in a language that is specific to that system (like using Apex inside Salesforce, or ABAP inside SAP). Even if you can export the rules using an API, no one else can understand them. That’s also when you discover that you wrote the rules in a system specific way, tying rule evaluation to events that do not make sense from an enterprise perspective.
The upside of the smart parts pattern is that your systems display light coupling. Each simply manages its own rules and doesn’t tell anyone else. The downside is that each rule that must apply between systems cannot be applied to multiple systems without writing that rule multiple times, in different languages and technologies.
So what’s the result of this understanding?
In order to improve something, you have to name it. By giving names to these patterns, I hope to form a basis for improving on any particular company or client’s use of business rules engines (and now decision engines… a different but related topic).
In one client of mine, I needed to identify these patterns in order to negotiate a transition from one pattern to another. There were considerable discussions about technology as well as company readiness and the difficulties of systematic coupling between people, processes, and systems. Achieving agility with a business rules engine is definitely a two edged sword. I hope to not only use this understanding in the future but also to share it with others who may benefit.
Did you find this list useful? Did I miss a pattern? Please let me know in the comments. I’m amenable to updating this post with broader ideas.