What a fabulous idea: having a centralized decision service! For any checkpoint in the enterprise, you could hit a written-once decision service. Beyond the maintenance savings, consistency is a Holy Grail that appeals to business owners.
What is a centralized decision service?
As an oversimplification, we draw a box in the architecture blueprint: “decision service” or “decision engine”. Et voila!
Architecture is rarely that simple though… There are at least two components to consider and what is “universal” is not necessarily ‘universally understood’.
Centralized Management
This is clearly the main objective.
If Joe is codifying the new batch of regulations for 2013 in the order entry system, and Susan is repeating the same logic in the fulfillment process, and Tom is doing the same thing in the billing system, we end up with a lot of waste of time on one end, and higher odds of errors / inconsistencies. Regardless of the systems that will consume the capture decision logic, the biggest savings are in the maintenance of this logic. If we write it only once then we can free up Susan and Tom’s time, and remove any chances of inconsistency. Or they might team up and do the work in a third of the time!
Decision management technologies are used to isolate the capture of the logic from the code that will execute in the end, allowing the business rules to be stored and managed in a centralized repository. The team might be spread out all around the world, collaborating on the crafting of the decision logic, writing business rules and testing that the decision outcome matches expectations.
Centralized Deployment
This is a little more subtle.
We want the decision logic to execute in all those disparate systems: order entry, fulfillment process and billing system in our previous example. And I saw many blueprints that drew a link from each one of those systems to an actual deployed decision service. The links could have been loose bindings, but, more often than none, they were API calls in the J2EE fabric or .NET infrastructure. Each system could get the same decisions made consistently by running the exact same piece of code for all of them.
Order Entry ——->
Fulfillment ———> Universal Decision Engine
Billing ————–>
In reality though, it is rare that businesses can afford to re-engineer all of your systems to fit in the same architecture. Beautiful greenfield project… But rare.
So how do businesses take advantage of centralized decisions? They simply deploy the rules in the mode that is the most appropriate for the consuming applications. It might mean that the same rules end up in different execution components. Maybe your order entry is J2EE-based but your billing system is .NET. Getting your inter-compatibility right may be more headache than you have appetite for. The main driver is often performance: in order for your systems to run efficiently, you might need to balance the execution in local modules. They may be part of the fabric, and load-balanced by your infrastructure, or not.
Order Entry ——->
Fulfillment ———> Enterprise Fabric ——-> Universal Decision Repository
Billing ————–>
A little irony
This is where it gets odd. In our terminology, we think and we speak of a centralized decision service, which is technically a deployment thing… but we really mean a management thing…
Learn more about Decision management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
