Microsoft has one. I think it's called Workflow Foundation (WF).
Here's my summary of what workflow software is:
Workflow software lets you specify a
sequence of tasks that must be
done to complete some process. The sequence may have logical branches
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:
Discharge a Solider from the Military, with steps including
Make sure his pay is up-to-date;
Sign the non-disclosure agreement;
& Collect his gun.
(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.
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.
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).
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.
Some steps might operate in parallel.
Some steps might have a high rate of failure & require retries.
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:
# 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.
# 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 &
# We can let him to the medical exam later, on his own time.
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?
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).
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.
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.
Unimaginative young programmers couldn't figure out how to do it
with simple scripts.