Digital sovereignty also means being able to design and further develop one’s own IT architecture independently over the long term. The interaction between CIB seven, an open workflow engine based on Camunda 7, and the A12 AI Low Code Platform from mgm technology partners.
What matters here is not only which applications are used, but also how their technical components interact and how independently they can be operated. Since June 2025, mgm CIB has been using seven within the A12 platform. This integration illustrates how a standalone process engine can be integrated into an existing platform architecture without sacrificing its independence.
Why Choosing the Right Workflow Engine Is Important
The A12 AI Low-Code Platform takes a model-driven approach: Applications and processes are described using models, and the platform provides the technical foundation for their implementation. The models include, among others:
- Data Models
- Document Models
- User Interface Models
- Rule Models
- Workflow Models
The choice fell on CIB seven, the open-source successor to Camunda 7, available under the Apache 2.0 license, making it an obvious alternative to Camunda 7. This allows mgm to build on a familiar technological foundation while benefiting from the engine’s ongoing development.
A key advantage of the change was that the existing code could continue to be used without modification. Therefore, it was not necessary to make adjustments to the existing code to replace the workflow engine. This demonstrates that it is possible to carry out technological modernization without having to develop solutions from scratch that have already proven their effectiveness.
Two components, clearly defined roles
The collaboration between A12 and CIB seven is based on a clear division of responsibilities. A12 provides the platform for the model-based development of applications and processes. CIB seven handles the execution of the workflows defined within it.
The workflow engine remains a standalone component. It can be used within the A12 platform, but it can also be operated independently of it. This separation provides flexibility in designing the IT architecture and allows both the platform and the workflow engine to be further developed according to specific requirements.
Several factors were decisive for mgm:
Reuse Existing Processes
Existing process models can generally be retained, provided they are compatible with the engine being used.
Design Components Independently
The platform and workflow engine remain technically separate components.
Organize Operations Flexibly
The architecture supports a variety of infrastructure and deployment scenarios.
Rely on open standards
Modeled processes and decision rules can be documented in a traceable manner and more easily transferred to other technical environments.
The architecture thus provides room for further development without tying the entire platform to a single technical component.
From Digital Applications to Automated Administrative Processes
A typical administrative scenario illustrates how this interaction might work in practice: A citizen submits an application digitally. First, the system checks whether all required fields have been filled out and whether the entries comply with the required formats. Such checks and other business rules can be modeled using A12’s model-driven approach.
The Business Process Model and Notation (BPMN) describes process flow. This internationally recognized standard lets you represent business processes graphically. For example, it shows which steps occur in sequence, which tasks are pending, and at which points decisions are made.
The technical decision rules can also be modeled using Decision Model and Notation (DMN). This standard is suitable, for example, for clearly mapping the criteria for approving or rejecting an application.
CIB seven executes the modeled workflow. Other components can then handle tasks such as creating and sending the notification. This results in a seamless digital process in which each component fulfills a clearly defined function.
The more of these steps that can be automated, the less manual intervention is required. Ideally, suitable processes can be handled entirely automatically, from application entry to the issuance of a decision. This form of processing is referred to as “dark processing.”
Preserving Process Knowledge, Advancing Technology
The benefits of open process automation go beyond the replacement of a single component. Process models and decision rules capture the domain expertise that has been built up over the years. They document how an organization operates, what rules apply, and how decisions are made.
When processes are modeled based on open standards such as BPMN 2.0 and DMN, this knowledge remains structured and traceable. This facilitates reuse when technical conditions change. While transferability in individual cases depends on the technology and functions used, open standards provide an important foundation for this.
This is particularly relevant for government agencies and organizations with long-term digitization projects when it comes to process automation. Platforms are modernized, technical components are replaced, and new requirements are integrated. If the business models are preserved throughout this process, there is no need to start from scratch with every technological change.
This allows companies to protect their existing investments while also tapping into new technical possibilities.
Integrating AI into Model-Based Processes
Conclusion: Openness creates room for maneuver
The integration of A12 and CIB seven demonstrates how a model-driven platform can be combined with a standalone open-source workflow engine. The clear separation of components makes it possible to reuse existing processes, design operations flexibly, and further develop the technological foundation in a targeted manner.
Digital sovereignty does not arise from a single technology, but rather from the ability to make architectural decisions independently and to adapt systems to new requirements over the long term. Open standards, independent components, and reusable process models provide an important foundation for this.
Frequently asked questions
Yes. CIB seven remains a standalone component and can be used within the A12 platform or operated independently of it.
Sovereignty in process automation means being able to make architectural decisions independently and adapt systems to new requirements over the long term without being dependent on a single vendor or a proprietary licensing model. Open standards such as BPMN and DMN, as well as a permissive open-source license such as Apache 2.0—under which CIB seven is licensed—provide the technical foundation for this.
