The visual interface for workflow definition is more hassle than benefit. The majority of such applications' complexity is not in the sequencing of operations but in state management, expressions, data manipulation, parameter passing, and retry policies. None of this is visible in the diagram. So engineers have to use UI/DSL to design the flow, but then implement most of the complex logic in non strongly typed code as parameter passing is usually using a map.

Temporal represents all the business logic in one place in the programming language of your choice. All parameter passing is strongly typed.

I see people advocating visual representation for workflows. But if it is so great for programming in general, why they don't advocate the same for systems programming, for example? Linux kernel in JSON/XML anyone?

I've heard of Camunda from reading this excellent article [1], but I havent' looked too deeply into it yet.

BPMN vs code is something we have considered. Our workflow engine works more like state machines as code, which is kind of the worst of both worlds. The business processes get fragmented into logic for each state, and mixed with imperative effects, so its neither easy to see the process nor maintain the code.

The nice thing about BPMN is that it's probably a bit more learnable by the subject matter experts who ultimately determine what the correct business process should be. However, having seen some pretty monstrous process flowcharts, my guess is that it probably doesn't scale past a certain level of process complexity. I suspect that workflow-as-code is ultimately the more scalable option.

[1] https://www.infoq.com/articles/events-workflow-automation/

Look at how Temporal represents workflows as code. It doesn't use any intermediate representation like DAG or state machine. It executes your code directly as a synchronous program with blocking operations taking as long as necessary to execute. For example the following code would be absolutely valid as a Temporal workflow:

    waitForApproval(purchase); 
    sleep(Duration.ofDays(30));
    sendEmail(email);

Yep. This is why I'm so interested in it!

Camunda is pretty nice and I have proposed it for projects, but it was shot down almost every time because 'BPM visual modelling is old-world' (it kind of says that on the homepage as well; 'modernize your legacy BPM systems'). We did a prototype for a big insurer in the UK and that went well, but covid+brexit killed the project altogether. It is nice to work with and to just toss it aside because of BPM modelling (and the charts belonging to them that make people from the industry who encountered them early 2000s cringe) is shortsighted (considering you can do everything in code). It is just that when people read the homepage, I guess from comments partners/clients made, it looks like going back 15+ years when you had fat java applet clients doing BPM and it always turning into a mess in the end.

It's interesting - I clearly never encountered them the first time around, and to be quite honest when I discovered them alongside Camunda I found them pretty refreshing.

+1 for Camunda.

I've used it for microservices orchestration previously and it works great.

I'm excited for Zeebe too but it's a bit immature atm.