thinairviews of various geekage from 1,655 meters (5,430 feet) above sea level

Sarah's uncle has written a book about his experience in Vietnam as a bombadeer/navigator. I mentioned him a couple years ago in Veteran's Day, POW communication systems, and Warfare

Update: I didn't he had a web site. Welcome Intruder by Captain Robert E. Cleary

He will be speaking at the Cherry Creek Tattered Cover tonight at 7:30pm.

From the Tattered Cover announcement

Vietnam Veteran Robert Cleary will read from and sign Welcome Intruder: Stories From the Logbook of a Marine Naval Flight Officer ($37.50 Robert Cleary). Historically rich with letters, photos, and papers that may now be called the remnants of war, this book serves to highlight the truths about Cleary's Marine Squadron's particular contributions to the war. These stories weave a rich tapestry and serve as the collective memory of multiple events and ultimately of the bond shared by men who lost the final remnants of their boyhood in a country far from home.

If you live in the Denver Metro Area and are interested, maybe I'll see you there. Tattered Cover hours and locations

Google knows where you can find a map to the Tattered Cover in Cherry Creek

The advantage of living in a representative democracy is that you get to choose political leaders without bloodshed. See, in non-democratic governments you can only change things by revolution.

In this particular democracy, we also get to demonstrate and to speak out against the government. (Many nations forbid one or both.)

Speak up. Vote.

These are the only powers given to you by the Constitution. If you don't vote and you don't voice your opinion you are abandoning the only legal powers you have over the government and you are surrendering to the tyranny of the special interests and political extremists.

You don't have to be smart to vote. You don't have to have read every news story to vote. You don't have to have a degree to vote. You don't have to own land to vote. You just have to be a citizen of this country. So vote according to the best that you can put together of your guts and your heart and your mind. Sure it would be great if everyone would educate themselves about all of the issues and make the most informed decisions possible, but not everyone will. It would be unforgivably elitist to suggest that only the most informed voters should vote, like suggesting that only white men who own land should vote -- we have come farther than that, thank you very much.

Vote.

Just in case you happen to still be undecided...

Why I'm voting against the current administration:

• Iraq: immanent threats, and WMDs.

• Simple economics: it's unforgivably irresponsible, even devious, to cut taxes with one hand while increasing spending with the other.

Why I'm voting for Kerry:

• Combat experience: each presidential candidate is rich white man who claims to be the tougher warrior. I'd prefer Kerry who has actually seen combat up close and personal.

Iraq:

The rationale leading up to the war emphasized 1) immanent threats, 2) weapons of mass destruction, and 3) associations between Iraq and the attacks on the World Trade Center and the Pentagon. What immanent threat? What WMDs? And what link between 9/11 and Iraq? On all three of those points, the administration has been proved wrong. Iraqi military presented no appreciable resistance to the US invasion. So much for an immanent threat. No weapons of mass destruction have been found. Even Rumsfeld himself has been quoted saying no hard evidence links Saddam and Bin Laden

Our Commander in Chief invaded another country without provocation. Never before in my lifetime has the United States initiated military action without provocation. The rationale justifying that action has come up completely empty. What's worse, explosives documented by the International Atomic Energy Agency have disappeared into the fog of war. The stated purpose of the invasion was to secure Iraq's weapons. They failed.

They got the rationale completely wrong and now we learn that they also failed to secure key components of the Iraqi weapons programs that actually existed. Completely inexcusable.

Simple economics:

The present administration would have you believe you can have your cake and eat it too. Instead of tax and spend it's tax-cut and spend. It's burning the candle at both ends. They're talking out of both sides of their mouth. Dealing from both sides of the deck. How many cliches can I come up with to say that you can't have it both ways?

Moreover, it is completely immoral that the mostly poor citizens who volunteered for the military are sent to kill and die in the Middle East while big business and the super rich enjoy the biggest tax breaks in recent memory. While poor families pray for the lives of their sons and daughters, the administration "supports our troops" by cutting taxes for the wealthy and powerful.

Combat experience:

I dislike this campaign's theme: my warrior is tougher than your warrior. The rhetoric of the "war on terror" is all wrong. Sadly, we are in fact picking a warrior to lead us in the misguided "war on terror." The incumbent is the son of a rich white man who took a cushy ride through the Vietnam War. Kerry is another rich white man who volunteered for combat in the Vietnam War. Leopards don't change their spots. Bush thinks he's got the courage. Kerry actually does.

Terrorism is a form of guerrilla warfare, something which Kerry has seen in person. I would prefer Kerry to be in the Oval Office making the choices that involve sending young Americans to kill or be killed in asymmetric combat. He knows what that kind of combat looks like up close and personal.

State Machines part twelve

Two interesting business process workflow articles to add to the discussion. First from last May which I've only now gotten round to posting, and second from last week.

If you're interested enough to have stuck with this long series of posts about state machines and workflow, you would probably also enjoy a good survey of business workflow by Tom Baeyens on TheServerSide.

A topic that certainly deserves to be included in an introduction about workflow is the relation between workflow and business process management (BPM). The term workflow is used to denote a series of related interactions between people and a computer system. Workflow is more often heard in developer communities. Sometimes, the meaning of workflow is restricted to the different screens of a user interface. Business process management (BPM) has a broader scope. Where workflow is more often used in a technical context, BPM has a broader scope. It implies also the non-technical issues like analysis, organizational impact, from the viewpoint of a manager.

First I start with explaining what workflow management systems are. Then, the advantages of business process management are covered. Next is an explanation of why the workflow market looks confusing at first sight. The main conclusion will be that selecting a workflow management system is the hardest task companies have to face. To give you a solid basis for this task, the core section of this article defines the four layers of a process definition. It describes the common workflow & BPM concepts in a neutral language. At the end, a guided tour along the specs and tools is added.

It provides a fairly thorough introduction to business process workflow and provides plenty of links for further reading and various commercial and open source workflow engines.

Last week Sean McGrath published an article in IT World about visualizing business processes -- some problems map well to workflow and some don't. It's really a gem to add to my workflow collection, but the URL looks a little dodgy. So I'll paraphrase some and quote the juicy bits to protect from potential link rot.

Sean uses a soda vending machine for his example. There are two business problems. First, there's the actual mechanics of the soda machine -- insert a coin, choose a product, and dispence the product. It maps quite well to a state machine. It's only slightly more complex than Bob Martin's example of a turnstyle. The second business problem is capturing the logic involved in picking the optimal container size for bulk orders.

The second use case smacks of math, ... of an algorithm, of control logic, of decision trees, of flowcharts. To illustrate, imagine that the process of determining the optimal container size required looking for the biggest number that divides two order sizes evenly. The algorithm for this was worked out by Euclid

Compute highest common factor of A and B
Let R = A modulus B
repeat:
                If R is zero, stop
                Set A to the value of B.
                Set B to the value of R.
The answer is B.

Now. How do we visually represent this to our business analyst? How do we give her intuitive, visual tools for crafting this sort of logic?

Beats me! I have seen lots of attempts, ranging from flow charts to decision trees and none of them seem to me to get close to a general purpose abstraction for the problem.

That in itself is worrying but is only part of the concern. The main problem is more subtle. Simply put, the state machine of the first use case maps so sweetly onto the problem that it acts as its own documentation. Any analyst or programmer could pick up the state machine and immediately think "Ok. I get it. It is states with transitions between states." In some sense, state machines - for problems that naturally map to them - encapsulate both the 'why' and the 'how' of a solution. From a total cost of ownership perspective, this is a wonderful thing.

The second use case however, brought us immediately knee deep into a thicket of math and boolean logic and loops and if/then/else shenanigans. We can concoct a visualisation of this that represents the 'how' of the calculation. Have we gained anything by doing so? I have my doubts. But the real problem is that no amount of visualisation of this sort of logic gets us any closer to capturing the 'why' as well as the how.

Two things I especially like about this article. First, I love the observation that for appropriate problems state machines have a powerful self-documenting quality to them. That succinctly explains why I'm so enamoured with the state transition table to which the Bob Martin introduced me. Second, it's really important to know that there are in fact some limits to the usefulness of state machines, especially if you're going to write eleven or twelve articles about them. ;-)

State machines part eleven

These were my first rambling thoughts about workflow from June of 2002. (Maybe I should call this "part zero". :-) I haven't looked at Commons workflow nor Turbine's pipeline since then. The code has probably diverged from my UML diagrams.

A summary of what I've learned over the past couple years of working on PlanetCAD's workflow and paying attention to other options.

I think there are several different things that get described as "workflow". I think of them as different use cases for a general workflow engine.

1. There's the wizard interface that organizes a complex form into multiple steps (or pages, or screens, or whatever). This is what commons-workflow is primarily about.
2. There's the business process automation where a purchase order must have quotes from three different suppliers, reviewed by someone in management, further reviewed by someone in purchasing, and finally the PO is cut and delivered to the winning supplier.
3. Complex processing of data without human intervention. The stuff we're doing at PlanetCAD is automating the preparation, processing, and delivery of engineering data between manufacturers and their suppliers. I like to describe this as a distributed batch processing system. A sysadmin sets up the scripts that will be used for processing. When an end user sends a collection of engineering files to another user, the destination user's profile determines which of the scripts get used for processing. The scripts are run without human intervention by a collection of job servers. A workflow state machine manages the processing of the script.

As you might guess from the rest of the entries in this series, I now see applications for workflow everywhere.

Clearly, some workflow systems would be a natural combination of these things. I think that Jason's use case of the lifecycle of a book will probably be a combination of 2 and 3. In fact, we have a couple cases where our automated workflow pauses to wait for a human to approve what's been done so far. We started with 3 and are adding elements of 2 as they are requested. I'm not as interested in 1, but I've seen some discussion on the commons lists about using commons workflow for some of these other kinds of workflow, so I have been including it in my thinking.

The original audience for whom I wrote this knew what I meant by "Jason's use case." For the rest of you, Jason van Zyl described the process a book goes through in editing and production -- something important for tambora.

Commons Workflow (figure 1):

An Activity (or wizard) is a collection of steps. There's a composite called Block that allows steps to be arbitrarily nested. Blocks are also used to model 'if', 'for', and 'where' type operations. There's some plans to add a Process which is a collection of Activities. The existing code handles wizards. 'Process' would be needed to add support for workflows between people (type 2) or workflows between systems (type 3). A Context is provided at runtime as processing flows through a defined Activity. Decisions through the workflow are made based on objects in the Context.

Turbine's Pipeline (figure 2):

Looks pretty similar to Commons Workflow, though a little more simple. A Pipeline is a collection of valves. The pipeline is defined with an XML file not unlike the default means of configuring Steps in an Activity in Workflow. At runtime RunData and ValveContext are provided as processing flows through the Pipeline. There's no composite patter like the Workflow Block, but the rest is pretty similar.

State design pattern (figure 3):

I think this turns the Pipeline model inside out. Instead of having a context and moving it through a pipeline, client code talks to the context and it changes states through subsequent calls. Context is the object that client code talks to and the behavior of that Context changes as the state of the Context changes. PlanetCAD's workflow uses a State pattern. It's worked pretty well for us but it seems to invite some coupling between the State objects and the Context. And we're also seeing some proliferation of pretty similar states.

Event model:

The asynchronous nature of a business process workflow (type 2 above) invites some thinking about making the workflow event driven, which is what I've been doing for the past several weeks. In this case the individual Steps or Valves or States would be decoupled and made independent. Then the workflow would be a network of listeners that trigger a particular processing step including access to contextual info in the invocation. When processing completes an event would be fired to indicate its completion and some other step could be listening for that event. You could still use an XML descriptor to define the network of listeners and the rules that govern different paths through the network. But I think making the steps more loosely coupled opens the opportunity to change the workflow at runtime. That would allow ad-hoc workflows to be created, or existing workflows to be changed on the fly to handle exceptions in the standard process.

I also like the potential for letting completely different systems trigger events in the network. I haven't quite gotten my head around this one yet, which is why I haven't included an illustration. Seems like the same sort of mental transition to event driving programming and GUIs. The elements start to look like they aren't doing enough, but the effect of a whole bunch of them orchestrated by the user makes cool things happen. In the workflow stuff I'm working on, it pushes a lot of the magic into how the network of listeners is organized how the rules in the network interact with one another to control flow through the network.

These decoupled states waiting for asynchronous events could even be web services in a pipeline, if you accept my theory that a pipeline is just an inside-out workflow. I still think there are interesting parallels between the asynchronous event-driven processing of GUI applications and similar asynchronous event-driven processing in Service Oriented Architectures. I don't think its any coincidence that SOAs and pipelines are getting some buzz these days. Finally, I'm still interested in a workflow engine supporting ad-hoc workflows.