Why Workflows? Part I
With the flood of new technologies coming from Microsoft recently Windows Workflow has had a lot to compete with to get programmers and managers attention. Unfortunately Windows Workflow does not have a quick 60 second summary. Most of the project types in .NET can be explained in a minute. ASP.NET is for building web applications. WCF is used for remote communication. Windows workflow is for…. where do I start? Windows Workflow has many facets. I’ll cover the ultimate configurable application in Part I. The aspect of windows workflow that I am focusing on in this article is not the most advertised feature of Windows workflows but it is one of my favorites. Most developers know the benefit of building applications with configuration in mind. If we can move an application behavior setting to a configuration file or a database then we can save maintenance costs. The typical items that are configurable in applications being built today are application resource locations (database connection) and application block configuration (logging and exception handling behavior). These items tend to be static while the application is running. They are configured by someone in the IT department. These items don’t change very often. Usually they change due to network infrastructure changes or when troubleshooting an application. But what about business behavior changes for the application? For a typical application today the business would make a formal request for change, have it sent to IT, a programmer would be assigned to it, the programmer and the business person would have a meeting or dozen to make sure they were on the same page, implement, and you know the rest. Changing a business behavior of the application is generally more costly per change. Also, depending on the industry and the company culture the business may be making change requests frequently. I would argue handling business changes in the application has a better ROI than handling infrastructure changes. However, we’ve had a poor answer for that until windows workflows arrived.
Now, don’t get all flustered. First, we had to worry about outsourcing and now we’re trying to remove ourselves from maintenance coding. We developers will be the last to turn off the lights in the office after we’ve automated the last business function.
What do we need if we want to expose an application business behavior to the business for changes? We’ll need to develop a flexible but simple programming language for our business savvy non-programmer. Windows workflow has a visual component to building workflows. It’s kind of a two tier language. We build the basic activities and base workflow in c#. Afterwards we can compose the final workflow from these pieces with drag and drop programming. Windows Workflow can be viewed as a framework that allows us to build visual programming languages for others. In this case a business programming language. We expose the program language elements as business functions that have a visual representation. These programming elements are called activities. The workflow can be defined to control where a programming element can be placed and how to configure it. We have control of what the language is and its validation. Once we have developed the base Workflow type and the business activities we need an editor to allow the business person to modify a workflow. Microsoft has provided the same Workflow designer control in visual studio in the workflow namespace. We can host this control, load up the business activities in a toolbox and allow the business person to change the application behavior.
Now that’s cool.