Navigation
  • The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
Saturday
Nov012014

By the book: How DMN is connected to BPMN

Throughout our new book 'the Microguide to Process and Decision Modeling in DMN and BPMN' we treat DMN as an integral notation for process modeling in BPMN. Even though decision model notation is a separate domain within the OMG, the DMN spec provides an explicit way to connect to processes in BPMN. DMN provides a schema model in XML format that includes two connection points. First, there is an explicit list that denotes the processes and tasks that use the decisions. Next, DMN provides an input and output data type that implicitly corresponds to the rule activity that invokes the knowledge bases of the decision.

In table 7 of the proposed Decision Model and Notation (DMN) Specification, the class model for the decision defines the BPMN processes and tasks that require the decision to be made (usingProcesses and usingTasks).

Appendix B of the DMN specification says:

“The interface to the decision service will consist of:

  • Input: a list of contexts, providing instances of all the Input Data required by the encapsulated decisions
  • Output: a context, providing (at least) the results of evaluating all the decisions in the minimal output set, using the provided instance data.

When the service is called, providing the input, it returns the output.

In its simplest form a decision service would always evaluate all decisions in the encapsulation set and return all the results.”

Here we are assuming that the decision is created by business rules from input processes and accessed through a decision service. Other decision can be manual or can require user input. The business rule task shape can denote the place within the process model that calls up a DMN model with the needed input and obtains the decision output.

As seen in the figure below, most DMN decision modelers utilize the rule shape to denote a connection to DMN. The inputs of a rule task are processed by the logic defined in the DMN model and then output for use in downstream gateways, participants, events and activities.

The customer is the input for the decision and the output is the customer discount. The process in the diagram can be made explicit according to the execution semantics. The figure shows the usage of the message shape. The association lines (dotted) are used to create the relationship between the message and the data type that is used in the process schema.  When decision for a customer discount is requested a customer message is sent to the decision service. This is an initiating message, so the envelope is white. After the decision is completed, the BRMS returns the customer discount. The message is shown as a non-initiating message with light shading.

To summarize: the DMN spec explicitly defines how a BPMN process is connected to the decision through the usingProcesses and usingTasks metadata for the decision shape. The input and output are attributes of the  decision and created by expressions and decision table. (more on that latter).

Thursday
Oct162014

New Book: The Microguide to Process and Decision Modeling in BPMN/DMN 

 

The Microguide to Process and Decision Modeling in BPMN/DMN is now available on Amazon.  A little bit about the book: the landscape of process modeling has evolved as have the best practices. The smartest companies are using decision modeling in combination with process modeling. The principle reason is that decisions and processes are discovered and managed in separate, yet, interrelated ways.

Decision Model and Notation (DMN) is an evolution of Business Process Model and Notation (BPMN) 2.0 into an even more powerful and capable tool set and the Microguide book covers both specifications. It also focuses on the best practices in decision and process modeling. A number of these best practices have emerged, creating robust, agile, and traceable solutions.  Decision management and decision modeling are critical, allowing for simpler, smarter, and more agile processes. 

A simple decision and gateway control of an execution path to respond to a purchasing decision.

As the figure above shows, the proper use of decision modeling uncovers critical issues that the process must address to comply with the decision. Decision-driven processes act on the directives of decision logic: decision outputs affect the sequence of things that happen, the paths taken, and who should perform the work. Processes provide critical input into decisions, including data for validation and identification of events or process-relevant conditions. The combination of process and decision modeling is a powerful one.

In most business processes, an operational decision is the controlling factor driving processes. This is powerful, as many governments and enterprises focus on minimizing the event response lag because there is often a financial benefit to faster responses. Straight-through processing and automated decision making, not just automated processes, is also emphasizing the importance of decisions in processes. Developing a decision model in DMN provides a detailed, standardized approach that precisely directs the process and creates a new level of traceability.

Decision modeling can therefore be considered an organizing principle for designing many business processes. Most process modeling in BPMN is accomplished by matching a use case, written or otherwise, with workflow patterns. Process modeling is critical to the creation of a robust and sustainable solution. Without decision modeling, however, such an approach can result in decision logic becoming a sequence of gateways and conditions such that the decision remains hidden and scattered among the process steps.

Without decision modeling, critical decisions, such as how to source a requisition when financial or counter-party risk is unacceptable, or what to offer a customer, are lost to the details of the process. When the time comes to change or improve a decision, a process model in BPMN alone might not meet the need. Providing a notation for modeling decisions separately from processes is the objective of DMN.

Saturday
Dec212013

Business Rules and Business Process Exceptions

Often a business process team will create a working prototype of a business process. These prototype might arrise from 'use-cases' or business cases.

This idealized process develops a deep understanding of the final version, yet much of the important work remains. You should even consider executing this development artifact in a test bed. Yet to complete a business process, the technical team should detail the process diagram with the necessary scheduling, exceptions and compensations. The purpose of the details is to erect a more complete process model. The business processes should act on all the messages, including the system failures. The process should handle every anticipated exception.

There are 3 types of exceptions may affect process execution:

 

  • Technical exceptions
  • Transient exceptions
  • Business exceptions

 

As we will see, business rules can create, named business exceptions. If the BPEL is transactional, the process should compensate for transactions that fail to complete. In compensation, the process cleans up or backs out records from ERP’s, operational datastores or data warehouses.

Often processes should be complete within a time period, so there could be time out actions noted on the diagram. Business processes usually receive a message and translate that message into yet another message for consumption by the next part of the process. BPMN is powerful for developing time-outs, exceptions and compensations. As seen in the BPMN fragment below, you can attach time-outs, exceptions and compensations directly to a subprocess task list. When time-outs, and exceptions occurs within the two process tasks, the BPEL traps these at the point of the subprocess.

 

 

 

 

In this scenario, a grant authorization system evaluates grants and records the data. The time-out BPMN (the clock) will raise a time-out exception and wait. The diagram reports any exception that occurs (the zigzag) to the exception task. The compensation takes care of a record in the grant database.

You can model BP’s with advanced abilities that suspend processing, or communicate with disconnected, mobile processes. They can add new technology such as RFID. These powers yield opportunities for the enterprise to fine-tune their most complicated practices. Yet to develop these capabilities you should understand how BPM tools use the three types of exceptions and what you must plan for when developing the production version of the process diagram.

A process diagram should use exception handlers to redirect the process flow in case a transient or business exception happens. However, no process can manage every exception. There are technical exceptions that will cause the entire process instance to suspend.

 

Technical Exceptions

Technical exceptions occur when the process causes the BPMS instance to fail. An internal server exception should be abnormal; however there are operational circumstances that cause these. Technical exceptions include

The common Java Null Pointer exceptions
Exceptions caused by Illegal Argument exceptions, (suppose an external operational system decides to change a field from 10 to 20 characters)

Server database exceptions, out of tablespace, violation of database constraints

These are outside and therefore invisible to the calling subprocess. Processes cannot handle them because the execution state of the process has stopped. When this technical exception happens, the current transaction is always marked for rollback. The process throws the exception to the scheduler or message router.

Transient exceptions

A transient exception is usually caused by code external to the server like database connections or connection pooling exceptions. Within the scope of the current transaction, a transient exception is visible and the process can catch it with an exception handler. If the exception is not handled in the scope of the current transaction, the subprocess marks the transaction for rollback and throws the exception to the scheduler or message router. The process is suspended.

The suspended process can be restarted and resume processing after the database connection or some other condition is restored.

Business Exception

A business exception is one that can be expected by the process. Examples of these exceptions include:

Exception raised by an activity, a specific, named exception is raised, for instance a business rule could raise a named exception.

Exception caused by receiving an error message (like an SOAP fault). 

 

If the exception is not handled in the scope of the current activity, the activity fails. When the activity defined a coordinated transaction, the transaction is committed. When no exception handling takes place Exception processing begins and leads to compensation and the failure of the process.

Business Rules Decisions and Business Exceptions

Many organizations use BRMS to validate and transform incoming transactions. Validations and transformation are important types of 'decisions' that a business process makes with the data within process flows.

This is a common decision pattern: evaluate a set or transactions, say from an incoming data set. Each record that fails the validation should be stored in an area for latter cleanup. You can either handle the validation directly, with values in the process flows or you can raise a business exception, create a reusable process for handling the exception and move on. Another common decision pattern validates user form input, in a workflow. Users might correctly complete a form and send it to a process flow. If there are business rules that violate complex data and business conditions, the process should collect data from the user at a latter date.

Figure 2 is an example of what I am describing. A decision service validates incoming data. If the data does not pass validation, the subprocess raises a named exception, otherwise the record is processed.

The basic idea is to design your exceptions, time-outs and compensations to enlarge the flexibility of the process and allow most process to continue unattended. Handle the process and move on.

 

Diagram complexity

The complete business process diagram has many important exception features that must be accommodated. Unfortunately, these additional boxes and notations make it difficult for business users to understand. It would be nice if BPM diagramming tools would permit users to disable display of exceptions, compensations and timers attached to subprocesses. The tasks following these should also not be displayed. This would clarify the core nature of the process and create a more useful business engineering tool.

Monday
Aug262013

Past, Present and Future of Business Rules (Redux)

It has been over 3 years since we released the white paper, the Past Present and Future of Business Rules. The paper has been widely distributed and we managed to generate many discussions, some of them were heated. My colleague, Christina Gruen suggested I update this and subsequently I have updated the paper and prepared a webinar. You can register for the webinar here:

To recap: the business rules approach (or operational decision management) BRA/ODM has principally evolved from three sources: Artificial Intelligence, Data Modeling, and Business Process Management. In the white paper, I explained the differences between the sequential logic approach and the inferencing approach adapted from expert systems.  I have experience with both and clearly my bias is towards sequential, graphical approaches. However, inferancing and functional programing is critical for developing decision analytics. Strict formalism in business requirements may sound desirable; yet it creates a lot of work of questionable value for the business analysts and the technician. Organizations are frequently ‘stuck’ in heavy; difficult to maintain environments in many large-scale business rules systems in finance and health care.

Having been involved with many of the standards and practices, I am hearing surprising rumblings that There are development on the horizon that I will be game changers. OMG’s decision model notation is becoming more prevalent, plus other efforts are poised to shift the industry.

Friday
May172013

Process Interactions in Orchestrations and Choreography  

We have common definitions for process, business rules, operational decisions, business events and other things that are important to process modeling. And, I have mentioned my favorite ones (here). But we frequently ignore one of the very important aspects of process modeling: interactions. Fingar and Smith mentions in ‘Business Process Management, the Third Wave' that an interaction is the use of process desktops that allows people or participants to interact with the process. This includes workflow emphasizing assignment, task management and form-based data entry.  So, interactions gave rise to the idea of task oriented process instances that are started by a form. We see this in today’s process monitor and task list in most BPM suites. A form is a completed interaction that spawns an instance. This was, arguably, a new concept in 2002.


The BPMN 2.0 specification (here) also delves into the concept of interactions. Section 10.1 says that a public process represents the interaction between a private business processes and another processes or participants. The interaction is the glue. In the specification, human interactions are a type of task with human involvement. Manual and human tasks have particular icons in BPMN that indicate that human involvement is required to complete the task. See the two figures below.

 

The Human Task &  Manual Task

Remember: a manual task is a task that is expected to be performed without the aid of any digitized business process. An example might be the nurse delivering medication to a patient. This is contrasted with a user task which is performed with the assistance of a software application or is scheduled through a task list manager. An example would be the approval of a request or deciding a proposition.

Interactions are critical to the concept of choreography. A key characteristic of choreography is that it is an activity representing an interaction between two parties rather than a unit of work. According to Dumas, "The Fundamentals of Business Process Management”, the interaction can be one-way, where a message is exchanged or two-way, where messages exchanged bring a return message. Each message has an initiator and a recipient. Indeed, the BPMN spec states that "choreographies formalize way business participants coordinate interactions. This gives rise to the 'conversation' shape center defined in the spec.

In Wikipedia the interaction is defined as ‘a kind of action that occurs as two or more objects have effects upon one another’. This is fundamental in the concept of the business process.