The modern corporate IT landscape is gradually moving away from the concept of static business process descriptions. The primary challenge for enterprise system architects has become the gap between documented regulations and actual operational activities. When business rules are hard-coded or exist only as paper instructions, "shadow processes" emerge. These are situations where actual task execution routes deviate from regulations due to the inflexibility of automation systems.
Why static process diagrams no longer work: the challenge of shadow routes
The traditional approach to automation involved a long cycle: business analysts create diagrams in graphical editors, after which developers manually translate them into programming code. This model creates difficulties with every change in business regulations, requiring a full development and testing cycle.
Due to the complexity of modifying systems, users may find workarounds, creating informal communication chains. These shadow routes make company activities opaque to management, and rigid automation logic prevents rapid adaptation to changing business rules. The solution to this problem lies in transitioning to executable models, where the diagram serves as a direct algorithm for a specialized process engine.
Executable BPMN 2.0 standard: turning diagrams into working algorithms
The transition to executable models relies on the BPMN 2.0 (Business Process Model and Notation) standard. According to the Object Management Group (OMG), version BPMN 2.0.2 is officially published as the international standard ISO/IEC 19510:2013. Its architectural value lies in the fact that it defines both graphical elements for process visualization and an XML schema (execution semantics) for their direct orchestration.
This allows for the use of a single model simultaneously for business documentation and process management in a runtime environment. BPMN 2.0-based process orchestration ensures a single source of truth (the model matches the code), allows for transparent monitoring of task execution stages, and standardizes calls to external systems via Service Tasks.
Separating logic from flow: the role of DMN in reducing change costs
One common problem is overloading the BPMN process diagram with numerous branches describing complex decision-making rules. To prevent the diagram from becoming an unreadable labyrinth of conditions, the DMN (Decision Model and Notation) standard is applied.
DMN allows for the separation of business rules from the direct process flow in the form of specialized decision tables. Instead of building dozens of conditions in BPMN, the engine queries the DMN table, passes input data, and receives a result. For example, changing credit scoring rules can be implemented in a DMN table without the need to redesign and restart the entire base BPMN process. This narrows the scope of changes required when updating business regulations and minimizes the risk of introducing errors into the overall orchestration logic.
Analyzing the real state: how Process Mining identifies bottlenecks via event logs
To understand how processes actually work, the Process Mining methodology is used. It is based on the analysis of event logs generated by various corporate information systems. Analyzing these logs helps reconstruct actual operational flows and compare them with target models.
Process Mining provides a data-driven approach to prioritizing automation efforts. Analysis reveals exactly where bottlenecks occur. A real-world example of this technology is the detection of an undocumented "shadow" step in the contract approval process, which systematically delays deal execution. Eliminating such discrepancies ensures that actual work complies with approved regulations.
Comparative analysis of architectural approaches: Scriptum, Camunda, Bonita, and UiPath
Different BPM platforms have their own architectural focuses, so their selection depends on an organization's key needs. Below is a comparative matrix of the four systems' approaches.
| Comparison criterion | Camunda | Scriptum (on UnityBase) | Bonita | UiPath |
|---|---|---|---|---|
| Primary focus | Microservices orchestration and system integration | Rapid low-code process and document automation | Building user-centric applications | Routine operation robotization (RPA) and UI automation |
| Standard support | Full BPMN 2.0 and DMN support | Full support for executable BPMN/DMN models | BPMN 2.0 support, limited DMN | Proprietary workflow schemes, focus on robot action sequences |
| Base technology | Java / Spring Boot | JS / UnityBase (high-performance native stack) | Java | .NET / Windows-oriented infrastructure |
| Optimal scenario | Complex transactional IT landscapes | Enterprise workflow, ECM, high-load processes | Self-service portals with custom UI | Integration with legacy systems without APIs via user interface |
Camunda is focused on orchestrating distributed systems and microservices, providing a reliable engine for developers working with complex transactional flows in the Java ecosystem.
Scriptum is a low-code platform (a product from the Intecracy Group technological alliance). It uses BPM capabilities for process automation and is built on the UnityBase platform (a joint development by Intecracy Group companies, where InBase is a key, but not the only, developer). Utilizing UnityBase platform mechanisms, such as a unified Domain metadata model, automatic REST API generation, and built-in access control tools (RBAC, RLS, audit trail), allows for the optimization of creating and maintaining corporate systems. Specifically, the Scriptum architecture supports integration with ECM systems, such as Megapolis.DocNet, based on a shared technological foundation.
Bonita is oriented toward developing process solutions where the user interface and the creation of custom web interfaces for self-service portals play a primary role.
UiPath specializes in robotic process automation (RPA). Its main task is the automation of routine operations by interacting with the graphical interface of legacy systems that lack open APIs for direct backend integration.
How to design a flexible BPM architecture without vendor lock-in
To minimize technological dependence and increase flexibility, architects should follow several basic approaches:
- Focus on open standards: using BPMN 2.0 and DMN ensures that process logic is preserved in a readable and portable format.
- Separation of architectural layers: decoupling the user interface, process orchestration (BPMN), business rules (DMN), and the data storage layer.
- Combined integration: using API-oriented orchestration for modern microservices and targeted RPA for legacy systems without software interfaces.
Adhering to these principles guarantees enterprise agility when scaling the business or changing regulatory requirements.
FAQ
What is the difference between BPMN 2.0 and DMN, and how do they work together?
BPMN 2.0 defines flow logic: the sequence of steps, events, and routes in a process. DMN defines decision-making logic (business rules). Together, they allow complex rules to be moved into separate DMN tables, which the BPMN process calls at the appropriate stage, simplifying changes without rewriting the process diagram.
How does Process Mining help identify shadow processes in a company?
The technology analyzes event logs generated during corporate system operations and builds an actual map of process execution. This allows for data-driven identification of real bottlenecks, delays, and undocumented workarounds.
What are the advantages of using UnityBase as the foundation for the Scriptum BPM platform?
The UnityBase platform provides a high-performance technological layer for data management: a unified Domain metadata model, REST API generation, DBMS-independent file storage (BLOB/file stores), and built-in security mechanisms (RBAC, RLS, audit trail) for enterprise deployment.