A CTO’s Perspective: How Decisions Integrate with Processes
cheryl wilson 270003VHSH email@example.com | | Tags:  business-process-manageme... bpm decision-management process-improvement brms business-rules
0 Comments | 4,192 Visits
Note from Good Decision! editor: This is the first of what will become a series of CTO posts addressing some of the frequently asked questions around business process and decision management. Thank you to Eric Herness, IBM Distinguished Engineer, BPM and Decision Management CTO, for his first post in this series.
As the CTO of IBM’s BPM and ODM software products, I get asked a lot of questions about how to effectively leverage the power of both BPM and ODM, synergistically, when building out solutions. The good news: There are generally answers to these questions.
Let’s start with a look at how decisions are integrated in with processes. I find that from a BPM perspective, processes are made more robust and more resilient when rules are integrated into the process at strategic places. Basic process design suggests that tasks in business processes implemented by services provide an element of agility which can be beneficial. Beyond this basic SOA principle, the next level of process design often involves placement of decisions in the process. And the most common place to find decisions is often in front of or just before a Business Process Modeling and Notation (BPMN) gateway – a gateway controls flow in a process.
Here’s an example of a rule that is calculating a result which will be used in the BPMN gateway in a healthcare admissions application, starting with the ‘before’ picture of a process fragment from IBM BPM as shown here:
The BPMN gateway definition before the design is changed to include the utilization of a decision service and looks like this (click on the image to make it larger):
There are two problems with the implementation of this decision:
In this scenario, the entire process application must be changed and put into production when any part of the decision changes. This may not be an issue for an application used by a small group but if this is a business-critical application, there will no doubt be an entire certification process in place before a new application version reaches production. While this amounts to thorough and complete governance, it slows the reaction time of the business.
Now let’s add a decision service to the process flow.
The decision service Score patient can use Business Activity Language (or BAL) when defining how a given decision is made. Think of BAL as a way to naturally describe decisions that occur in business. In this example we’ve re-implemented the decision gateway as a series of BAL rules as shown shown here:
By converting the decision gateway into BAL
and running the rules on
IBM Operational Decision Manager, we’ve created a much more human-readable
service which also shows the impact of each decision to the line of business
and addresses the first pain point of decisions by turning the technical
implementation into real business logic. We can take this even further by inspecting
the new gateway. (Click on the image to make it larger.)
In this new gateway we can view the direct impact of a “TooFewPlatelets” setting: Immediately readmit the patient.
An added side benefit of using a separate decision service, especially an IBM Operational Decision Manager decision service, is that there’s a separate life cycle for the rules. This means changes to the rule or process can be done independently. So, going back to our sample process, if new research shows patients with a platelet count less than 450 should be readmitted to the hospital, you can change the business rule, do your testing, and push the rule into production without touching the business process.
Finally, if other processes or applications also need to make the same calculation, the rule is now easily reused by those other consumers.
In future posts, we'll look at additional patterns where mixing process and rules benefits the resiliency and robustness of the overall solution design.