Al Hoang

John posted some of his thoughts on an article titled A brief history of workflow.

John Writes:

Maybe workflow history lies more into the “here is my recipe to sharpen sticks” or “here is my recipe to start a fire” (process/activity) and “hey, you, why don’t you sharpen sticks while we hunt, so that it’ll be easier for us to start a fire when we come back” (workflow).

I found John’s explanation brief and clear to understand about what workflow is about. However, I’m confused about what point history of a workflow is trying to make besides the author just blog brainstorming his understanding of workflow history.

While it might be an interesting academic exercise to trace the history. I think something more useful is to ponder on what it means for a software system to embody a set of steps a business organization makes to reach a goal.

Perhaps, this merely shows my utter ignorance about workflow engines (that I’m completely comfortable in admitting. Yes I’m clueless please make me ‘get it’) but from an outsider peering into the workflow engine community I’d feel the actual software artifacts of the workflow engine need to be documented in a more straightforward manner so people who don’t know ANYTHING about workflows can start to define, create, and excute workflows in a straightforward manner.

Perhaps some of the difficulties in going ‘aha’ on workflow engines and why they are necessary are:

1. At this point in time it’s just tough enough getting a working implementation
2. A software implementation of a rather abstract idea and trying to pin it down is not a trivial thing
3. To embody an abstract idea as a running piece of software, it is necessary to define terminology. WIth a name comes the power to be able to touch and manipulate it (for a programmer)
4. Enough example cases to sell that these engines are a decent bet

I believe for more widespread adoption of workflow engines it will be necessary to make it easier for people with very little understanding of the jargon, the theory, or even the nuts and bolts of these engines to be able to do something that provides a quick benefit to them. For now, many of these people will be programmers. So more concrete examples and explanations for many different scenarios (preferably a real scenario a programmer used to solve his/her problem) would far more helpful rather than histories or huge elaborate context stories that use Dilbert-management speak.

Be Sociable, Share!

• 
•