Paweł Bujak is the President of Datapolis and chief architect of Datapolis workflow solutions
The following observations are the result of several years of the conceptual work on a platform for business process management known as Datapolis Workbox (later upgraded to Datapolis Process System). The very process of creating a working product from scratch, basing only on one’s own thoughts and ideas, is itself worth recording. Now however I would rather like to share the ideas which defined the shape of the product and which still evolve in a surprisingly innovative way.
Part One: State Machine Workflows vs Sequential Workflows
The development of Datapolis workflow platform started in July 2007 with a simple proof of concept for a graphical tool defining SharePoint-based workflows. I invited over a dozen people – almost all our development team – to that task. As Windows Workflow Foundation includes two possible types of workflows, sequential and state machine ones, I asked the team which one we should choose. The great majority favored the sequential engine. In spite of that I insisted to go with the state machine one. Developers – very intelligent and capable people – resisted that approach, which really confused me. State machine workflows appeared to me as more elegant, readable and able to model complex processes in an easier way. I understood the opposition to that perspective only after few years and hundreds of conversations with guests of our booth at various SharePoint conferences. To explain it I will first describe the difference lying in ideas behind state machine and sequential workflow.
The idea of a sequential workflow is not hard to explain. It says that a workflow should be defined step by step: from A to B, then conditionally: if condition X is met, to C, if it isn’t, to D, etc. In that aspect the notation of a sequential workflow is similar to a cooking recipe: you need to write down every single activity in a precise order. Adding a graphical designer, frankly speaking, does not improve the readability of such a process. You can see all the activities one after another, loops, branches, etc. but the meaning of the process is often hard to grasp.
State Machine Workflows
In place of a cooking recipe state machine workflows have more in common with a game. There may be no single determined path of a process. Instead you have the beginning and the end, some stages in the middle, and plenty of connections in between. The road followed by a workflow does not matter. What matters is that you could move a workflow from the beginning through various process stages until the end. The graphic diagram of such a workflow looks like a game board. You need to look at it just once to understand its complexity and logic.
Why The Programmers Love Sequential Workflows?
As I wrote before, I was confused when my team did not want to adapt the tool to use state machine workflows. The resistance was fierce. There were arguments every few weeks in the row. Conceptual meetings usually ended with slamming doors and for the next hours the tension was too high that we could even speak to one another.
A piece of advice by the way. If you develop something new, do not fear heated debates and disagreements (just make sure the conflicts would be on topic, not personal). With that approach you will kill a few birds with one stone. Your product will be better, your team will bond stronger (people will appreciate a constructive criticism, if it is not ad personam) and the engagement in the project will be higher.
Few hot weeks later my vision prevailed and we started developing a tool for modeling state machine workflows. We called it Datapolis Workbox, as when I looked at the workflow diagram, I imagined workflow states as pieces of work locked in small boxes.
Finally I have realised the programmers’ way of thinking is very… well, programmatic. For them a sequential workflow is just another program, structurally and logically similar to thousands of functions and procedures they wrote in their lives. In that mindset the dominion of “ifs”, “elses” and “loops” is an absolutely straight and natural order of things.
When I however visited various conferences and talked with Workbox users, usually no IT staff but chiefly business analysts, I have always – I repeat, ALWAYS – met with their understanding and approval. State-machine workflows are easy to interpret. State-machine workflows are simple. State-machine workflows are excellent in modeling the process logic.
Now, after almost eight years of developing Datapolis Workbox and currently Datapolis Process System, you can wake our developers in the middle of the night and ask which workflows work better. They will explain you – and they will be absolutely honest about that – why state machine workflows are superior to sequential ones 😉
To be continued