I work for a large, federated organization, in which individual teams can choose their own tooling.
Further, the engineering teams often see themselves as overworked, so want assurances that they will not be aversely affected before changing their workflows.
I’ve seen the Forrester Total Economic Impact study, which has a few quotes.
Hi @ColinR ,
Can you explain a little more about what kind of things you’re trying to avoid as part of the overworking problem?
Which things in particular are you trying to minimize?
At present - with these tools being very new to us - the concerns are general:
will engineering teams need to learn to use new tools?
will Camunda orchestration make ‘more work’ for them?
My understanding is that orchestration can take place invisibly: the individual teams need only interact with the processes via APIs, which can continue to use existing tooling (e.g. Jira tickets…).
However, I want to check this with teams who have actually been through this transition.
You’re correct in that engineering teams that are responsible for building/maintaining the business logic of your process don’t need to know too much about what’s going on with the orchestrator. They just need to use the API to register their service and respond back with the result.
But there’s also the question of who’s responsible for building the processes and workflows that will orchestrate the services. These usually need to implemented by someone with software engineering experience and would require knowledge on BPMN, FEEL and DMN (optional). These are the open standards we use for process design and execution. There are a lot of resources out there to learn these standards including ones created by us..
Can you explain a little bit about the current system you’re working with? Then i can maybe try to offer some comparision.
That’s probably enough for me to try to leap our next hurdles: I can offer assurances that ‘task devs’ don’t need to do anything differently, once they’ve got APIs set up.