Real time decisioning is so complex because it blends strategies and tactics from such a wide variety of functional business areas. The decisioning logic or business rules are essentially the product of the entire real time decisioning effort, the brain if you will. As such, all those strategies and tactics can add up to pages and pages of rules. Fusing them into one interface and language can be a daunting task. The real challenge is that the strategies and tactics themselves are constant in flux.
So, the question is how do you control (or at least contain) such a dynamic, complex and voluminous mix of business rules? This question is applicable to both the initial implementation as well as the ongoing “business as usual” maintenance.
The answer is standards. All organizations need a set of standards for their business rules. These standards would naturally supersede any language standards or frameworks that come with the enterprise platform of choice. Why? Because the enterprise platform tool was built to provide a framework of code to build any real time solution and is not likely to address your specific industry application of “best offer” or “intelligent work routing” or “customer retention” or whatever your scenario may be. The reality is that most enterprise decisioning platforms have a business user-friendly interface for developing business rules, which in many ways is great benefit. However, the power of that user-friendly interface comes with a specific responsibility to adhere to rules that (unfortunately) the user needs to create and enforce themselves.
So, what are some good standards to adhere to? Well, this list isn’t meant to be comprehensive but it is certainly covers the absolute basics to developing quality business rules (i.e. decision logic).
Separation of Rules & Data
The separation of rules of data is one of the best ways to streamline decision logic. This is because the methods used to perform these two actions are incredibly different and in many ways should be done sequentially rather than at the same time. Meaning, it makes good sense to prep the data before it is used. Further, if the data can be prepped in one space and referenced in another it usually cuts down on redundancy. Its easy to get caught in this trap as we see all too often organizations will choose to hard code data into the business rules because it seems like an inexpensive alternative to proper data integration. However, in the long term this approach usually ends up costing much more in maintenance and errors.
Expression Complexity
The complexity of expressions is sometimes unavoidable however in practice it is best to keep decision logic as simple and readable as possible. This measure is meant to draw attention to areas of logic in which the expressions are incredibly complex or voluminous because those areas would naturally be a pain point for the “business as usual” teams, even if they may be unavoidable. If an expression is unavoidably complex then ensure that it is isolated and commented well by the developer. In our experience there are only ever very few core expressions that are complex so keeping them isolated and well documented provides good value vs. effort.
Visual Organization
Many enterprise decisioning platforms support visual management of business rules or decisioning logic. At times the ability to group logic in different layers and place components freely on the screen can easily become a pain rather than a blessing. As a best practice the visual organization of the logic should be as easy to read as possible and be structured (whenever possible) in a sequential and logical flow. When this is not done with care a relatively simple bit of logic can seem incredibly complex simply because of a poor visual representation. When visually organizing business rules consider what it would take to demonstrate to an audience with no skill set in the tool what is actually going on in the logic.
Redundancy of Operation
Redundancy of operation is essentially doing the same thing again and again within the logic. Examples would be writing the same expression twice or more, using two rule components when one would suffice, etc. It can be extremely easy to allow this to happen in larger implementations when multiple individuals are working on different subsets of business rules. The tried and true fix for this sort of thing is to follow object oriented code principles. A practical way to enforce this is to always have one developer oversee the architecture of the entire business rule development effort.
Diversity of Enterprise Platform Frameworks
The enterprise decisioning platforms available today, generally speaking, are extremely robust. They typically have a wide variety of ways to create an IF/THEN statement, predictive model and combination of the two. Developers should ensure that they embrace a wide variety of these components within the greater framework. All too often we see that the early developers may have not fully understood the entire toolset and thus struggled to develop elegant business rules. The point here is don’t develop three pages of business rules when they can be written another way in only one page.
These set of standards are so basic and fundamental they are applicable to virtually any set of strategies or tactics that require translation into business rules (decisioning logic). Though simple in concept, achieving these standards can be extremely challenging. That said, we’ll cover what skill sets we think are critical to a competent enterprise decisioning architect in a separate post…
