I was thinking long and hard about whether Windows Workflow Foundation, or any other workflow tool for that matter, can really be used in a large production application for orchestrating large business processes. (Clarification: I’ve been writing a framework for developing such workflows using WF 3.5 and WF 4.0 for the past three years, so I’ll try to speak from experience.)
Is it possible to use workflows to orchestrate large business processes without landing in a mass of spaghetti a couple of years later?
I believe that the same techniques that need to be applied to code to prevent it from deteriorating into a slime ball need to be applied to workflows as well. It is, after all, “just code”.
For example, you really ought to review complex workflows you write. You need to come up with a framework for invoking one workflow from another, so that you can modularize your application. You need to learn to debug workflows and their code-behind, and train the activity developers on the internals of whatever workflow framework you’re using.
But wait, if it is just code, why don’t we just write the code? Surely a line of code flows from the keyboard much faster than an activity is dragged from the toolbox with the mouse…
In a nutshell: physical limitations to what you can do. When given a set of activities to choose from, with strict design-time validation on every operation, it’s much harder to go wrong than when working with APIs.
To some extent, this is a matter of personal preference—just the other day I saw a presenter demo a visual drag-and-drop tool for building certain UIs, and then dismiss it with “but you will write your UI in code anyway”. However, if you’re serious about writing a framework for workflow development, it’s not that hard to get to a state where the workflow developer is shielded very carefully from the bad choices, and the “right” application is almost magically generated from under his fingers.
Only developers can write workflow applications. Leave it to their personal preference whether they want workflows or code.
Other than the physical limitations mentioned above, there is a fallacy here that all the developers in the organizations have similar skillsets. What if you have a group of 10 extremely talented developers who can write a framework for workflow applications, who can write the activities and their code-behind and services and whatnot, and a group of 100 inexperienced developers who are accustomed to perhaps a simple scripting language and have never maintained an enterprise application?
I propose that it’s easier for 10 talented developers to maintain a workflow-building framework used by 100 other developers, than to maintain a framework for writing code.
Can workflows work together with any framework I already have in place for process orchestration, pub/sub, bus, etc.?
I believe they can. It’s just a matter of the proper integration. For example, in the project I’ve been building, we use WCF and a custom bus with pub/sub for most communication. I’m pretty sure that using WF with WCF and AppFabric is an even more seamless experience.
Isn’t testing a PITA? It’s not just “create an object, call a method” anymore.
I propose that testing workflows is in fact much easier than testing code. The main reason is that workflows automatically promote proper dependency management, which leads to better testability. If you drag activities around, and these activities are properly designed, it’s almost impossible to introduce any dependencies other than the dependencies these activities have.
In turn, activities rely on local services (extensions in WF4) for any external work, or invoke WCF services. Either is very easy to mock, replace, or isolate.
In other words, workflow-driven development actually holds your hand all the way to testable code, which can hardly be said about code-based APIs.
There is, of course, the matter of building a framework for unit testing your workflows. Someone has to run them, wait for completion, report any errors—but this is a framework you write once, much as a framework for testing code.
To summarize, I have faith in workflow-building frameworks for orchestrating business processes. It does take discipline, and there is no magic involved.
For an alternative (in fact, completely opposite) point of view, I recommend reading Udi Dahan’s post, The Danger of Centralized Workflows.