White Space in the Standards: Business Rules, Data and Process Modeling in BPMN
Blog: Process Modeling 2.0
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.
Leave a Comment
You must be logged in to post a comment.
