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.

White Space in the Standards: Business Rules, Data and Process Modeling in BPMN

According to the Specification (here), BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope  for BPMN. Therefore, the following are out of the scope of the BPMN specification:

• Definition of organizational models and resources
• Modeling of functional breakdowns
• Data and information models
• Modeling of strategy
• Business rules models

Since these subjects are critical to Business Processes, the relationships BPMN is supposed to be evolving. We also know that operational decisions need data to decide, so at this point BPMN is incomplete with respect to creating executable business processes. An executable BPMN diagram might be more complex — it is inadequate to create an executable specification.

BPMN has a data shape, the data object. A data object is a rectangle with the upper right corner folded over, as shown here:

The text label for a data object can be found underneath the shape.  Often the current state of the data object is shown as an attribute shown in brackets under the text label.  As the diagram progresses, the state of the data object can easily be read, as displayed in the Figure below.

Figure: Use of data artifact shapes.

As with the text annotation, the association line attaches the data artifact to another shape. Data Class shapes can be associated with tasks, gateways, events, sequence lines, or message lines.  In message flow, data objects portray the “payload” or content of messages.  

The use of data objects is optional.  Some diagrams may concentrate on flow, while others show the complete details Data artifacts do not directly affect the sequence flow or message flows.  Data objects provide additional information, some of it reflected in the XML schema, without changing the basic behavior of the process.  For instance, the Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object. The data object can detail the metamodel’s XML particularly with a ‘callableElement’. Uses the following additional elements:

• ioSpecification,
• inputSet,  
• Data Input,

The data input and output are detailed in the purchase order approval example above. When a BPMN editor draws a Data Association to an Activity or Event it should generate this supporting invisible substructure.

As mentioned, the specifications are naive with respect to the origin mutation and alteration of data attributes. I've always maintained that this is the realm of business rules (mostly). That business rules through examination of data in order to decide Bolivian conditions controls specific aspects of operational decisions. Some of that data exploration includes analytics such as regressions, projections, and other techniques.

I believe the BPM industry needs to progress on standards with respect to business rules: the representation how they use things like Business Objects expressed in UM, and other expressions of the operational aspects of the business process. The BPMN specification pretty much admits weakness in this. So, even with the data input and output elements of BPMN, more needs to be done in order to specify a business process in a way that does not very important code aspects. The OMG spec on business rules (PRR) seems to be moving very slowly and it doesn't offer a clear connection to the process modeled by BPMN.

Introducing a new white paper: The Five Categories of Operational Decisions and their Impacts on Business Process Models

Business processes should enforce compliance to operational, legal and risk objectives. Yet how can one be assured that their processes are compliant? Increasingly, the best practices is to use a combination of business process modeling with a business rules approach- the operational decision (OD) approach. These frequently occurring, repeatable decisions are key to enforcing compliance.

A combination of BPM, OD and event processing can create comprehensive, agile solutions in many problem domains. In a new white paper from Bosch Software Innovations, we explain the role and interrelationships of these different visual modeling approaches. Most process modeling methods parse directly requirements into BPMN process elements. They incorporate with workflow patterns. There are alternate approaches that start with business rules and Bosch Software Innovations can support either. This white paper discusses how to develop processes requirements from a business rules perspective. Starting with this definition of a business process:

A business processes is an organized, coordinated flow of activities, conducted by participants, acting on and deciding with data, information, and knowledge, to achieve a business goal[1].

We can design a digitized business process based on business rules that describe the means of compliance, operational controls and risk mitigation[1]. So, from the perspective of the business process as per Ron Ross:

“A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or influence the behavior of the business.”[2]

The objective is the digitized process so the rules are expressed in executable, directed graphs and decision tables. When we design processes, we are defining the behavior of the business, so that processes comply with business rules by making operational decisions—a rules-compliant process.  

Operational decisions are frequently occurring, repeatable decisions that implement the compliance, operation and risk controls. They are settled with process data and evaluated by digitized business rules. So a business rule is an atomic logic step that uses data and knowledge to evaluate a part of a proposition about a process decision³.

 In a BPM/Business Rules approach, processes are activated by business events. Chandy and Schulte[3] define a business event as:

”A business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities.”

The differences between process, rules and business events are simple; rules are overarching, stateless directors of behavior, processes are stateful responders to the directives, and external business events, are detected and processed.

The recent research of Martijn Zoet, Richard Welke, et al found that business managers expect business rules to govern and control business operations with on five concepts:

1. Rules should influence, order or sequence a process’ tasks, decisions and internal events
2. Rules should influence and decide who is included in and assigned to a task
3. Rules should influence and decide what course of action is taken
4. Rules should influence and decide what data is retained, its validity, and duration and
5. Rules should detect, control, and respond to events

When they are dynamic or controlled in a BRMS, these five concepts are categories of operational decisions. Static elements become elements of a business process map or diagram—transitions, activities and gateways. We described five different ways that a decision’s outcome can direct the pathways of the process. As a nexus for governance, risk and regulatory compliance, the process decision is both an important management concept and a strategic design tool for achieving business objectives and goals.

Our new white paper clearly demonstrates how the 5 categories of decisions create processes that are compliant with the operational, compliance and risk management objectives. We lay out an effective design method that recognizes that process behavior considers decision-generated events. Also, from a single operational decision, events and data can trigger and control many aspects of a business processes.

The figure below depicts these 5 categories:

The Bosch Software Enterprise Platform provides a powerful design environment that simplifies management control of business processes. The result of separating processes from rules stabilizes business processes and permits operational decisions to change without having to change the process application. Understanding the five operational decision categories simplifies the choice of what should be a dynamic operational decisions supported by business rules and what should be a static part of the process. The white paper presents approaches for deciding what should be an operational decision (business rule) and what should be on the BPMN process diagram (gateways and conditions).

You can download the complete white paper here:

---

[1] Martijn Zoet, Richard Welke, et al, ‘Aligning Risk Management and Compliance Considerations with Business Process Development’, Springer-Verlag, Berlin Heidelberg 2009

[2]Business Rules Group, Defining Business Rules ~ What Are They Really?, www.businessrulesgroup.org

[3] K.Chandy, R. Schulte, Event Processing: Designing IT Systems for Agile Companies, McGraw-Hill Osborne Media, 2009

---

[1] The Microguide to Process Modeling in BPMN 2.0, Debevoise, Geneva and Welke, Advanced Component Research, 2010

Bosch Software Innovations Webinar Series

Bosch Software Innovations has made many changes over the past several years, plus our technology  provides platforms for many new Bosch products and services. If you would like to hear more about Bosch’s ‘Connected World’, we are holding a BPM and BRM webinar series. At these webinars, you can learn from Bosch’s technical experts with in-depth industry knowledge, best practices and relevant solutions.

During the first webinar “Comprehensive Round-Trip BPM and BRM System at Best-in-Class TCO”, we will describe the Bosch approach and thinking about the benefits of using BRM and BPM. There will be a live product demonstration of inubit and Visual Rules. The webinar will cover these topics:

• The integration of a inubit process and the Visual Rules engine
• How our customers manage their projects on an enterprise level using
• Our BPM and BRM methodology

 In order to register, please visit Bosch’s website: here

Do you have a process for business process management?

During business process modeling, a BPM technical/management team creates or tunes a business process model that supports the project’s objectives.  What are the mental processes of the team members modeling and developing business processes and connecting business events and rules? They use workshops and communication. They interview the best-performing and the worst-performing actors in the processes. They review financial reports, documentation and the notes of the managers of the current process. They identify triggering events, business rules and the process needs for policies. They design the proper flow control. They create pictorial representations.

There are institutional or traditional ways of gathering information about a process. However, few organizations know when it is time to add process thinking and business process management to formalize activities—there is no process to create new topics.

Legacy efforts create reams of paper, cabinets full of files, and databases overflowing with useful information—from management directives to marketing papers to MIS memorandums. Much important information exists here. Yet, business process modeling is different from knowledge management, quality reviews or even data modeling. The purpose of data modeling is to develop a model of what is. The purpose of business process modeling is to develop a model of what should be. Yet, how does an organization decide it is time to gather ad-hoc and undocumented activities and add the structure of business process management?

It is self-apparent to look at a factory production line and know that there is a process present; how do we discover the need for a process? Symptoms of missing process needs include:

• Poor business or financial performance in a rapid, surprised way
• Low morale and high employee turnover
• Management overwhelm, (many decisions, little data)
• Poor communications

There are other symptoms; however, deciding and clarifying when to create a process can liberate these conditions and improve business results. A well designed process has these characteristics

• Clear goals
• Well defined roles
• Improved clarity
• Increased visibility

We have identified a series of steps to deciding and delineating a ‘green fields’ or occult process in the enterprise business process framework.