Many people I have talked to have asked me why was there a need for state machine style of workflows. Here I am trying to put down some of my thoughts for the reasons why we felt the need for having the state machine style of workflows in Windows Workflow Foundation.
If you look generally at the business process landscape you will find that end user requirements have changed. They are no longer satisfied with simple business process automation. They want much more than automation. In my experience there are 3 main categories of requirements.
- Flexibility
- Visibility
- Control
Flexibility
Businesses today need to be agile and the business processes that they use constantly change to keep pace with the demands of their customers. Moreover for small businesses to compete their ability to be agile in responding to customer needs is what distinguishes them from their bigger competitors. Thus there is a need to create business processes that are flexible and accommodate a variety of situations. Often the business processes contain a prescribed path to the end goal but then there are a lot of alternate ways the same goal can be achieved. For example a Purchase order can contain a prescribed path where the PO goes from being create to approved to shipped to completed. But then there a multitude of other ways in which the PO can be completed. The PO can get changed, or back ordered or canceled and then ReOpened. All these paths must be accounted for. Just to put things in perspective. We did a study of the purchase order process of a small business and found that there was one traditional order fulfillment path but then there were about 65 different variations on the same process depending on the nature of the order. Trying to hardwire such a large number of alternate paths is not only difficult it is almost impossible. Traditionally there are two ways in which this was dealt with. Either the business process was hard wired to accommodate all the paths, making the implementation of the business process extremely complex, brittle and hard to maintain. In the other way the alternate paths are simply not dealt with and any situation of the ordinary was dealt outside the domain of the process. When dealt outside the process all the benefits like tracking, visibility etc were lost. Most often people create manual systems to track such out of the ordinary situations.
State machine workflows provide an easy way to create these complex business processes easily. In a state machine the idea is not to hardwire the different paths a process can take but rather to simply account for all the possibilities. The way you do it is by providing event handlers for each of the external events that can influence the process. Within each event handler you can put logic to respond to that event. You can then group the event handlers into logical states of the process. Each state corresponding a to a milestone in the process.
Visibility
In a connected world the ability to provide visibility into a business process to your partners and customers is a very important competitive advantage. It also helps a business internally to measure key performance indicators and help in continuous improvement.
Once you have implemented your process the most important thing to do is to provide visibility into the running instance of the process. Without providing that visibility the process will be pretty much useless. In a lot of cases business processes are specifically built with visualization in mind. In some cases a whole layer is built to simply interpret the running instance of the process and provide visibility. All these approaches are fine but when you consider a flexible process which is changing frequently, the interpretive layer would have to change frequently too to make sure that the visualization is in sync. Also the knowledge of the business process is duplicated, once in the visualization layer and one in the process execution layer. This is not a very desirable way to build business systems.
Another important reason for providing visualization is to make sure that the users who are interacting with the process have all the right context to take any actions they want to. An ideal visualization must provide information about the past steps in the process, the current context and some information about the likely future. A business process must be built so that all these three aspects (providing the past, present and the future) are easily possible.
State machine workflows offer a very nice and effective way to query the process. Moreover there is no interpretive layer that needs to be built around it. The current state of the business process is the current state of the state machine. You can figure out the past steps by simply looking at the states the process has been through. In order to figure out the future you simply have to find out the possible events that can be received in a state and the possible transition from the current state. As you can see the amount of work that needs to be done to provide information is not much. The information about the process need not be duplicated in a visualization layer. You can see the order processing state machine example or the Interactive voice response application that are available for download. The entire Visualization layer is completely agnostic of the process. If any change is made to the process there is no need to change the UI it can simply query for the structure of the new process.
Control
Control almost seems paradoxical when we just talked about flexibility. The control we are talking here is the ability of the end user to control a running instance of the process. For instance think of the PO process where the PO process owner wants to skip the approval step. Or may be a PO is important enough where an additional approval is required for which the approval step needs to be repeated. Such type of interaction patterns require a kind of control that the end user must have on the execution of the process.
State machine workflows provide you the ability to control the execution. A user can skip a state or jump to any other state in the process. Trying to provide this kind of control in a sequential workflows would mean hardwiring those paths in the process. But again that would mean that the flexibility is lost.
Overall State machine workflows provide a very easy to use and useful paradigm. Also it is not something new that you have to learn. State Machine have been in use since the advent of computing and all of us have used them. Even in doing business process analysis all of us have drawn a state machine of the process on paper and then implemented it in code. What we offer in Windows Workflow Foundation is not only a way to create those state machines in Visual Studio but also a way to execute them.
