Not only it is a JVM workflow platform written in a lisp dialect, but it also strives to innovate how complex workflows are visualized and modeled. If a workflow has only a few steps/activities in it, it is anyone's game: pretty much any diagram visualizing such workflow looks sleek and man, if you draw it in BPMN it sure will look smart!
So yes, there is no denying that too verbose is sometimes good, and that BPMN sure has its wide area of use cases where it does its job just right.
There are clearly situations where too much of verbosity is a bad thing. One can even wonder and ask if the verbosity of BPEL and BPMN is inherent to verbosity of programming languages used by its creators?
But what about designing a platform that can cater for workflow graphs with n nodes and v vertices? Where n and v are any positive integers? Since titanoboa aims primarily at automated workflows (without human interaction) complex integration workflows are a typical use case. Reduced verbosity of functional (lispy) languages is definitely a paradigm that could help us here.
Lo and behold: a complex workflow: (To simulate a workflow of any arbitrary complexity, I tend to simply visualize an algorithm for nth Fibonacci number calculation (in this case it is the 7th). You can see that the workflow has ~70 steps in total and at one point it forks into 21 parallel threads.)
When dealing with workflow of tens or even hundreds of steps a space becomes an issue. Using existing standards of UML (activity diagram) and BPMN as a starting points, titanoboa tried to remove symbols and objects that are not truly necessary. It challenged some symbols to see if they would defend their place in workflow notation ecosystem or if any of them would become extinct through natural selection and could be either removed or combined. Here is how these symbols did:
In titanoboa's diagrams, every step can act as a decision. Simply attach multiple links (connectors) to one. Each link carries its own condition. Titanoboa's steps can all have return values which can be referenced in step's connectors. Any literal value will do. Wildcards are also an option - as are dynamic expressions. Also if you want to use gateways in titanoboa (and thus define more explicit, verbose workflows), you still can - simply add a separate step that will just serve as a gateway!
If parallel flow is enabled on a particular step, its all outbound connectors can be executed in parallel (denoted by dashed connectors' line). Condition can still be defined (to reflect Inclusive Gateway's behavior) and wildcards can be used (to cater for "Parallel Gateway" use case).
This one is a draw! Turns out we need joins, so even in titanoboa we have steps with
:supertype :join. Visually however these are still just normal steps as need to rendezvous is already implied by multiple inbound connectors. You can still use join icon to denote this of course, but you are free to change the icon to anything else if you see fit.
Also joins are steps like any other and can define a task that is executed right after a (successful) join.
For sake of being concise, titanoboa also does not require "End". The workflow simply ends when the workflow graph traversal is finished and there are no further nodes in the graph to process. As with gateways, you still can add step(s) that denote an end if you wish - but you don't have to!
So if you want - for instance when dealing with too complex workflows - you can design your workflows in less verbose, more concise way in titanoboa:
Read more about titanoboa's workflow design in our github wiki.