State Machines and Business Process and Workflow
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. ;-)