Moar Ted Plz! (p&p, day 3)

Started this out in the parking lot, but wow! it merits its own post after all.

Workflow workflow workflow workflow. Workflow patterns!

Interestingly enough, Ted uses a hypothetical higher ed approval process as his hypothetical test example.

W(t)F: look for "processes" in application code that users will want to control directly, or that will change over time. Long-running processes that happen in human space/time.

Instead of running around/telephone game for coders to implement and re-implement changing requirements, esp. around changing processes, give the "knowledge workers"/domain experts the tools to DIY. Not just the content, but the process/steps/sequence.

Activities: not branching and flow control, but domain-specific steps

Programmers build domain-specific activities (we focus on what we understand); domain experts string them together into processes (ditto)

We have to build activities so they're potentially useful across multiple workflows... sounds familiar

Decide early who's going to write the workflow; when in doubt, assume non-techs will do it.

Sequence workflow, state-machine workflow, open-ended processes, parallellism

Workflows with non-processing elements may never proceed to the next step (human actor hit by bus); need a timeout/recovery plan, don't leave a bunch of stuff locked & waiting, etc.

Workflows can persist themselves off anywhere and rehydrate anywhere, any time. Activities need to be decoupled accordingly. If done right, super-scalable, because can punt any of them to a new box any time.

Also "temporally decoupled"... take your Amazon.com order, capture it off, store it, apply its workflow to it somewhere else. Avoids lots of remote tripping, slashdotting, etc., because it doesn't matter what happens to the site. The workflow gets done eventually. If something went wrong, you get an email later.

Kudos to ps for catching Ted at the same thing I caught him at: "the IT guy" writes activities to enable the non-technical domain expert, "the secretary", to write processes "herself". Grrr. (This reminds me that in Peter's Agile Tragicomedy yesterday, the cast of characters consisted of a female PM, a female customer, three male developers and a male tester.)