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.
5 thoughts on “Why a workflow model is not code”
"for an EAI system, changing the state machine half way through the process requires flexibility in design that EAI systems are not normally capable of."
Is there a technical reason why an EAI system could not be made capable of this?
Sure you and Don Quixote. Why would you use an EAI tool to represent Human Workflow? Unless tilting at wind mills is your kind of thing.
sr. technical product manager
To Bruce: Why not add these features to an EAI system? Because EAI systems are designed for a particular purpose: to encapsulate and allow the independent manipulation of the integration logic between independent systems. Re-authoring of the interaction in process is "bad" for the same reason that "self-modifying code" is bad: it is tough to keep it running. I would say that EAI systems should NOT be used for HCW.
To Mike Woods:
With all due respect, Mike. Your product advertises that it provides Human Collaborative Workflow components in the current RTM version. If you think it is a bad idea for Biztalk to provide HCW, you are talking to the wrong person. 🙂
In regards to Bruces Comment Kontinuum from web and flo handles modification of the EAI system. The system orchastrates widgets which can be redefined or substituted by other vendors. There will always be a risk when you try to change anything with any system however
I do not know enough about Kontinuum to comment intelligently on that product’s capabilities. However, from my very brief examination of their web site, it looks like a good product. I would not say, however, that the ability for a widget to be replaced in an orchestration is even remotely similar to what I was talking about. I was talking about a workflow model changing itself, not a human changing a workflow model. There is a huge difference.
EAI systems all allow humans to change the orchestration. Workflow systems should allow a single instance of the process to vary to the needs of the process. Many do not. A few do.
I cannot speak for this particular tool. Perhaps there is another feature that would allow it to behave in this way. The ability to replace widgets is not the feature I would pick.