Modern enterprise automation requires separating complex business logic from direct process flows to ensure operational flexibility. When rules change more frequently than the process structure itself, traditional development approaches quickly reach their limits. Hardcoded checks scattered across microservices or monolithic systems turn any optimization attempt into a lengthy project involving developers. Practice shows that without a clear separation of responsibility between different types of logic, enterprise systems quickly accumulate technical debt, and real business processes degrade into unmanaged shadow routes.
Why classic BPMN becomes overloaded: the problem of hardcoding business rules
The BPMN 2.0 standard has become the de facto industry benchmark, allowing a single model to serve simultaneously as documentation and an executable process definition. However, architects often make a fundamental mistake: they attempt to map every branch, condition, and scoring rule directly onto the process diagram using gateways. This leads to the emergence of "spaghetti workflows," where the actual business flow is lost among hundreds of arrows and blocks.
Mixing decision-making logic (such as tariff calculations or approval limits) with sequence logic makes BPMN models overly heavy. Attempting to change even a single rule requires modifying the entire diagram and re-testing. In practice, only about 13% of organizations are able to painlessly update complex business rules in real-time without performing a full code release. The rest face rigid processes that cannot keep up with changes. As a result, employees begin to bypass the system, creating shadow processes outside the automated perimeter.
The OMG standards triad: distributing responsibilities between BPMN, CMMN, and DMN
To overcome the problem of diagram overload, the Object Management Group (OMG) offers a complementary triad of standards. Distributing responsibility between them allows for building a clean, scalable architecture:
- BPMN (Business Process Model and Notation): Focuses on predictable and structured processes. Its task is workflow orchestration, where the sequence is clearly defined in advance. BPMN 2.0.2 is published as the international standard ISO/IEC 19510:2013, establishing it as a universal language between business and IT.
- DMN (Decision Model and Notation): Specializes in decision-making logic. DMN allows extracting rules, formulas, and selection matrices from application code or BPMN diagrams into manageable decision tables, simplifying updates without the need to redesign the entire process.
- CMMN (Case Management Model and Notation): Designed for dynamic cases where the sequence of steps depends on events and context (e.g., incident investigations or audits). It is important to note that modeling here does not replace human judgment but rather structures the information space for the expert (case manager) who acts according to the situation.
DMN in practice: moving decisions from code to tables
Using DMN radically simplifies BPMN models. Instead of a cascade of gateways, a single Business Rule Task is used, which calls the DMN engine. Context data is provided as input, and a decision is generated as output.
In the credit application processing workflow, using DMN allows for managing scoring rules separately from the workflow. Instead of modeling dozens of branches, the architect creates a DMN table using FEEL (Friendly Enough Expression Language) expressions, which are understandable to business experts. When risk policies change, the business simply updates the decision table, leaving the application routing process untouched.
Process Mining as a lie detector: identifying shadow processes through event logs
Even a perfectly designed process may be executed differently in reality. Process Mining technology uses event logs from information systems to reveal how processes are actually performed. Analyzing these logs exposes bottlenecks and deviations from the architect's original design.
For example, in a typical invoice approval process, Process Mining tools can reveal that up to 49% of transactions may pass through "shadow" routes, bypassing standard controls. This data becomes the basis for re-engineering: overly rigid checks are replaced with flexible DMN tables, and unstructured deviations are brought under CMMN management.
The Scriptum architectural approach: designing flexible workflows without technical debt
Implementing such a comprehensive approach requires the right toolkit. The low-code platform Scriptum (developed by Scriptum, a company within the Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges) ensures a clear separation of logic through native support for BPMN and DMN standards. Scriptum uses a process engine for task orchestration, providing real-time visibility into the status of every individual process instance.
The solution is built on the UnityBase platform, a joint development of companies within the Intecracy Group (where InBase is a key, but not the only, developer). Utilizing the mechanisms of the UnityBase platform gives the system enterprise-grade advantages:
- Unified domain metadata: Ensures a holistic description of data, UI, generated API, and access policies.
- Security and audit: Support for RBAC and RLS (Row-Level Security) mechanisms, as well as detailed audit trails of user actions, meet strict enterprise-level requirements.
- High performance: Thanks to an asynchronous architecture and reliable database access, the platform easily handles significant loads during the execution of complex orchestration processes.
Applying the BPMN/CMMN/DMN triad in combination with a reliable technological foundation eliminates hardcoded business logic and makes enterprise systems truly adaptive to change.
| Criterion | BPMN 2.0 | DMN 1.x | CMMN 1.1 |
|---|---|---|---|
| Scenario | Clearly defined, sequential processes (e.g., contract approval) | Complex decision-making logic, tariffs, scoring, limits | Loosely structured cases, situational work (e.g., incident investigations) |
| Managed by | Business analysts and developers | Business experts (no programming required) | Case managers, operators |
| Result | Executable process diagram | Decision tables and FEEL expressions | Dynamic set of tasks depending on context |
FAQ
What is the difference between BPMN and DMN and why shouldn't they be mixed in one diagram?
BPMN describes the sequence of steps (workflow), while DMN describes decision-making logic (the rules determining the result). Mixing logic overloads BPMN diagrams with gateways and complicates updates. DMN allows moving complex rules into decision tables, keeping the process clean.
How does the BPMN 2.0 standard help bridge the gap between analytics and development?
According to the ISO/IEC 19510:2013 standard, BPMN 2.0 allows a single model to serve as both business-friendly documentation and an executable process definition. This means process engines can execute the diagram directly, eliminating the need to write code from scratch.
How can Process Mining be used to find deviations from a designed BPMN model?
Process Mining uses event logs from corporate information systems to visualize how processes are actually performed. This helps objectively identify bottlenecks, redundant steps, and "shadow" routes that differ from the original design.