Work Journal for March 20th, 2014

Not sure what my mental block is this morning. The only thing that keeps popping up is my profound dislike for this product. It's a clumsy way of managing integrations that could just as easily be done with a proper programming language and a well tuned application server. I suppose the same could be said about WebSphere Message Broker, but that tied in to MQ so easily and so well that it simply seemed easier to use. Orchestrator just...bothers me. 

The second module is about including user interaction into workflows. In reality, that's just the business framing so as to teach the user control panel and how to compose some basic workflows. This seems to be the problem with this goal-oriented approach to teaching. You need to take this circuitous route to get to the actual information you need to teach. 

Maybe information is the problem. One of the pillars of Action Mapping is that you're not supposed to teach "what students need to know" but "what they need to do". So what is it they need to do here? 

So far, module one covered the product architecture and purpose, as well as introduce actor adapters. The only part that's not alluded to as of yet is, "How do I run these workflows once I have them written?" So really, the question comes down to invocation rather than user interaction. 

There are several ways that a workflow can be started. Usually, one sets up a rule (for a monitor adapter), a SOAP endpoint, or exposes the workflow in the user control panel. The latter is the easiest, since users just log in and start the workflows they need interactively. While I could cover the other invocation methods in the same module, they don't meet with the same business framing. We get back to information, rather than activity. 

So what does the student need to do here? That really depends on the workflows. This gets back to the problem that the product, as a development product, is versatile enough that the answer always comes back to "whatever the workflows you create do". This combined with the naturally circuitous way goal-oriented teaching does things makes the entire class into a hall of mirrors design wise. No wonder why this is causing me so much stress.

Usually, you run workflows from the user control panel fall into one of two camps: fully automatic, and those requiring user input. Fully automatic processes need to further input after being executed. The user control panel cannot handle workflows that require input parameters, so the workflow must run without any input whatsoever. 

And this is why the first slide, "use cases" is so hard. It doesn't tell the student any of this framing. It doesn't focus on what to do, only possibilities. It also comes across as all-encompassing making the selection of items difficult and uninteresting. The real question remains, "How do I run workflows once I create them?"