It is no secret that I am not fond of using EAI systems like Biztalk for Human Collaborative Workflow.  I believe, instinctively, that it is a bad idea.  However, I have to be more than instinctive in this analytical world (and company).  I need to be prescriptive at best, and constructive at worst.  So I did some thinking.

When I was in college, I really liked some of the logic languages, especially Prolog.  I found it interesting that much of the real power of Prolog comes from the fact that Prolog is not really a language as much as it is an engine that evaluates logic rules, and the database of rules was dynamic.  In other words, a Prolog program could easily add statements to itself.  It is, in effect, self modifying.

I remember getting into a long debate about what it means to “write a program” with an Assistant Professor who felt rather strongly that no language that supports “self modifying code” should be used at all.   He was all about “proving correctness” while I was keyed in to particular problem sets that defy prediction.

And now, 20 years later, I’m beginning to understand my instinctive reason for believing that human collaborative workflow should not be done with an EAI tool… because Workflow is self modifying.

In order for the EAI engine to be helpful in a workflow situation, every state must be known to the engine at compile time.  Avoiding this rule can be done by modifying the logic in the engine.  Workflow must be self-modifying to be truly useful, because Humans are Messy.

EAI engines are not known for being amenable to this modification.  A good workflow engine is not restricted in this way, so for it, no problem arises when a workflow manipulates itself.  But for an EAI system, changing the state machine half way through the process, and applying the change to only one instance of the process (itself, usually), requires flexibility in design that EAI systems are not normally capable of.

What do I mean by self-modifying workflow? 

There are two ways to use a workflow engine: one as a code system and the other as a logic database.  It’s kind of like comparing C# to Prolog.  A truly Prolog system produces a logic database that is inspected at each step by the Prolog engine.  Therefore, if a block of Prolog code updates the database, the logic of the system changes immediately.  This is not so simple with C#.

If you use your workflow engine as code, (the C# model), then a human being can perform “self modification” of the workflow only in very specific and prescribed manners, and only when the designer of that specific workflow would recognize it.  In other words, you can create a list in your data that represents a list of people that an item must be routed to.  You can modify the list as the system moves through, and your code workflow can inspect the list.  However, the constraints come in that the list is a single thread, and that modifying the list to change the people who have already seen the item is possible but logically meaningless.

If you use your workflow engine as a logic database (the Prolog model), then a human being can self modify the workflow by adding complex logic, changing evaluation rules, rewriting error handling, and doing other complex jumps that are essential to creating a system that begins, even remotely, to be able to handle the sophistication of human collaboration.

For an EAI engine, this is foolish.  EAI lives “at the center.”  It is a system for allowing multiple other systems to collaborate.  The rules at the center need to be stable, or all routing can suffer.  This is not a good place for very complex behavior models based on self-modifying instances of code. EAI, to function properly, must submit itself to excellent analysis, careful design, and very very very careful versioning. 

And that is why EAI systems are lousy at human collaborative workflow.