Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

How is workflow different from a Finite State Automata?

How is workflow different from a Finite State Automata?

  • Comments 1

After showing a workflow diagram to a co-worker, he asked me if I could tell him how this is any different from basic Finite State Automata (FSA).  To be honest, I had to think about it for a few minutes to get my thoughts around this, but there is a fairly big difference.

For those of you who aren't familiar with FSA theory, this is a segment of computer science that goes back to the earliest days of computing.  The idea is this: arrange your input into a stream of tokens of the same size.  Then, keeping a state, read each token.  The token will dictate the state you move to next.  Side effects could be added to a transition.  These side effects, taken together, were the actual functional code of the system.

In a strange way, we've all moved to FSA programming when we moved to event driven application programming.  The event handler is essentially a place to put logic for reacting to an input (the event) in a state (the global environment).  It's a bit different, though, in the sense that our input isn't in a stream.  We can't look ahead at the next token or move in the other direction over a series of tokens (important parts of compilier design).

In that respect, Workflow modeling is closer to event driven programming than it is to FSA theory, because we don't have that input stream.  We can't look ahead. 

On the other hand, unlike event driven programming, most workflow systems use the FSA approach to modelling, where you look at the behavior of the system by creating a graph showing the stages of work, and the transitions from stage to stage. 

However, what really distinguishes Finite State Automata from workflow programming, in my mind, are the three layers of abstraction inherent in Workflow analysis. 

Finite State Automaton development requires a pre-processing step, where you take the input and interpret it as a series of tokens in a language.  In compiler theory, we call this lexical analysis.  This analysis happens at only one layer of abstraction (usually at a very low level: character sequences).  Therefore, the structure of computer languages has to be represented as a parse tree: a complicated heirarchical structure that "represents" the analyzed token stream.  The FSA is done when the parse tree is done.  It isn't involved in actually using that tree to create the target code.

With workflow analysis, there are three layers of abstraction: Business unit level, Business process level, and Workstep level.  All three are distinct (but related).  All can be described with rules and constraints.  All have a specific purpose, and each one can be represented as a state graph.  The mathematics are considerably more complex.  (Only the lowest level has to be deterministic).   There are many PhD level practitioners of workflow modeling who can attest to the fact that workflow is much more complicated and complex than the fundamental concept of a Finite State Automaton.


Because FSA's interpret logic... nothing more.

Workflow modeling deals with human behavior.

Page 1 of 1 (1 items)