A centralized decision engine and decision service, what a fabulous idea! Imagine calling a “written only once” decision service from any checkpoint in your enterprise. Besides the maintenance savings, a centralized decision service will provide consistency is decision-making, a Holy Grail for business owners.
What is a centralized decision service?
As an oversimplification, we can draw a box in the IT architecture blueprint and label it “centralized decision service” (deployment) or “centralized decision engine” (execution). Et voila!
Architecture is rarely that simple though. There are at least two components to consider and what is “centralized” or “universal” is not necessarily universally understood.
Imagine a business where Joe is codifying a new batch of regulations for 2013 in an order entry system, Susan is repeating the same logic in a fulfillment process system, and Tom is doing the same thing in the billing system. The business will end up with a lot of time wasted managing multiple versions of the same batch of regulations. With multiple versions, the business is more likely to have errors and inconsistencies in the logic.
Centralized Decision Management
Centralized decision management is clearly the main objective.
Regardless of the systems that will consume the captured decision logic, the business can realize major savings in the maintenance of this logic. Imagine instead that Joe writes the logic once, and that logic is used in order entry, fulfillment, and billing. The business would be able to free up Susan and Tom’s time and remove any chances of inconsistency. Or, they might team up and complete the work in a third of the time!
The business can leverage decision management technologies to isolate the capture of logic from the code that will execute in the end. By doing so, the business can store and manage business rules in a centralized repository. Even if the team is spread out all around the world, they can collaborate on crafting the decision logic, writing business rules, and testing to ensure decision outcome match expectations.
Centralized Decision Deployment
Centralized decision deployment is a little more subtle.
The business wants the decision logic to execute in all those disparate systems: order entry, fulfillment, and billing. 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 not, 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.
In reality though, it is rare that businesses can afford to re-engineer all of your systems to fit in the same architecture (a 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. The order entry system could be J2EE-based but the billing system could be in .NET. Getting your inter-compatibility right may cause more headaches than you have an 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.
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