The business workflow is rare to be changed after the implementation.
Versioning is not required.
BPMN is not a must-have. Since business stakeholders just need working software. What we need is only align requirements with stakeholders. And we have many methods for that.
Business workflow optimization is not required.
Monitoring & operations may be needed but we can also get the data from persistence and implement it.
I found in this scenario, we cannot find a strong reason to use Camunda. On the contrary, BPMN may become a burden for the whole development team. Because we have to consider how to deploy and maintain the XML files. And the developers have to adapt to the new way of working with the workflow engine.
Actually, I pretty like the concept of Camunda which designed as a lightweight framework. But every framework increase the constraints for developers. And the business workflow normally existing at the core domain of business logic. I’m not sure how to evaluate the benefits and loss if we import Camunda into our project.
Camunda saves you a lot of time in coding complex state transitions and async behavior. These things come out of the box with camunda and you wouldn’t need to code them yourself. Things like timer events, state persistence, error handling and automatic retry mechanisms. These are just a few that come to mind, but coding from scratch would take quite a while and wouldn’t be as solid as the features camunda has created.
“Things like timer events, state persistence, error handling and automatic retry mechanisms.”
These features are easy to find the replace solutions which are working as libraries rather than a framework. The benefit of using a library rather than a framework is that the development team own more flexibility and the control of the code.
I think you should pick a project and create 2 PoCs one with the engine and one without, then you’d be able to see a more concrete example of how your specific use case can be helped.