I was asked today if there's a metric for determining whether an business application should use Windows Workflow Foundation (WF) or roll its own workflow plumbing.  Here's my extended answer...

As far as a metric of qualification, I can't say there is one (or that I have found one).  Besides deciding whether or not to  use a technology (or any type of plumbing) as an aide for development can't be (and shouldn't be meausered) by a number.  It's not the number of lines of code, methods, classes, assemblies, etc. that decide whether or not you should use workflow.  It all comes down to process you need to model with your application.

If your business process is some what complex in other words:

  • Multiple activities
    • Notifications
    • User interaction
    • Parallel & Conditional Processing
  • Scheduling
    • Performing action "X" after "Y" seconds/minutes/hours/days
    • Multiple Instantiation
    • Multiple Threads
      • Creation
      • Cancellation
      • Pausing
  • Bulk Processing
    • Grouping of similar tasks
    • Retrieval and sharing of similar data

For one of our applications, a real-time document (reports, forms, invoices, etc.) generator, using WF was a way for us to work around the headeches of building our own scheduling and concurrent processing plumbing.  We needed to schedule the generation of n number of documents and have the process respond to external stimulus (user cancellation, re-ordering of the generation list, pausing of processing, etc.)  By using WF, we got many of these features straight out of the box.  Yes, I know that using WF increases the learning curve since any developer working on/maintaining the application will need to know/learn WF.  But even if we were to write our plumbing, that developer will still need to learn our implementation.  So, there will be a learning curve regardless.  By choosing WF, a developer has access to a ton of samples and resources offered by the community for the community.

Note: The same argument can be made about other parts of a "framework" i.e. logging, data access, object instantiation, etc.  Why build something from scratch when you can use an existing solution to the problem?

If you're curious about what WF has to offer, check out the samples on the web or the ones found on the Vista SDK.  The more you know about any technology, the easier it is to know whether it can be useful or not in one of your projects.  For me it was easier to plun into existing plumbing rather than coming up a with a lesser-feature copy of one.

What are your thoughts on this?