Decisioning systems need to fit in with existing processing systems.
There are five easy steps for deploying decisions using a combination of three core patterns – patterns suited for Legacy Systems, for Commercial Software Packages and for Modern Decision-Centric Systems respectively. This recipe allows for incremental changes that can be directed systematically for a powerful digital transformation.
Step 1- Pull Decisions out of Processes
Explicitly defined and managed decisions (a) simplify processes by abstracting the embedded business logic, and (b) allow knowledge to be injected into processes in the form of advanced analytical models and business rules.
Most systems are designed to automate tasks as a part of implementing processes and workflows. If a task requires some thinking or logic to decide a course of action, that logic is ‘programmed’ directly into that part of the programming. Thus ‘decisions’ got embedded into systems. This makes the process complex as it needs to accommodate all possible outcomes of decision-making. And every change in decision-making requires expensive reprogramming. Extracting decisions out from processes therefore significantly simplifies those processes. And in most cases a complete process redesign suggests itself.
Since decision making requires knowledge and information, decisions are the natural place to plug knowledge in. This formalized knowledge could be business rules or advanced analytics models or optimization algorithms. Thus decisions provide the ‘adapter’ for plugging knowledge into processes. Modeling decisions in parallel with modeling processes is key for this step.
Step 2- Design Decisions to plug into Processing Systems
Given that a system is a process implementation, and also given that we want to make those processes ‘smarter’, it follows that we need to ‘plug’ automated-decisions into these systems. This is where some of the modern technology comes to our aid. The Service Oriented Architecture (SOA) and its supporting technologies are now quite common in most technology infrastructures. Systems are designed to be able to ‘talk’ to agents within other systems through various channels and defined protocols.
The challenge now is to be prudent in how we carve out functionality so that each component is internally consistent but loosely coupled with other components. We should be able to assemble higher level components using lower level functionality.
Since decisions are essentially a question-answer pair, they can be placed in a component by itself that can be called by whichever component requires an answer to that question. This principle makes decisions an ideal fit for a componentized services oriented architecture.
Step 3- Automate Decision as a Decision Service
Automating operational decisions requires that a Decision Service be scoped, defined, designed and created.
What does an automated decision look like? Business friendly model at design time, and a piece of generated code at run-time. The design time model is a visual, graphical representation – generally enabled through a design tool. The run-time code is generally packaged as a ‘Service’. This is a stand-alone capsule of business logic that can answer questions from other systems.
Deploying an automated decision in practice means deploying a Decision Service. A decision service is an automated component that can be called remotely whenever a decision is required to be taken. Since decisions are required in almost all transactional processes and systems there are various options for deploying Decision Services. The componentized nature of a Decision Service allows significant flexibility in deploying decisions with minimal disruption.
Step 4- Pick the ‘Best’ Decision Deployment Pattern
Modern Business Systems need to be Decision-Centric – i.e. Reusable decision logic (Decision Service) has to be separate from processes. Decision Services are deployed in a combination of the following three patterns.
Pattern 1: No Decision Service – This is common to most legacy applications where decision logic is programmed very tightly within the application, with no easy mechanism for exposing this logic for reuse by external systems. Incorporating a Decision Service into this pattern is generally very difficult and requires major efforts and costs in significant rewrites.
Pattern 2: Embedded and tightly coupled Decision Service – This is common to most modern commercial software packages where decision logic embedded in a task is designed to be exposed for external consumption through a service or an API. This is a mixed blessing since the advantage of a mechanism for reusing decision logic is offset by the fact that decision logic is still tightly coupled with its application. Changes are not easy to make without thorough impact analysis and significant effort and costs in reprogramming.
Pattern 3: Independently Hosted Decision Service – This is the modern evolving pattern where there are no decision services embedded with the application, but are instead hosted externally on an independent hub. The ‘hub’ is logically centralized for design and maintenance purposes, but the actual Decision Service may be distributed physically across multiple instances. This common hub design allows maximum reuse, effective governance and streamlined access to required data services and knowledge services.
Step 5- Plan for Future Decision Deployment Upgrades
Is there a decision deployment pattern that is the ‘best’? Yes. The best pattern is whatever is best for your goals and your environment at a particular point in time. But if a design goal can be maintained given all the practical constraints, then that goal should be the Independently Hosted Decision Services. This pattern does not require centralized hosting for production Decision Services, but does require centralized design and maintenance.
Decisions are high change elements of any business operation. The decision making logic is updated frequently to respond to internal and external events. New information and updated knowledge is constantly arriving at the door. All these decision management components are either very clearly interdependent now, or may become related in important ways right away as the business environment changes by the minute. Therefore a centralized hub for designing and maintaining decisions is an appealing idea for competitive and agile environments. The roadmap for deploying decisions should point towards a centralized decision management hub, even though the physical deployments are decentralized.
Decision-Centric patterns position organizations in becoming naturally nimbler and systematically smarter.
