What for workflow software

by Gene Michael Stover

created Tuesday, 2013-07-23 T 03:35:50Z
updated Tuesday, 2013-07-23 T 03:35:50Z

I'm reading about Workflow Software.

Here's my summary of what workflow software is:

  1. Workflow software lets you specify a sequence of tasks that must be done to complete some process. The sequence may have logical branches (IF/ELSE stuff).
  2. In practice, the process is probably a business process. The example that everyone uses is Order Fulfillment. (Really, everyone uses that same damned example.) Here are some examples that arise from my attempt to apply some imagination:
    1. Discharge a Solider from the Military, with steps including Make sure his pay is up-to-date; Sign the non-disclosure agreement; Medical examination; & Collect his gun.
    2. (For a defense lawyer) Prepare My Client for First Day in Court: Tell him how to dress; Tell him what to expect; Tell him things he must not do or say; & Go over his story one more time.
    3. Get the Family Ready to Leave in the Morning: It might have steps for each family member, such as brushing teeth, showering, dressing, collecting school books, taking out the garbage. Many of them can be done in parallel or out of order.
    4. Complete the Permits for My New Restaurant (When I Don't Know How to Do It Already): Might start with a single Contact the City Government & Ask What I Do. The results of that might include a list of forms, & where to get them, & my workflow would either append steps to itself or create another workflow. I assume that each form wold become at least three steps (obtain it, complete it, submit it). Many of the forms might be completable independant of each other (in any order, in parallel).
  3. Some steps in the process might require human activity. For example, a manger might need to sign a purchase order. Or a shipping center employee might need to get a product from the shelves & put it in a box so we can ship it.
  4. Some steps might operate in parallel.
  5. Some steps might have a high rate of failure & require retries.
  6. Some steps might take a long time to do (hours, days).

Wikipedia points out that you can implement workflow software with a general purpose programming language. In other words, my workflow software could be this pseudo-shell script:

#! /bin/sh
# Assume that command line argument 1 is the name of a file
# that contains all input required for the workflow.
# For brevity, assume that a failed step ends this script
# with a decent error message.
VerifyInputs $FILE
# Notice that we can verify that his pay is up-to-date &
# have him sign the non-disclosure papers in parallel (order
# doesn't matter).  However, we can't have him sign the
# actual discharge papers until he's done all the others.
# And notice that unix shell lets us do that easily.
SignNonDisclosureAgreement $FILE &
EnsurePayIsUpToDate $FILE &
SignDischargePapers $FILE
# We can let him to the medical exam later, on his own time.
MedicalCheckup $FILE

A programmer might point out that many of the steps in a workflow are implemented with web services, but in my example, I've used programs that are local to my unix system. Well, any of those programs could easily be a simple, local program that forwards the request to a web service. They could lookup things in the database. They could alter the file. They could retry if necessary. And if there are a lot of steps &/or some of them take a long time (even days), it still works; you just start the script for each input file; your scripts can run in parallel.

If a step requires human action, then the local program can print a message, such as "Tell Joe to go get an Uber Toy from shelf 123, put it in a box (size 456), tape it up, & take it to the shipping office". And if Joe isn't sitting in front of the computer that's running the script, then your FetchProductFromShelvesAndPutInBox local program can lookup the warehouse, lookup the employee name, lookup the name of the computer that Joe checks, & ask a web service on that computer to print the message for Joe. Point is that with local programs, you can have steps that require human action, & you can do it even if the humans aren't looking at your local computer's screen.

I maintain that you could implement workflow software with local programs, usually so simple that we would call them scripts.

When you look at generic workflow products, they aren't bad, but they sure are more complicated than scripts. So why do they exist?

  1. Wikipedia points out that domain experts & programming experts are rarely the same people. Generic workflow software can help the domain experts create the workflow logic graphically (or in other ways that don't require as much programming knowlege).
  2. If you use a local script, & if the workflow takes a long time, then there's an increased chance that the script can crash or the computer can reboot. Generic workflow software can remember its place on secondary storage so this isn't an issue. Yes, you could do it with a local script, but you'd have to write the code for it. Said code might be non-trivial enough that it's worth writing just once in the generic workflow softtware.
  3. Generic workflow software can know how to retry steps that have a high failure likelihood. As with the previous point, you can do this in a script, but you have to write the code for it.
  4. Unimaginative young programmers couldn't figure out how to do it with simple scripts.


...sequence of tasks...
A sequence of tasks? With conditionals? Sounds like a program to me.
...create the workflow logic graphically...
So general purpose workflow software might be the killer app for the visual programming languages that appeared in the late 1980s?