Topic: wftk -- Usage scenarios

wftk home ] [ discussion ]
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

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.]

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.