Decision services may or may not be linked to business process activities. Looking only at a business process approach / modeling to find decision services, will limit the scope of potential dramatic improvement. The majority of decision services deployed in SOA are not directly linked to any business process. Since at least 10 years, the main drivers for BRMS deployment are at the service implementation level, where agility are needed, when change to the business logic are frequent and are driven by business. All those projects shown that a top down approach, by starting from the business process, should not be considered every time as the way to go! Analyzing existing business service operations can lead to quickly identify decision operations that you may want to modernize using rule engine technology.
When doing a business process modeling effort, business process analyst can identify activities within the process definition which participating in decisions. Most of the time those decisions are taken by human, or some piece of software supporting the business logic. At this stage of process discovery, the agile business rule development methodology recommends naming those activities: ‘decision points’. Decision points are points of variability and decision in a business process which group together all potential business rules that determine decisions. A decision service is the implementation of one to many decision points. Most of the time it will be a one to one mapping, but a decision service can include multiple decision points, when, for example, the data model to process such decisions is the same, and the activities in the process are sequential therefore may be grouped in one activity. For example for a claim processing ‘Validate claim’ and ‘Verify coverage’ are decision points which may be mapped to one unique decision service, as once the claim is valid the process goes directly to verifying the coverage:
Decision points in a business process definition
To identify decision point, we need to look at the activity description within a process definition or at the step description within a use case when a use case approach is used to define application requirements. Most of the time it is obvious to find such service by searching for action and mental thinking verbs, ‘decisioning’ words like decide, assess, validate, and choose. Typical decision points are, loan illegibility, underwrite insurance policy, verify plan, review application, compute price, validate claim… It is important to note that a BPMN gateway within a business process diagram is not a decision service. It is control flow branching mechanism to route the sequence flow within a process. Most of the time, the outcome of a decision service may be used as input to decision gateway or input to an OR gateway.
When doing process modeling the discussion with the subject matter experts should lead to understand the scope of the decision, are we talking about lest than 10 rules or more than that? Does the information model is complete at this stage of the process? For example to validate a claim we may need to look at the insurance policy, and the historical records attach to the claim, like medical invoices. The process carries minimum information, like the policy number, plus a set of data elements it may have gathered in the different coaches executed so far.
Finally decision services are not a group of rules within the process definition used to route the flow of execution of the process. Those rules are defined as ‘process routing’ rules, they are taking local routing decision, but do not represent a service. There are just group of rules. Most of the time, the number of process routing rules is very limited, few rules are defined and they work at the process variables level. No rich data model, no complex decision, no reuse by other application, no external life cycle.
During the business process discovery and analysis activities, it is possible to represent the decision service with color code within the process map in IBM Blueworks Live. This is important to identify each decision point as the project plan has to include all the tasks for rules discovery, analysis and implementation, in a separate work stream from the business process implementation activities. Finally once identified it is important to understand where the current business rules are defined, who is triggering the change to the rules, who process the change, who own and define the logic.