Revisiting workflows: BPMN is dead. Long live the Functional Programming!

Titanoboa is like a bull in a china shop. Wait, actually it is more like a giant snake in a china shop: it may break few things. (Unless it is cold in there, because you know, it's cold-blooded.)

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: How to Visualize Large Complex Workflows?

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.)

Remove what's not necessary

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:

Round 1: Titanoboa vs. Decisions

Symbol	Standard	Team	Vital Functions	Status
Exclusive Gateway	BPMN	Gateway		KIA
Decision	UML	Activity		Expendable
Tasklet	-	Titanoboa		Alive

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!

Round 2: Titanoboa vs. Parallel Gateways

Symbol	Standard	Team	Vital Functions	Status
Parallel Gateway	BPMN	Gateway		Deceased
Inclusive Gateway	BPMN	Gateway		Missing
Fork	UML	Activity		K.O.
Tasklet	-	Titanoboa		Alive

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).

Round 3: Titanoboa vs. Join

Symbol	Standard	Team	Vital Functions	Status
Join	UML	Activity		Survived
Join	-	Titanoboa		Survived

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.

Round 4: Titanoboa vs. End

Symbol	Standard	Team	Vital Functions	Status
End	BPMN	Event Type		Missing

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!

Summary

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:

BPMN	Titanoboa

Read more about titanoboa's workflow design in our github wiki.