State Machines and Business Users

I was at a workshop over the weekend talking about the use of Finite State Machines as coordination mechanisms for systems. These things might be called sagas, activities, workflows, process managers (my preferred term lately from PEI), orchestrations, choreographers, and I am sure I am leaving out a few.

One of the guys in the talk (quite knowledgable) brought up that they used to use petri nets for this as well as pure finite state machines and there had been a push to more procedural mechanisms as business users don’t think in terms of finite state machines. I noted that while we have been moving to more procedural methods, as most of these procedural methods are in their hearts asynchronous our procedural techniques tend to be domain specific languages that internally generate state machines anyways, often based in the join calculus (think futures or the async keyword in C# when joining).

However later in the day I had a realization connecting two things. We like to describe business situations in gherkin style (not strict) specifications.

Given: Some initial starting point
When: Something happens
Then: Something occurred

We as an industry have been very successful getting specifications written in this style. We regularly do analysis and write acceptance criteria using this style. Business users seem to have been fairly capable of understanding it.

This style is basically describing a state machine.

Given: some initial state
When: a stimulus
Then: Something occurred (message/transition depending on style of testing)

How can we be so successful with this style of specification and in the next breath say that business users can’t understand state machines? The trick is they don’t understand the actual machine but they understand (and can specify very well) the exterior behaviours of such a machine.

Try getting a business user to create for you the state machine to control a simple DVD player for you. Likely they will scratch their heads and politely become very busy so they won’t be able to attend the next meeting. Try getting them to specify

Given a video is playing
When fast forward is pressed
Then the play goes at double speed

Maybe the problem here that caused our move towards procedural style controllers was the goal all the middleware seems to push of having business users writing the activities as opposed to reading about/specifying/understanding them. I have yet to see in all the organizations I have been to a single one where the dream of having business users creating these types of long running procedures actually panned out. to be fair: I have seen it work but the business user had formerly been a developer and BA

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to State Machines and Business Users

  1. Tuomas Hietanen says:


    There are many solutions to encapsulate (mutable) state.
    One is OO, but it usually exposes the state in quite ugly way.

    Some others are actors/agents based models. As you may already know, those are pretty close to reactive programming, or what you would call event sourcing, actually.

    I translated “The Simple CQRS” to functional language.
    There I used this F# MailboxProcessor (which is based on agents model) to make the event storage.

    But Actors/Agents based model can be used to another things also, not just event sourcing. For example a real-time domain model.

    Here is a nice video about the actor model.

  2. Kelly French says:

    I think you are onto something, as it is usually fairly obvious that business customers can handle some pretty complicated procedures and process flows. The difference I suspect is that they focus on the action and not the state. The specs you describe are centered around a state, lists an action and only then describe the behavior that results from said action; let’s write is thusly:

    State ->Action->Behavior.

    I’d be willing to bet that the users are really thinking like this, “I want it to do X (Behavior) so I have to push the yellow button (Action) but it only works if the red light is on (State), or


    The style of documenting has enough in common that they understand what is being asked for even if, to them, it is listed backwards.

  3. I’ve personally found that state machines, when applied to a business domain, cause more problems than they solve. State machines attempt to record a multitude of factors within a single dimension. This is great for one-dimensional problems, or for problems like parsing that can be collapsed to one dimension. It’s not so great for business problems.

    A typical CRM system will model the process of acquiring and serving a customer as a sequence of states. This sounds good on paper, but once the real world happens, users have to work around the system as often as they work through it. The states just don’t capture the richness of the problem domain.

    A typical bug tracking system will model detecting and fixing defects with state machines. Some well-intentioned project manager constrains the flow from one state to another. How often have you had to artificially move though fake intermediate states to get to the one you want? You essentially have to lie to the system – and ultimately to that project manager – in order to get your work done.

    I prefer to model the history of the system, and base the specifications on that history. The “given” clause does not refer to the state of the system, but to some event that has occurred in history. All other events can be ignored.

    If you try to collapse history into a state machine, you will find yourself facing a combinatorial explosion. Every time you introduce an event that could happen in parallel, you will essentially double the number of states. It’s easier – and I have observed more natural for the business user – not to try to build the machine, but to simply state the requirements in terms of the events that matter, ignoring all others.

  4. Eddy Young says:

    FSM is possibly the best yet most under-used design tool. I wonder whether FSM will come back under a new fancy name as the latest software development craze…

  5. IanRae says:

    Have you looked at David Parnas’s work on requirements. He has developed a way of writing specs using table-based state charts. It has been used to specify flight control software. Parnas claims the specs were readable by pilots and they found several significant errors.

  6. Greg:

    Good points. I, too, see devs “thinking” in state machine terms quite often. What I don’t see (as often) are devs _coding_ in state machine terms; esp. when coding Web-oriented clients that are not human-driven.

    The Web browser is a state machine that waits for events in order to change state (HTML.FORM->submit). A Web server is a state machine that waits for events in order to change state (“when a request appears using this following URL, do this…”).

    However, once that level of state-machine are reached, most of the code executed is procedural (i.e. client code executes sequentially upon load, server code executes calls to other servers sequentially [file systems, databases, etc.] once the request is handled).

    So, for me, it’s this “next level” of coding that is most often still procedural.

    I, personally, would like to see more “state-machine style” coding at this “next level.”

  7. Gene Hughson says:

    Terminology can get in the way as well. A few years back, we started using UML activity diagrams to detail the various flows through a use case instead of a mass of text. In spite of the naysayers, the business users loved it as it was much easier to follow. The trick was to mention “it’s really just a flow chart under a different name”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>