P&P Summit Day Two: Re-engineering to Support Workflow

The last speaker of the day is Billy Hollis. He speaks with a real thick southern draw which at least makes me feel at home. Interestingly enough he has a sticker on his laptop that reads “Partnership for an Idiot Free America”.

He’s defining workflow as:

• Something that has work items that needs to be operated on. Documents, orders, etc.
• It has Rules/process to control the flow of these work items.

He brings up the fact that distributed workflow and non-distributed workflow is a categorization, not a definition point of workflow.

He talked about using queues more often in workflow solutions. It provides the load balancing and fault tolerance, but more importantly provides the loose coupling of the process parts. He defines a “push” vs “pull” queue difference. The push queue is that items are added to the queue and the back end just pops stuff off and works on it. The Pull queue is more for human type processing such as I want to work on this one item in the queue because I know how to handle it at this time.

He states that MSMQ as a queue mechanism is good for high throughput and for fire and forget models, such as logging. However, he doesn’t like it for the pull type queues and there is no way to query the queue easily. He also thinks that MSMQ is not on the “innovation path” within Microsoft. He suggested that if you are using MSMQ then continue to do so; however, if you are making a new system then use Service Broker for 2005. This overcomes the drawbacks of the MSMQ queue since you can query it, no client side deployment special packages (MSMQ client) and so on. Messages can be logically associated together as well. He does mention it is not as high performance as MSMQ.

He suggests queue wrappers for workflow systems. This includes providing a façade to your queues. The wrappers can ensure type safety for what is going and off the queues. You can write your own wrapper for specific scenarios or queues if need be.

He talks about separating routing from processing. This means that he wants to put in a dispatcher at the end of processing to perform the routing. This is like an orchestration engine to control the routing. This provides a loosely coupled mechanism to control routing separate from processing. He called this the dispatcher model.

He then discussed Windows WF. Since I’m pretty familiar with WF this was a review of what WF was and a high level of how it worked.

It’s good because:

• It handles threading
• It handles persistence.
• Included in the OS for Vista and included in Office 12.
• You can integrate the designer into their own systems.
• This is an in process engine (you must host it somewhere).

It may be bad because:

• You may have to blaze the trail on activities that are not out of the box.
• There is a little bit of a ramp up time on learning the communication into and out of the workflow.
• Does not address distributed workflows - you’ll have to supply the queues.
• Rules engine has no out of the box front end.

He then brings up the fact that BizTalk includes all the things that WF doesn’t have. It is a product and thus it make sense it has all this stuff. Of course, BizTalk is expensive. :) He also brings up the fact that BizTalk can be temperamental.

He then went on to talk about a real world experience of designing a workflow system. The lesson learned:

• Build in logging of all workflow transactions.
• Build a tool to monitor and manage queues.
• Remember to include workflow information in reporting.
• Take the human side into account. This means making the changes easy for users to adapt to and ease their concerns about their redundancy after the automated process is in place.
• Test the entire process, not just the workflow pieces. Test the rules hard to prove all the cases were covered.
• Recognize there will be malcontents as people do not like change and also show productivity will slow at first until things are learned.

This was a good session for me as my current client is looking at needing a workflow engine soon.