I've been working through some usage scenarios to get a handle on what wftk should really do, what it should be good for.
As I started each one, I realized that it opened up yet another can of worms, bringing me to this conclusion:
Undaunted, I slogged further. What follows is an annotated list of my usage scenarios. Each links to a full presentation
of the scenario with lots of musings and thoughts on workflow.
If you're reading this page in the first place, then you're interested in workflow. At the moment (1/18/00), this project is wide
open. I need all the help I can get -- please give me whatever feedback on these you think might make sense. My email?
Heck, use wftk@vivtek.com .
Here they are:
- Chair purchase
This and the next scenario were the original scenarios in the original RFP.
And strangely, it was the most straightforward. Just go look at it. No deep thoughts on this one.
- Trade show organization
Things started to get a little fuzzy on this one. Rather than really write down a full list of the things to do to organize
a trade show, I truncated it. But whereas the initiation of the chair purchase lies with the employee who wanted the chair,
after which that employee is pretty much a spectator, this one includes a case worker who initiates and then
coordinates the rest of the project. The question arose: is the assignment of roles properly formalized in the process
class? The trade show case was also interesting in that I realized the need for deliverables expected from each
task, and maybe from the process as a whole.
- Open-source software project management
This description is a little misleading, maybe. In my mind, open-source projects are typified by their small granularity.
A bug or enhancement is proposed, a change request made, analysis done, change made, change released. That's the whole
"project" -- or at least, that's the process I choose to model with this scenario. But oops. What happens if two requests
describe the same work? Processes must merge? What happens when one request embodies two changes? (Maybe the requester
is naive and describes two literal changes in one form submission, for instance. But maybe it's just more convenient
to represent a complex change request as two changes.) Should the process fork? I think both questions get a yes
answer. What do you think?
- Closed-source software project management
To me, a closed-source release consists of many changes rolled into one project. The project management aspect is quite
complex because now we have an analyst, a manager, multiple developers... Wait! A project plan?!? Yes, this
scenario includes the generation of a project plan which is then executed as a subprocess. At design time we have no
idea what that process is.
- E-commerce purchase
One of the things I do is host e-commerce services using software I developed myself. This software, of course, implements
a workflow system -- but in a very hardcoded manner. I will probably redevelop the whole thing using this "real" workflow as
soon as it works. So I modelled my retail purchase workflow as well. The surprise in this one was that some parts of the
workflow are iterative. A single order contains multiple line items, each of which may be fulfilled individually. So some
parts of the workflow are repeated until there are no line items left. Seems every scenario introduces some more things that
a reasonable system should be able to handle, right? Maybe I should write more than seven.
- SourceXchange project
If you missed this part, this project originated in a SourceXchange RFP. As the
sXc business model is rather interesting and somewhat complicated, it seemed an interesting thing to model, and sure
enough, it brought yet another insight -- in the case where an arbitrary subprocess is included in a process, then the
actions taken when a subtask is completed may themselves be complex. Ooh. My head's hurting! What do I mean by that
mumbo-jumbo? To be specific, when a milestone is completed in a SourceXchange project, (and note that each project is
different, each has its own unique set of milestones), then an approval process is initiated, culminating in either rework
or acceptance. If accepted, payment is due for the milestone. Thus each task node in the project is itself an abstraction
of a complete parametrized process! Goodness, meta levels flying right and left.
- One for the road: simple to-do list
Just so you see that workflow doesn't have to be difficult, I wrote up a little to-do list manager.
[Some deep thoughts may be inserted at this point later.]
|