If you haven't heard of Microsoft's Windows Workflow Foundation (WinWF), you're probably living in a van down by the river. Microsoft has (and rightly so) gone to some lengths to permeate the software development world with awareness of their framework. This is because they've invested quite a lot in WinWF, and not just in the framework itself, but also in other Microsoft technologies that are being built to take advantage of it, such as Office 12, SharePoint 3, ASP.NET, Windows Forms, BizTalk, etc.
It's not just another framework; it's not just a passing fad. Indeed, over the last several months, both before and after Microsoft released Windows Workflow Foundation (WinWF), I've become more and more convinced that workflow is everywhere. Consider, for instance, the simple (and ubiquitous) case of a user updating a database with a form. This, in its most essential sense, is a kind of work flow; it is a set of steps (activities) that are performed by a working entity. It is entirely possible to design a workflow model around just this simple case.
Of course, workflow, as most of us think of it, is generally more involved. Obviously, if it weren't, we wouldn't need any kind of new (or old) technology to deal with it. The reason we need a workflow framework is that many workflows span multiple working entities (be they humans or machines), and coordinating that effort becomes quite a task if you have to start from scratch.
For another example, consider the ubiquitous wizard. Who among us has not at some point developed a wizard for end users to enter data, such as a loan or membership application? Essentially, this is a set of steps that a working entity should perform to complete a task, and it is another great candidate for a workflow technology.
And naturally, more complex, inter-machine business processes such as have been historically targeted by the likes of BizTalk are another good example of candidates for workflow. But BizTalk is too high-level and focused to serve the general need for a workflow framework (or foundation, if you prefer); it is targeted primarily at simplifying inter-machine, inter-application, and inter-organization automated processes. All the same, it does represent one kind of application that can benefit from it.
As a final example, consider your basic approval process. You fill out your timesheet and submit it to your supervisor. Your supervisor reviews it and either approves it or asks you for changes. If approved, your supervisor submits it to your manager for a similar approval process, and so on, all the way up to HR where they enter it into the payroll system. This is primarily a human workflow (not really covered by, e.g., BizTalk); it is, or can be, fairly complex, and yet it is very, very common.
All of these are examples of kinds of workflow that could be served by a workflow foundation. And in fact, they will be served by WinWF. As I mentioned, Microsoft has invested a lot in this foundation. The thing that makes it stand apart from most other well-known workflow frameworks (apart from being made and promoted by Microsoft) is that it really has been engineered for extensibility all throughout. Whether you need to create custom activities or use a special tracking and persistence service, it has most, if not all, of the plugs you need to inject and modify to suit your needs.
