Why is OCBC modeling language needed

Techniques for business process modeling (e.g., BPMN diagrams, Workflow nets, EPCs, or UML activity diagrams) tend to suffer from two main problems:

– It is difficult to model interactions between process instances, which are in fact typically considered in isolation. Concepts like lanes, pools, and message flows in conventional languages like BPMN aim to address this. However, within each (sub)process still a single instance is modeled in isolation.

– It is also difficult to model the data-perspective and control-flow perspective in a unified and integrated manner. Data objects can be modeled, but the more powerful constructs present in Entity Relationship (ER) models and UML class models cannot be expressed well in process models. For example, cardinality constraints in the data model must influence behavior, but this is not reflected at all in today’s process models.

Because of these problems there is a mismatch between process models and the data in (and functionality supported by) real enterprise systems from vendors such as SAP (S/4HANA), Microsoft (Dynamics 365), Oracle (E-Business Suite), and Salesforce (CRM). These systems are also known as Enterprise Resource Planning (ERP) and/or Customer Relationship Management (CRM) systems and support business functions related to sales, procurement, production, accounting, etc. These systems may contain hundreds, if not thousands, of tables with information about customers, orders, deliveries, etc. For example, SAP has tens of thousands of tables. Also Hospital Information Systems (HIS) and Product Lifecycle Management (PLM) systems have information about many different entities scattered over a surprising number of database tables. Even though a clear process instance notion is missing in such systems, mainstream business process modeling notations can only describe the lifecycle of one type of process instance at a time. The disconnect between process models and the actual processes and systems becomes clear when applying process mining using data from enterprise systems.

What is OCBC modeling language

Object-Centric Behavioral Constraint (OCBC) modeling language is a novel language that combines ideas from declarative, constraint-based languages like Declare, and from data/object modeling techniques (ER, UML, or ORM). Cardinality constrains are used as a unifying mechanism to tackle data and behavioral dependencies, as well as their interplay. In other words, it extends data models with a behavioral perspective. Data models can easily deal with many-to-many and one-to-many relationships. This is exploited to create process models that can also model complex interactions between different types of instances. Classical multiple-instance problems are circumvented by using the data model for event correlation. The declarative nature of the proposed language makes it possible to model behavioral constraints over activities like cardinality constraints in data models. The resulting object-centric behavioral constraint model is able to describe processes involving interacting instances and complex data dependencies. This model can be then used for conformance checking, i.e., diagnosing deviations between observed behavior (i.e., an event log) and modeled behavior (OCBC model) for compliance, auditing, or risk analysis. Unlike existing approaches, instances are not considered in isolation and cardinality constraints in the data/object model are taken into account. Hence, problems that would have remained undetected earlier, can now be detected.

OCBC Technique Suite