We're software developers new to BPMN and Kogito. We'd like to encourage adoption of Kogito, but we're struggling to understand how best to get started and what the SDLC looks like operationally, so I'm hoping to reconcile our plan against established community practice.
The main draw for us is BPMN itself — the diagram gives developers, BAs, and stakeholders a shared visual they can use to role-play workflows together. Our ambition is to let BAs, and in some cases stakeholders directly, frame a process in BPMN without being experts. We're betting that common sense plus a little AI assistance is enough for them to rough out a process that a BPMN/Java developer can then enrich with integrations and scripts.
The problem we're trying to solve is that we want to avoid a benign-looking change by a BA or stakeholder turning into a catastrophic one for the developer — for example, deleting and redrawing flows or flow objects that look visually identical to what was there before, but leave the underlying logic disconnected. I'd like to protect developers from rounds of avoidable Q&A caused by that kind of change. We've roughed out an approach internally using a two-repo model (an "A" model repo and a "B" implementation repo) to keep code and scripts out of the BAs' hands. Given how long and established jBPM/Kogito have been, I wanted to ask the community whether there are resources or established patterns we should be reading before we commit to our own design.
The change-management flow we're picturing is that:
I'm hoping to benefit from the lessons you've learned, and the references you've read to learned from when designing your SDLC around your BPMN processes.
Questions: