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. 

On the whole, I dont think I can overemphasize the importance of recognizing workflow as a real thing that you, O Grand Maker of Software, need to think about as a real thing. In an upcoming article in CoDe Magazine (should be in the next issue), I talk about the importance of focusing on object-oriented design as a real thing and how it is essential to solving business problems. Workflow is another one of those foundational things that I think we need to embed in the way that we design applications, at least in the business world. The funny thing about it is that it has been there all along but only some have put the effort into thinking about it formally, just as object-oriented design has been around for a long time but few have truly understood and thought about formally.

The reason we need to embrace WinWF is that it can change the way we develop business applications for the better. The greatest strength of WinWF itself, apart from its extensibility, is that its soul is modeling, that is, visualization of both structured and semi-structured processes all the way from high-level human workflows down to basic code flow control. Taken together with strong object-oriented design, I think that we can take our applications to the next level of evolution in our industry.

In fact, I imagine a design environment where you can visually design in a multi-dimensional way the various aspects of your application. Imagine a three-dimensional representation of this as a many-sided shape, each side representing different architectural aspects of your application, such as security, network topology, logical topology, object-orientation (e.g., class libraries), business processes, services, and so forth. Each of these dimensions is a starting point to work on that aspect of the application.

Perhaps at a higher view, you could see different polygons attaching to each other via their services layer. But you interact with this in a three-dimensional way, grabbing the representation, moving it around, zooming in on a particular polygon (application), then turning the polygon around in your hand (figuratively, or maybe, eventually, literally) until you come to the dimension of the application that you want to focus on.

Choosing that dimension zooms into the next level view of that dimension. For instance, if you chose the business process element, you might see the human workflow or some business integration workflow. At each of these, you might be able to zoom in and see a model of the code flow, and at the lowest level, you would finally come to the code itself.

Now these may seem like ridiculous flights of fantasy, but I think most of it could be done today, and I think that it would be a huge step forward in software development. The reason I mention it here is that workflow, and WinWF in particular, is a rather large, positive step in that direction; a model is worth a thousand lines of code. Maybe I should duck while the code monkeys throw wrenches at me, but don't worry, we'll always have code.

I realize that visualization and modeling is anything but new. At the same time, it just seems right, or rather, that Microsoft is getting it right. Maybe its because the gorilla is the only one that can get the monkeys into line, but whatever it is, we're on the verge of something potentially groundbreaking. Together with DSLs in general and increasingly good form designers, we are rapidly approaching critical mass, as it were, and the fantasy I described above may just not be so fantastic after all.

So embrace workflow and embrace WinWF (you really don't have a choice). Embrace the modeling revolution. Gone are (or will/should be) the days of creating static documents and models that are stale as soon as the ink dries. Now our models can be our code. We can all be artists and communicate our genius to the world through pictures that concisely reflect our mental machinations.

Related Resources

SEP Field Wikipedia
Getting Started with Microsoft Windows Workflow Foundation: A Developer Walkthrough Dino Esposito
WindowsWorkflow.NET Microsoft
WinWF Web Casts Microsoft
WinWF on MSDN Microsoft
DSL (Tools) - Microsoft