In the computational space we know as software, there appears to be a growing trend to recognize and encode processes as workflows. These workflows can be business processes that require input from customer service or other personel, span several organizations and involve web service calls.
Due to the latency and often distributed nature of workflows, it is often not natural to express workflows directly as code. If a process can span days, weeks or perhaps even months, it does not naturally fit conventional programming models.
Therefore workflow models are invented. These are data structures that can be used to express workflow processes at a high level. Workflow activities delimit significant or meaningful work, e.g. “wait for quality control”, “send e-mail to customer” or “perform credit check”.
Workflows are coarse-grained algorithms; do this, do that, if this then that, and so on.
These differ from [conventional*] programs where the code is code, data is data and the two are distinct. With workflows, code is data. Workflow engines are virtual machines and workflow data models are meta-programming languages; I like to think of them as meta-programs and meta-machines; the abstraction level is “one up”; n+1. * In that sense, the perfect language to encode workflows would perhaps be Lisp, a language where all code is data and all data takes the same form.
This is an important fact! It means that we can think about workflows as programs and think of workflow models as programming languages and evaluate them as we would any other programming language.
I first encountered workflows in Navision, a business process platform. There is no real built-in workflow engine in Navision but one can create one; and several companies have done so.
The pervasive use of workflows is probably why Microsoft, who now owns Navision, has incorporated a workflow programming model, Windows Workflow Foundation (WF), into the .NET Framework.
One issue that faced me early on was the transactional nature of the workflow model. This meant that a long workflow could fail after many steps had been completed and comitted to the database. A nice solution to this problem is to do more validation up-front. This means creating an activity that does combined state validation before allowing the rest of the workflow to execute. It’s a simple measure but it is an imporant one. This approach can also be combined with design by contract style programming where “internal state” is checked for correctness up-front; it is assumed correct but if not, then fail early and often – in other words: fail fast.
The transactional nature of workflows also come into play in the sense of “point of no return” actions. If an e-mail has been sent to a customer we can’t “roll back”. There is no retroactive erasure for e-mails – we can’t unsend it. This makes up-front validation and sanity checking more important.
I’ve also come to realize that developing with workflows can benefit from unit tests. This again follows from the simple fact that unit tests benefit normal programs and these meta-programs can benefit from unit tests for precisely the same reasons. The unit tests may look somewhat different though. Perhaps the unit tests are even themselves workflows.
Many workflows are probably more difficult to test than regular programs because their effects often span several distributed systems but this only makes testing even more important.
The distributed nature of workflows is probably also why Microsoft emphasises the integration between Windows Workflow Foundation (WF) and Windows Communications Foundation (WCF). Services that use workflows are appropriately called Workflow Services. I look forward to possibly designing Workflow Services some time in the future.
I also really like the idea of a workflow designer where one can embed a workflow designer in an application and allow users to see a running workflow and even redesign a running workflow; a somewhat theoretical scenario but possible. Windows Workflow Foundation has such a designer. Appendix 1 shows a simple example of a workflow. The graphical nature of the designer makes it very intuitive and easy to see what’s going on.
The designer can be tailored so that users can only compose high-level activities and stay clear of low-level activities that could wreak havoc in the wrong hands.
This is a simple example of a nested workflow Sequence: