What is Windows Workflow Foundation?
What seems like a simple question that can be answered in a few sentences is actually a little more involved. To understand Windows Workflow Foundation and why it is important you first need to understand “Business Processes” and how modern organizations use them to gain value. Since most business processes are manual, another concept to understand is Business Process Automation. Finally it is necessary to understanding “Models” and how they are used to depict and design business processes. This post will look into all of these concepts (Business Processes, Business Process Automation, and Models) before answering the question “What is Workflow Foundation?”
Business Processes
The idea of a “process” was first described by Adam Smith (who lived from 1723 to 1790) in his book The Wealth of Nations. Adam Smith used the manufacturing of a pin (the modern day nail) to illustrate the value of process. In this example the production of a pin is described as follows:
“One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another ... and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”
This early example uses division of labor to increase productivity. Allegedly, workers using this process produced 240 times more pins as the same number of craftsman. A craftsman being a laborer who performs all the activities needed to produce a product. This was an innovation at the time because in Adam Smith’s day all products were primarily produced by craftsman.
Today the modern business process is defined as a collection of activities which start with a need and end when the need is fulfilled. A useful way to categorize business processes is listed below.
1. Management Business Processes - Examples: Governance and Strategic Management
2. Operational Business Processes - Examples: Manufacturing and Supply Fulfillment (These are core business processes that are related to revenue generation.)
3. Supporting Business Processes – Examples: Accounting and Recruiting
It is important to note that the term “Business Process” does not imply automation. A completely manual process like the one described by Adam Smith is a business process. (Based on the classifications above, it is an Operational Business Process.) Figure 1 below shows an Operational Business Process that is more common in the 21st century. This is a Supply Fulfillment business process. This is the example I will use for the rest of this post. Since I have not discussed modeling technologies it is important to note that Figure 1 is just a free form drawing of the labor required to complete a manual supply fulfillment business process. The graphics in the figure do not represent a standard notation for representing tasks or activities. These graphics are only meant to illustrate a completely manual version of a Supply Fulfillment business process.

Figure 1 – A manual Supply Fulfillment process.
Business Process Automation
Business Process Automation (BPA) is concerned with cutting the cost of a business process by automating as much of a business process as possible. The use of software is the primary tool most organizations utilize to achieve effective BPA. BPA still maintains a division of labor but adds additional value by reducing manual labor and facilitating interoperability between disparate systems. Since it is unreasonable to expect that all aspects of a business process can be automated, an effective business process automation strategy also takes into account human interaction.
Interoperability with other systems is very important when automating business processes. If an automated business process can only communicate with components inside of its own application host then the value of such a business process will be limited. True business process automation occurs when a business process can interact with many different applications - even if another application is written in a different technology. This should also include applications that exist outside of an organization for situations where Business to Business (B2B) interactions are needed.
Workflows
The conventional definition of a workflow states that it is a model of a Business Process whether it is a manual business process or an automated business process. In other words, a workflow is a simplified visual depiction of a real world business process. A model airplane is a good example of a model. It is a simplified depiction of a real airplane – it is smaller in size, it has no moving parts, and it has no requirements to actually fly itself. A conventional workflow is a model that follows this same pattern. It is a simplified visual depiction of a business process. It is just a picture of a business process and is not expected to execute itself. Technically speaking Figure 1 above is a workflow (or model). That is it is a visual depiction of a manual business process. However, most workflow aficionados would draw this same business process using more standardized symbols like those found in Business Process Modeling Notation (BPMN) or Unified Modeling Language (UML). The same workflow of Figure 1 is redrawn using BPMN in Figure 2.

Figure 2 – Supply Fulfillment workflow drawn using Business Process Modeling Notation
Notice some of the benefits you get from using a standardized modeling notation. In addition to having a common notation that is familiar to more people, modeling notations tend to coach more details from the designer than ad hoc diagrams. For example, the logic depicted in Figure 2 contains more details about the RFQ sub-process. Here we see that first a message is sent to each supplier, and then the business process waits for a response, finally each response if saved. Another improvement in the logic of Figure 2 is that a time limit has been placed on the RFQ sub-process. This prevents a slow supplier from slowing down the entire supply fulfillment business process. In general, models like the model shown in Figure 2 contain more information than ad hoc diagrams.
Windows Workflow Foundation
Windows Workflow Foundation (WF) marries the model of a business process to the implementation of the same business process. Stated another way, WF promotes the model (or the workflow) to a first class development artifact. Figure 3 shows our supply fulfillment business process modeled by the WF designer which is delivered as a feature of Visual Studio. WF models are created by assembling “Activities” into a business process. Activities can be thought of as atoms of logic. (Other modeling notations use the term “Task” to represent the same idea.) Figure 4 shows the Visual Studio Toolbox and all the out of the box Activities which come with Workflow Foundation. This list of activities is extensible and development teams may create their own custom activities to represent atoms of logic that are unique to their domain.
In WF as a model is changed by a developer so does the generated code that is created from the model. Clearly all the logic needed to automate a business process cannot be generated from a model. Therefore the WF designer has a variety of techniques for calling logic implemented with custom code or external services. For example, WF has activities for calling local code (or code within the same application) and WF also has activities for calling web services. When human interaction is needed there are activities which cause the execution of the business process to pause and wait for external data to be passed to the business process.
The ramifications of this technique are important because making a model a development artifact changes the way we think about models. Models are no longer visual depictions of a business process – they are the business process. It should be no surprise that models depicting business processes have become development artifacts. Over the past several years there have been many improvements to development environments. One of the more interesting modifications to development environments has been the addition of high end visual editors that are tied to code generation engines. This is the same experience enjoyed by Windows Forms developers for years whereby the forms designer generates the basic structure of the new Window and event handlers for each control allow custom code to be invoked.

Figure 3 – Supply Fulfillment Workflow drawn using the WF Workflow Designer (Click figure to view a larger image.)

Figure 4 – Activities Toolbox from Visual Studio
Conclusion
Workflow Foundation is a new developer tool that facilitates Business Process Automation. With WF the model of a business process becomes the business process.
In addition to the Workflow Designer and the Activities Toolbox shown in this post, WF also comes with other development tools such as a workflow runtime which instantiates and executes workflows (models). Additionally, WF comes with a persistence service and a tracking service to make workflow execution durable and visible respectively. Future post will investigate these capabilities.
In my next post I’ll take a more detailed look at Visual Studio and the capabilities it has for designing and building workflows.