Identify decision service

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.

Jerome

Leave a comment

Filed under Uncategorized

Decision service buzz

A decision service is a service operation taking decisions, and in the context of this article, implemented using business rule engine technology. There a recent tendency to use the term decision service everywhere even on unrelated product features use such term. This may not help to adopt best practices for decision service design and implementation and may confuse the users. Another tendency is to use some features blindly, short cutting the design and considerations of what decision service needs to be in SOA, forgotten the years of SOA practices. This article does not pretend to solve all the problems, but at least should help to design and implement such services in the context of sustainable architecture.

The use of business rule engine technology to support the implementation of decision service, brings transparency and encapsulation of the business logic within the service. It is possible to change this logic very often and without redeploying a business process, or any business application. Using WebSphere Operational Decision Management (also known as ILOG Jrules), business analysts are able to maintain the rules themselves.

The life cycle of such logic is very different from a workflow (BPD in IBM BPM 7.5.1) or a service orchestration (BPEL or mediation flow in WESB). It is possible to change the business rules on a daily basis, which is not thinkable for a business process definition, or a reusable service. As a business service, decision service should promote reuse for any consumers, and not only one, for example, a business process.

One basic example of decision service, is data validation, where business requirements constraints the data. The decision is to log issue, or/ and reject the business transaction. In a claim processing the “validate claim’, or “adjudicate claim” are examples of such decision service. Approving a loan, an insurance policy, assessing a fraud are decision services. Externalized from the core application logic, decision service is a service provider, consumable by a business process application but also by any other applications. Rule processing is data oriented, and process a large scope of data elements to take decision, where a BPM product is flow oriented, and carrying minimum information. The two technologies are orthogonal. Tendencies to group the two technologies into the same product do not help, and confuse the industry.    We will start some posts to present the design considerations and the implementation best practices using WebSphere Operational Decision Management (WODM). IT Architects and developers have to address questions such as:

  • How do I identify decision service?
  • What kind of decisions the business is taking?
  • How do design the decision service?
  • What are the object model needs for the rule processing?
  • Should I design my service from the business process, using a top down approach?
  • Does my ruleset signature is my service?
  • Where the data are coming from?
  • What is the frontier of my service definition?

Also using product features blindly, developers may go to dramatic implementation, with poor performance, poor maintainability, or quick and dirty solution.

Jerome

Leave a comment

Filed under Uncategorized

WebSphere Operational Decision Manager 7.5

A new release of JRules just came out. Sadly the name changed, for Operational Decision Management. The components are also renamed, it may be to do not confuse the new product manager, who is also responsible of IBM BPM. Therefore Rule Studio is now Rule Designer, and Rule Team Server is named Decision Center, RES new name is Decision Server. The following diagram illustrates the new components.

The big change in this release,   is the event filtering rules as part of the product. The Event Designer is an eclipse plugin, as Rule Designer is. It is a port of WBE development environment into eclipse and the filters are also managed within the decision center. This is very important to have one platform to govern all the authoring and deployment of rules and filters.

There is a lot of buzz around decision management, it is time to say bye to BRMS acronym. Business rules are becoming decision now!. Which sometime make senses but a lot of use cases for BR are outside of decisioning: product configuration, filtering elements, mapping data elements… Obviously as decision can be broadly applied to any piece of software: taking the decision of mapping data elements, taking decision of configuring the product, taking the decision of schedule the airplane crew… Even when I develop a dojo front end, I can code decision in javascript…
Adding the term operational to the business rules makes sense , as WODM is designed to manage only business rules aimed for execution.
We will write a post on filtering syntax and pattern.
Jerome

2 Comments

Filed under Uncategorized

Data model for the claim processing sample

In chapter 4, we address the rule discovery and analysis activities of ABRD. This is an important step of a business rule application implementation. The example is a claim processing application. In the insurance industry, this business process is one of the most complex to implement. We do not pretend to give you a real claim processing application. But the data model is complex enough, so we can implement rich business rules, and also we can address the problem of the integration with a BPM product (in a future post).

On pages 104 and 111, we present a set of facts about the data model, which was derived from discussions with the claim adjudicator and claim processor experts. Recall that the development of the  data model for the rule is coming by analysis the terms expressed in the rule declaration, and by analyzing the business terms used by the business.

The rule discovery and analysis outcomes are:

  • a conceptual data model
  • a glossary of term
  • a rule description document
  • a recommendation on where to implement the rules

For the conceptual data model we use basic UML class diagrams, representing the business entities at scope and their inter-relationships. The diagrams are used to communicate with the business team, and to help them understanding the navigation between elements of the model. This is important as this conceptual data model is future building the vocabulary to express the business rules in the BRMS. In term of tooling, any UML diagram editor should work.

The conceptual data model evolves over time, when we progress on the rule discovery and analysis. It is a tool for the business, but in parallel a developer can develop a logical data model which will be used to test the rules. This model is developed by applying object oriented design practices. This model will be used at the execution level, as we like to call it, Rule Business Object Model, or RBO. There are two approaches to develop this model, one is using UML and generates code, the other is to start from the java code, mostly java beans, and then generate UML class diagram. Those diagrams are used for communication between the different project stakeholders. Most of the time I prefer the second way, as I can test the data model, and immediately figure out what behavioral, factory  methods I need to add to the model. This is important as we need such method to simplify the rule writing.

The following ClaimProcessing-rbo is a zip file you can download to get the rbo java project which includes the data model used as JRules xom. Use ant to build the jar for the model. Before doing so, you need to download  ClaimProcessing-parent which is a parent project used to set common ant script, repository of jars, and properties file. This parent project is used by all the other projects.

Import those two projects in Rule Studio, and create a bom project. We will describe the BOM project in a separate post.

Jerome

1 Comment

Filed under Uncategorized

Welcome to the agilebrdevelopment.wordpress.com, the companion web site to “Agile Business Rule Development”, the book!

This page is an entry point to a myriad of resources to complement the information contained in the ABRD book, by Jérôme Boyer, and Hafedh Mili.

You may also use this page to provide us with feedback on the book, or to ask questions.

Happy browsing!

2 Comments

Filed under Uncategorized